script_type
currently in use.
@luke-jr @harding @hugohn
BIP 87: Hierarchy for Deterministic Multisig Wallets #1089
pull Rspigler wants to merge 30 commits into bitcoin:master from Rspigler:v2_Multisig_deriv changing 2 files +281 −0-
Rspigler commented at 5:14 am on March 22, 2021: contributor
-
Create Multisig Derivation Standard.mediawiki
Draft
-
Formatting a067f9ca08
-
Update and rename Multisig Derivation Standard.mediawiki to Modern Derivation Standard.mediawiki
Multisig and singlesig support
-
Update Modern Derivation Standard.mediawiki
minor edit
-
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
-
Merge pull request #1 from Rspigler/Sane_Mulitisg_deriv
[DRAFT] Modern Hierarchy for Deterministic Multisignature Wallets
-
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: contributorNot 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: contributorHow 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/*
andm/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
-
Update Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
Fix formatting
-
Update Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
Formatting
-
apoelstra commented at 2:38 pm on April 21, 2021: contributorIn 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?
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 doluke-jr commented at 8:08 pm on April 25, 2021: memberI 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: contributorMinor edits, + backwards compatibility 7ae9e025e8Merge pull request #3 from bitcoin/master
Update local
Add BSMS reference and key origin info 653b965f15in 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 fanquakeluke-jr renamed this:
BIP Proposal: Modern Hierarchy for Deterministic Multisignature Wallets
BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets
on May 14, 2021luke-jr added the label New BIP on May 14, 2021luke-jr commented at 10:55 pm on May 14, 2021: memberAssigned BIP number 87, please rename file and update READMEBIP 87 assigned cd223ea64aUpdate README.mediawiki 10e4bc6668Rename BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki to bip-0087.mediawiki 7e10290920luke-jr commented at 4:37 am on May 15, 2021: memberCI 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 42d7ae8c09Link to merged BSMS, update examples 9c40c18dbeChange name for CI 7663693310Rspigler renamed this:
BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets
BIP 87: Hierarchy for Deterministic Multisig Wallets
on May 15, 2021Minor edits and links d502f681b8Minor edit 2371906f02sipa 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, 2021luke-jr closed this on May 17, 2021
Rspigler commented at 1:42 am on May 18, 2021: contributorThanks!
github-metadata-mirror
This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 01:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me