HD Multisig derivation standard

Fonta1n3 commented at 1:40 pm on February 24, 2021: contributor

This PR is a proposal for a new BIP to define a standard on m/48’ derivation paths used in modern day hierarchical deterministic multi-sig wallets.

Create bip-0048.mediawiki e6b9822142

fixes c9517ecf87

typo 23d57cb9ad

minor 42b9148cea

Update bip-0048.mediawiki ff04f6cea4

Mention BIP 44 as the Multi-Account standard bfebc4b047

Update bip-0048.mediawiki 4e81e16224

Fix the table 9ec6bf64b7

Update bip-0048.mediawiki eae5288ffd

Merge pull request #1 from ben-kaufman/patch-1

Mention BIP 44 as the Multi-Account standard

3664283eb4

remove bip44 stuff 38096cedd9

fix: remove legacy references 86e77903ba

fix: define motivation, remove account creation blurb. bf8c208da5

fix: bip number not actually assigned 32d6ee217a

Fonta1n3 marked this as a draft on Feb 24, 2021

Fonta1n3 marked this as ready for review on Feb 24, 2021

Merge remote-tracking branch 'upstream/master' 787ed87ff3

ramsemune approved

devrandom commented at 7:16 pm on February 26, 2021: contributor

stray file .DS_Store

fix: this is specific to an existing standard only dd3033f0dd

fix: update to provide for future extensibility 8a3a8bd042

fix: typo 0b667770d8

in bip-0048.mediawiki:87 in dd3033f0dd outdated

83@@ -84,7 +84,7 @@ Hardened derivation is used at this level.
84 ===Script===
85 
86 This level splits the key space into two separate <code>script_type</code>(s). To provide
87-backward and forward compatibility.
88+backward compatibility.

SomberNight commented at 8:12 am on February 27, 2021:

I have originally added the script_type level for forward compatibility. Specifically to avoid a BIP44/49/84 scenario, that is, to avoid creating a new BIP every time we wanted to use new type of scripts – instead I thought it’s easier to maintain a list of script types.

from https://github.com/spesmilo/electrum/issues/4352#issue-321556261 :

The advantage would be that when new script types come later (e.g. Schnorr-like sigs), no new BIP would be needed.

There is another solution, which is to e.g. hash a descriptor or similar of the script type template to arrive at a derivation path level; then a single BIP would be enough; though that might make disaster-recovery problematic – but this too requires its own script_type level.

SomberNight commented at 8:18 am on February 27, 2021:

Also, arguably there is no backward compatibility provided at all. What exactly is this backward compatible with? I guess you mean the wallets that are using this same spec before it was formally specced (here), but as you don’t add anything new, just formalise it, that is just self-referential.

Fonta1n3 commented at 1:28 am on February 28, 2021:

Hey, I have added some simple text around future script types and extensibility in https://github.com/bitcoin/bips/pull/1072/commits/8a3a8bd04279537066a504de1211a7fb48087526, does that work?

SomberNight commented at 2:03 am on February 28, 2021:

Yes, thanks. I personally like this approach better; though I guess it might be subjective. (re new BIP every time vs maintaining list of script types.) I prefer the wording to express the original intention, to explain why it was done like this.

Rspigler commented at 9:47 pm on February 28, 2021: contributor

I don’t understand the purpose of this BIP. The stated goal is to not need a BIP for new script types, but you then still need to maintain a list of script types for the script_type path, so it’s not actually reducing maintainability, and in doing so, the derivation path would then have the script type included, instead of just being in the descriptor, which is unnecessarily messy IMO. It seems to be a standard for describing current bad practices instead of a standard of how wallets should behave

Fonta1n3 commented at 1:57 am on March 1, 2021: contributor

I don’t understand the purpose of this BIP. The stated goal is to not need a BIP for new script types, but you then still need to maintain a list of script types for the script_type path, so it’s not actually reducing maintainability, and in doing so, the derivation path would then have the script type included, instead of just being in the descriptor, which is unnecessarily messy IMO. It seems to be a standard for describing current bad practices instead of a standard of how wallets should behave

Hi Robert,

The stated goal is:

0This PR is a proposal for a new BIP to define a standard on m/48' derivation paths used in modern day hierarchical deterministic multi-sig wallets.

0The motivation of this BIP is to define the existing industry wide practice of utilizing m/48' derivation paths in hierarchical deterministic multi-sig wallets so that other developers may benefit from a standard. This BIP allows for future script types to easily be appended to the specification so that a new BIP is not required for every future script type.
1
2The hierarchy proposed in this paper is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, multiple script types and millions of addresses per chain.
3
4This paper was inspired from BIP44.

It is absolutely for the purpose of describing existing standard that are in use across all modern segwit HD multisig wallets and also provides future extensibility. @SomberNight is the original creator of the m/48’ derivation. He had commented here so I amended the BIP to stay true to the original vision of allowing for future script types.

You can absolutely “just include a descriptor” (in your application) as descriptors include the derivation path. This BIP gives devs a standard to follow for which derivations they should use in their output descriptors for segwit (currently) multi-sig wallets. Similarly to what BIP44, 84, 49 achieve for single-sig.

Rspigler commented at 2:45 am on March 1, 2021: contributor

Multisig wallets should be created using descriptors, which contain the script type, (sorted) multi, key origin identification, xpubs, and checksum. The descriptor should be created using parameters like ‘M’, ‘N’, script type, and by gathering keys from co-signers in the descriptor format of master key fingerprint, BIP44/49/84/Future_Tapscript derivation path, xpub. There’s no reason to use BIP45, or to create a ‘future proof’ BIP45 ie BIP48.

Fonta1n3 commented at 3:11 am on March 1, 2021: contributor

