BIP 87: Hierarchy for Deterministic Multisig Wallets

Rspigler commented at 5:14 am on March 22, 2021: contributor

Updates derivation paths for descriptors, by removing the redundant script_type currently in use. @luke-jr @harding @hugohn

Create Multisig Derivation Standard.mediawiki

Draft

675c3a8703

Formatting a067f9ca08

Update and rename Multisig Derivation Standard.mediawiki to Modern Derivation Standard.mediawiki

Multisig and singlesig support

ef3a16eeec

Update Modern Derivation Standard.mediawiki

minor edit

c747ee9880

Clarify testnets deba2a75be

Revert to multisig only 8c346ca3ba

Add PSBT and ML reference b4af07c8a7

Clarifications f4cea61a4e

BIP2 compliance. Add rationale, addresss discovery, etc. 73dce7aafc

Formatting ba9f775ef6

Merge pull request #2 from bitcoin/master

Update local

5161601435

Merge pull request #1 from Rspigler/Sane_Mulitisg_deriv

[DRAFT] Modern Hierarchy for Deterministic Multisignature Wallets

1361af2f73

Grammar/formatting 453d328265

Fix errors b1c2b5c671

Formatting c7cd5e990b

Sjors commented at 10:16 am on April 12, 2021: member

This seems like a nice simplification. The key distinction here is that users are expected to store the wallet descriptors along with the seed.

I don’t know if this is flexible enough for wallets that need additional derivations, e.g. for nonces in schemes like https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6

It might be fine to just create another BIP when that becomes a problem, but then perhaps this BIP should get a more narrow scope.

Rspigler commented at 7:08 pm on April 12, 2021: contributor

This seems like a nice simplification

Thanks!

The key distinction here is that users are expected to store the wallet descriptors along with the seed.

Yes, in a multisig setup, every user has to store every other cosigner’s xpub anyway, so they might as well do so via the descriptor (since it provides this information in a standardized format, with the benefit of key origin information and error detection)

I don’t know if this is flexible enough for wallets that need additional derivations, e.g. for nonces in schemes

I understand the concept of MuSig-DN, but not its implementation details unfortunately. I didn’t realize that the nonces would be a level in the BIP32 path?

Sjors commented at 7:40 pm on April 12, 2021: member

Yes, in a multisig setup, every user has to store every other cosigner’s xpub anyway

Ideally yes, but the current “BIP48” approach has the benefit of being able to recover using only the mnemonics and the threshold. This BIP would drop that ability. That’s OK, but it’s useful to point out the trade-off.

I didn’t realize that the nonces would be a level in the BIP32 path?

I don’t know if that’s the case. Perhaps they can be derived from the private key. I haven’t read the blog in enough detail.

Rspigler commented at 7:50 pm on April 12, 2021: contributor

Not ideally - necessary. You need the threshold # of mnemonics and all xpubs to recover funds.

Rspigler cross-referenced this on Apr 12, 2021 from issue wallet: Multi-sig flow with descriptor wallets by laanwj

prusnak commented at 9:31 pm on April 12, 2021: contributor

