BIP 87: Hierarchy for Deterministic Multisig Wallets

[Rspigler]

Updates derivation paths for descriptors, by removing the redundant script_type currently in use.

@luke-jr @harding @hugohn

[Sjors]

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]

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]

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]

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

[prusnak]

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]

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]

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]

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]

@Sjors @prusnak Addressed your concerns.

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

[apoelstra]

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

[luke-jr]

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

[luke-jr]

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

[Rspigler]

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]

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

[luke-jr]

Please move this to a Backward Compatibility section.

[Rspigler]

Will do

[Rspigler]

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

Also on Line 261

[philipglazman]

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

[Rspigler]

👍

[luke-jr]

Assigned BIP number 87, please rename file and update README

[luke-jr]

CI is failing:

bip-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)

[Rspigler]

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

[sipa]

@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]

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

[Rspigler]

Thanks!