On 04/26/2014 04:33 PM, Mike Hearn wrote: > > Let's assume we use one shared branch for everyone. Then two > cosigners could need a new receiving address at the same time, and > get the next unused address on that branch. > > This is the part I struggle to understand. There is no shared branch > because each user/cosigner has their own unique seed and thus unique > key hierarchy, right? What you described above could be an issue if > all co-signers shared the same seed but then the scheme wouldn't work. > Consider two people with phones, using 2-of-2, using private seeds k1 and k2. Every address generated by either party is: 2-of-2(K1/a'/b/c, K2/a'/b/c) So for any a, b and c you end up with a 2-of-2 address. The seeds/branches will not be used for single-sig receiving... it's always a multisig 2-of-2. In fact it behaves much like a regular wallet, you give an a, b, and c value, and you get an address -- it's just that this wallet always gives you a P2SH multisig address. The problem is that if you follow BIP32 in the the most obvious way, both devices will generate receiving addresses along the last index, i.e. K/a'/b/0, K/a'/b/1, K/a'/b/2,... If I am at one store and my wife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382) at the same time not realizing the other one has distributed that address. There's not a good way to coordinate the devices well enough to avoid it. But we don't have to. The solution is to use two separate branches -- both phones will follow/watch both branches, but each only only distributes payment addresses from one such branch. The original proposal here suggested adding a level to the tree using the "cosigner index" as a branch point for doing this... I recommended simply having 2*N values for "b", so that each participant has a receiving line and change line, that won't conflict with other devices. However, all devices will still watch all 2*N branches to know the total balance of the wallet, and will use UTXOs from those branches when constructing spending transactions/proposals.