How is the descriptor wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum going to find all external and all change addresses of the wallet? (m/XY'/0'/0'/0/* and m/XY'/0'/0'/1/*)

Rspigler commented at 10:46 pm on April 12, 2021: contributor

That’s hardware/software specific, and doesn’t affect this BIP. Again, this is an ongoing debate/conversation

Most hardware wallets and coordinators use a single parent descriptor, and expand it locally for change and receive addresses. In BSMS, the parent descriptor is used, and a list of accepted derivation paths that the Signers can use to generate addresses are included. If someone else wants to use a descriptor each for change and receive addresses, that works too (although I think there are serious usability issues).

Regardless, it doesn’t affect this BIP/how co-signers generate keys.

Sjors commented at 11:37 am on April 13, 2021: member

Not ideally - necessary. You need the threshold # of mnemonics and all xpubs to recover funds.

You can derive xpubs from the mnemonics if you use the BIP48 convention and stick to account 0. The threshold is trivial to remember or can be found with trial and error. You do need all of them, which is of course another disadvantage of that mechanism compared to just backing up descriptors.

Rspigler commented at 8:43 pm on April 13, 2021: contributor

You can derive xpubs from the mnemonics

Of course, but then you’ve lost the entire purpose of multisig if you rely on this. If you set up an M-of-N wallet, and you store only the mnemonics, the moment you have only N-1 mnemonic, you’ve lost your funds. You need M mnemonics and N public keys (you don’t know which M mnemonics you will use to restore, so you can’t rely on deriving the xpubs).

You might as well store this information as a standardized, single descriptor. Under BSMS every Signer (software or hardware) must be able to display this information to the user. Users should back this up just like they do the mnemonic.

There’s no reason generating the xprv should have anything to do with the script type

Rspigler cross-referenced this on Apr 18, 2021 from issue BIP 129: Bitcoin Secure Multisig Setup (BSMS) by hugohn

Update Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki

Some minor fixes, address gap fixes, backup clarification

d95aa3329d

Update Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki

Fix formatting

25bacdc21d

Update Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki

Formatting

f18ddfbfa5

Rspigler commented at 10:14 pm on April 19, 2021: contributor

@Sjors @prusnak Addressed your concerns.

Way too many commits. So likely will squash at some point. I would recommend just viewing the file

apoelstra commented at 2:38 pm on April 21, 2021: contributor

In Musig-DN (and in RFC6979) you can derive nonces just from the private key.

Address Discovery Fixes ccc8af43b0

in Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki:26 in ccc8af43b0 outdated

21+
22+This BIP is licensed under the 2-clause BSD license.
23+
24+==Motivation==
25+
26+With the increase of more user friendly (offline) multisignature wallets, and adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transactions)], it is necessary to create a common derivation scheme that makes use of all new technologies.

luke-jr commented at 7:50 pm on April 25, 2021:

Currently the descriptor language is wallet-specific - it should probably be made a BIP before relying on it.

Rspigler commented at 3:22 am on April 26, 2021:

I think a BIP could be very helpful, seeing how all wallets will likely (or should) be moving towards this direction. Are you saying a Descriptor-BIP is a blocker for this?

Rspigler commented at 3:26 am on April 26, 2021:

Tagging @sipa , as I believe he is the author of the descriptor language

in Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki:55 in ccc8af43b0 outdated

50+
51+Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script.  While it attempts to reduce maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, <code>script_type</code> list.
52+
53+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type <ref>'''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection.</ref>.
54+
55+Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.

luke-jr commented at 7:51 pm on April 25, 2021:

Please move this to a Backward Compatibility section.

Rspigler commented at 3:27 am on April 26, 2021:

Will do

luke-jr commented at 8:08 pm on April 25, 2021: member

I thought I’ve seen dev ML discussion of this, but searching isn’t coming up with it. Can you link me?

Rspigler commented at 3:27 am on April 26, 2021: contributor

@luke-jr : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html

Also on Line 261

Minor edits, + backwards compatibility 7ae9e025e8

Merge pull request #3 from bitcoin/master

Update local

4794d70c5e

Add BSMS reference and key origin info 653b965f15

in Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki:125 in 4794d70c5e outdated

120+
121+Public derivation is used at this level.
122+
123+==Address Discovery==
124+
125+The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses.

philipglazman commented at 5:11 am on April 26, 2021:

Would be nice to explicitly require the descriptor template to include key origin information since it is useful for the PSBT creator.

Rspigler commented at 6:29 pm on April 26, 2021:

:+1:

Rspigler cross-referenced this on May 13, 2021 from issue offline / multisig UX by fanquake

luke-jr renamed this:
~~BIP Proposal: Modern Hierarchy for Deterministic Multisignature Wallets~~
BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets
on May 14, 2021

luke-jr added the label New BIP on May 14, 2021

luke-jr commented at 10:55 pm on May 14, 2021: member

Assigned BIP number 87, please rename file and update README

BIP 87 assigned cd223ea64a

Update README.mediawiki 10e4bc6668

Rename BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki to bip-0087.mediawiki 7e10290920

luke-jr commented at 4:37 am on May 15, 2021: member

CI is failing:

0bip-0087.mediawiki has too-long TItle (57 > 44 char max) at scripts/buildtable.pl line 128, <$F> line 4.

Suggest dropping “Modern”, since that’s relative to present time. (Note that will only get it down to 51 characters; an additional 7 still need to go)

Merge branch 'bitcoin:master' into v2_Multisig_deriv 42d7ae8c09

Link to merged BSMS, update examples 9c40c18dbe

Change name for CI 7663693310

Rspigler renamed this:
~~BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets~~
BIP 87: Hierarchy for Deterministic Multisig Wallets
on May 15, 2021

Minor edits and links d502f681b8

Minor edit 2371906f02

Rspigler commented at 5:31 am on May 15, 2021: contributor

@luke-jr sorry, not sure what the issue is now

sipa commented at 3:11 pm on May 15, 2021: member

@Sjors MuSig-DN needs a different kind of keys for nonce derivation (it doesn’t even use the same secp256k1 for that). I think it’s unlikely that those will be integrated into descriptors in common software - it’s pretty complex unfortunately.

MuSig2 is a lot simpler, but it relies on (actual) randomness or state in the signers.

luke-jr merged this on May 17, 2021

luke-jr closed this on May 17, 2021

luke-jr commented at 11:29 pm on May 17, 2021: member

@Rspigler The colours were incorrect in your README. Fixed them for you.

Rspigler commented at 1:42 am on May 18, 2021: contributor

Thanks!

BIP 87: Hierarchy for Deterministic Multisig Wallets #1089