The motivation was that I came up with it before BIP 45 existed, but wasn't vocal enough about it because Armory didn't have BIP32 Multisig trees implemented yet, so I didn't have a strong mental focus or determination around it. If there's momentum behind BIP45, we should use it. I wanted to share the document because it was also created to be educational on the topic of "multisig address generation collisions" as being disucussed in this thread.

Though we just put in BIP44 with my modification into our new wallet format (in the works), and if I was to adopt this I'd like to simply merge the two.

    M / purpose' / coin' / account' / cosigner / change0or1 / address

For reference my proposal (and the way I implemented it before BIP45 existed) is just BIP44 but with 2*N change branches instead of 2:

    M / purpose' / coin' / account' / change2N / address

Our new code has the goal of being able to easily reconfigure your BIP32 tree for your specific application. But for the default free-public-download software, it would be nice to have a standard everyone agrees to. BIP44 vs original-BIP32 doesn't really matter since you only transfer the account branches, but this particular decision with how the consigners avoid "collisions" does affect it.

-Alan

On 04/09/2015 10:02 PM, William Swanson wrote:

Hello Alan,
Your scheme is basically the same as the BIP45 scheme, except that you
have collapsed the "cosigner_index" and "change" fields into a single
field with the formula:

    combined = 2*cosigner_index + change

This removes one level from the hierarchy, but ultimately produces the
same number and type of chains as BIP45 (just addressed differently).

I kinda like the BIP45's approach of giving each field has its own
dedicated purpose. What is the motivation behind flattening the
hierarchy?

I ask because the wallet I work on, Airbitz, will be adding multi-sig
at some point in the future, and we need to figure out what kind of HD
tree structure we will be using. Our ideal structure would basically
be BIP 44 plus some "no-collision" logic:

    m / purpose' / coin_type' / wallet' / cosigner_index / change /
address_index

I feel like interoperability with Copay would be worth the extra HD
branch. Assuming Kefkius adds similar no-collision logic, his proposal
is pretty close to our ideal:

    m / purpose' / wallet' / coin_type / cosigner_index / change / address_index

Of course, I am open to hearing your thoughts on this as well.

-William

On Thu, Apr 9, 2015 at 3:37 PM, Alan Reiner <etotheipi@gmail.com> wrote:

BTW, I had originally proposed a "no-collision" scheme for
multi-signature wallets, which doesn't require modifying the key tree
structure at all, except for adding new internal and external chains
(2*N chains).  All siblings watch all chains, but only generate
receiving and change addresses on their two chains.

The original document is here, which might be educational for the
purposes of understand precisely the problem that needs a solution (and
mine is a different solution than BIP45).

https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf

I prefer not adding even more levels to the key tree, and (IMO) it makes
more sense to add more chains to the wallet instead of adding a new tree
level (as it allows for a simpler tree in the event that you don't need
separate cosigners).  But I suspect that there's a certain momentum
behind the cosigner-index method already in BIP45?  Just throwing it out
there.