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.