[Bitcoin-development] New BIP32 structure

Luke-Jr luke at dashjr.org
Wed Apr 23 21:53:05 UTC 2014

On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
> On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
> > Hopefully it would be clarified as only a MUST NOT do so silently...
> > "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> > sounds like a terrible user experience. :)
> That is a subjective matter. To me it makes PERFECT SENSE that funds
> across accounts NEVER MIX. One can still send funds from one account to
> another and then perform another spend.

Only by crossing the blockchain unnecessarily.

> That's what I consider a consistent and thus GOOD user experience.
> What's the purpose of Accounts if wallet mixes coins among them anyway?

To keep balances separated. For example, I might have an account for each of 
my children, move their allowance money to it every day/week (off-chain), and 
they can spend only what they have in their account. Or an exchange might have 
an account for each user's deposits. In neither case, would it make sense to 
pay special attention to which UTXOs are consumed in transactions from any of 
the account.

The only use case that requires tracking UTXOs per-account is when you want to 
have multiple uncoordinated copies of the wallet in use at the same time, and 
therefore need to immediately identify which account a transaction came from 
based on the UTXOs it consumed - although even then, you could still mix funds 
as long as you use only the first UTXO for tracking, so maybe there isn't even 
a niche use case! In any case, Trezor, being a hardware wallet, should never 
overlap with this niche...?

> I know it's not good to use classic bank accounts as analogy, but that's
> exactly how they work. Or have you every done ONE transaction from two
> bank accounts simultaneously?

Bad analogy. Banks *always* mix funds. You don't expect your bank wire to use 
exactly the specific dollar bills you deposited, do you??


More information about the bitcoin-dev mailing list