Multisig wallets should be created using descriptors, which contain the script type, (sorted) multi, key origin identification, xpubs, and checksum. The descriptor should be created using parameters like ‘M’, ‘N’, script type, and by gathering keys from co-signers in the descriptor format of master key fingerprint, BIP44/49/84/Future_Tapscript derivation path, xpub. There’s no reason to use BIP45, or to create a ‘future proof’ BIP45 ie BIP48.

Other then the fact that many wallets do use bip45 and m/48' and yet we have do not have a standard for m/48' which is the purpose of this BIP.

Specter, Sparrow, Electrum, Coldcard, Trezor, Ledger, Fully Noded, Gordian Wallet, Nunchuk (and others) all use the m/48' derivation as it is the only derivation path we have for HD segwit multi-sig wallets. If you are using bip44/84/49 in your multisig descriptors then you are doing it wrong as those are single-sig derivs.

Rspigler commented at 7:06 am on March 1, 2021: contributor

If you are using bip44/84/49 in your multisig descriptors then you are doing it wrong as those are single-sig derivs.

Yes, I meant in the same way BIP44 was done - with a BIP per script. I don’t see why we should be encouraging mixing scripts and keys by creating a BIP45 with a script_type. There’s also no reason to have a cosigner_index, since that requires that each cosigner send to each other their purpose' public key before being able to create their full derivation path of the key, which merely adds unnecessary communication rounds when the coordinator can use sortedmulti in the descriptor.

BIP48 doesn’t have a cosigner_index, but if we want to create a HD Multisig derivation standard of how wallets should behave, rather than how they currently behave, we should remove script_type as well (and rename it to something different from BIP48).

Fonta1n3 commented at 7:26 am on March 1, 2021: contributor

If you are using bip44/84/49 in your multisig descriptors then you are doing it wrong as those are single-sig derivs.

Yes, I meant in the same way BIP44 was done - with a BIP per script. I don’t see why we should be encouraging mixing scripts and keys by creating a BIP45 with a script_type. There’s also no reason to have a cosigner_index, since that requires that each cosigner send to each other their purpose' public key before being able to create their full derivation path of the key, which merely adds unnecessary communication rounds when the coordinator can use sortedmulti in the descriptor.

BIP48 doesn’t have a cosigner_index, but if we want to create a HD Multisig derivation standard of how wallets should behave, rather than how they currently behave, we should remove script_type as well (and rename it to something different from BIP48).

As I’ve made extremely clear this is to define an existing standard that is already in use and also provides extensibility in case the community wants to extend upon it. Removingscript_type will cause “loss of funds” and break compatibility with existing multisig wallets.

If you want to define a standard for what “should” be used in HD multisig wallets and remove script_type then a separate BIP would be appropriate.

doc-hex commented at 4:06 pm on April 19, 2021: none

Datapoint: Coldcard Wallet supports this BIP (always has) and as of v4.0.3 will support varied account numbers.

luke-jr added the label New BIP on Apr 23, 2021

luke-jr changes_requested

luke-jr commented at 2:03 am on April 25, 2021: member

Please:

drop the .DS_Store file.
add a section on backward compatibility, especially with current use of purpose 48.
follow the format described in BIP 2’s “BIP format and structure”.
choose a copyright license and add the relevant metadata.

It might also be a good idea to document script type 0.

Update bip-0048.mediawiki

- Replace BIP number with ?
- Reduce title to less then 44 characters
- Add MIT Licence and copyright section
- Add specification section
- Add backwards compatibility section

1eb8a3ca4d

Update bip-0048.mediawiki c3c0abd44d

Fonta1n3 commented at 1:54 am on July 20, 2021: contributor

Please:

drop the .DS_Store file.

add a section on backward compatibility, especially with current use of purpose 48.

follow the format described in BIP 2’s “BIP format and structure”.

choose a copyright license and add the relevant metadata.

It might also be a good idea to document script type 0.

Hi Luke,

I went ahead and made the requested changes. If I did not do it correctly just let me know.

afaik script type 0 is not actually used as per @SomberNight (original creator of this derivation scheme), instead wallets use BIP45 for legacy multi-sig scripts.

Delete .DS_Store bc05931332

Update bip-0048.mediawiki 20c5af58f1

Rspigler commented at 2:53 am on July 20, 2021: contributor

Strong NACK - Bitcoin is moving away from this (layer violations) and towards descriptors. This is also redundant with BIP 87

Update bip-0048.mediawiki 90cb1c8906

Update bip-0048.mediawiki

Add code snippets.

84e14b68a6

craigraw commented at 7:15 am on July 20, 2021: contributor

Strong NACK - Bitcoin is moving away from this (layer violations) and towards descriptors. This is also redundant with BIP 87

As pointed out above, this is simply documenting the existing system which is already widely used. Also, I think you misunderstand the process. For a BIP number to be assigned, the BIP proposal merely needs to be formatted correctly and technically sound (as in could be implemented). Clearly the latter is already true, therefore it is just a matter of the former.

Rspigler commented at 5:24 pm on July 20, 2021: contributor

I understand the BIP process (for example, see BIP-101 and BIP-102). Anyone can make a proposal that won’t be implemented in any project in a couple years. I just believe it’s a better use of time to work forwards rather than backwards.

Fix BIP 48 headers and add to README 03f2d744d3

luke-jr merged this on Jul 20, 2021

luke-jr closed this on Jul 20, 2021

Hbutlercapone commented at 3:39 am on August 25, 2021: none

Approve merge request #1072

Hbutlercapone commented at 3:43 am on August 25, 2021: none

Looks great, Approve #1072

HD Multisig derivation standard #1072