I have written a new BIP describing a BIP32 derivation path that supports a 
single or multi-signature and multi-coin wallet from a single master seed.  It 
combines BIP44 and BIP45 and adds in a self-describing structure in the 
derivation path for multiple multi-sig combinations within the single wallet 
along with an extended public key export file format for public key 
distribution between parties.  I can particularly see this being useful for 
multiple Lightning Network 2of2 accounts for different payment channels.

The BIP can be found here: 

I appreciate that this might be re-hashing old ground as BIP44 in particular 
has been widely adopted, however, BIP44 does leave itself open to a lot of 
interpretation from a wallet portability perspective such as:

- What address format is expected when discovering balances and creating 
- Does the master seed represent a single-sig or multi-sig wallet?
- If multi-sig, how many cosigners and what are their extended public keys (so 
that the wallet can generate the correctly formatted redeem script with public 
keys in the right order)?
- If multi-sig, how do you prevent collisions on the same address index (in a 
wallet that is occasionally connected)?

BIP45 solves the collision that occurs when the individual parties in a 
multi-sig group each give out a new address from a wallet, where the wallet 
hasn't been able to sync to mark the address as 'used' (this could happen if 
they gave out addresses independently at the same time).  It uses a cosigner 
index in the derivation path so that each party has their own path to their 
addresses.  However, BIP45 drops the multi-coin support that BIP44 has.

This is a useful discussion on the problems of a collision and the merits of 
separating cosigners in the derivation path: 

For the purposes of the BIP text (and the example paths used to generate keys) 
I've temporarily assigned it the number 46.  It looks like that is available 
and seemed somewhat appropriate given that it builds on the good work of BIP44 
and BIP45.

Paul Brown

bitcoin-dev mailing list

Reply via email to