This PR contains 3 proposed BIPs, the main contents of which were sent to the bitcoin-dev mailing list in October. There have been a few changes, notably the addition of a new BIP for the derivation methodology which was split from the descriptors BIP.
I've also changed the PSBT BIP to use 33 byte plain aggregate pubkeys rather than xonly.
I've also changed the PSBT BIP to use 33 byte plain aggregate pubkeys rather than xonly.
It would be helpful to document the reasoning in the commit msg or here in the PR to have a record of design decisions.
I've also changed the PSBT BIP to use 33 byte plain aggregate pubkeys rather than xonly.
It would be helpful to document the reasoning in the commit msg or here in the PR to have a record of design decisions.
I've added a rationale section which addresses this.
499 | +| MuSig2 Public Nonce 500 | +| <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1a</tt> 501 | +| <33 byte compressed pubkey> <32 byte xonlypubkey> <32 byte hash> 502 | +| The compressed public key of the particpant providing this nonce, followed by the X only public 503 | +key the participant is providing the nonce for, followed by the hash of the Taproot leaf script that 504 | +will be signed. Note that the second public key must be the key found in the script and not the
Why can't this be omitted like with with the partial signature?
It can be. This description is outdated, I've synced it with the one in bip-musig2-psbt
488 | +| <32 byte xonlypubkey> 489 | +| The MuSig2 aggregate X only public key from the <tt>KeyAgg</tt> algorithm. This key may or may not 490 | +be in the script directly. It may instead be a parent public key from which the public keys in the 491 | +script were derived. 492 | +| <tt><33 byte compressed pubkey>*</tt> 493 | +| A list of the compressed public keys of the particpants in the MuSig2 aggregate key in the correct order.
typo: participants
Fixed
647 | +| <33 byte compressed pubkey> 648 | +| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not be in 649 | +the script directly. It may instead be a parent public key from which the public keys in the script 650 | +were derived. 651 | +| <tt><33 byte compressed pubkey>*</tt> 652 | +| A list of the compressed public keys of the particpants in the MuSig2 aggregate key in the correct order.
typo: participants
Fixed
11 | + License: BSD-2-Clause 12 | +</pre> 13 | + 14 | +==Abstract== 15 | + 16 | +This document specifies a <tt>musig()</tt> key expression for output script descriptors.
Any reason why we don't call it musig2? I would be very confusing in the future if we get musig3() and now we have to explain that musig() means musig2.
The 2 is not a version number. It refers to the number of rounds of communication required. If it were a version number, then this would be musig3 (or higher), as IIRC musig-dn was actually the second variant.
I chose to use musig() since MuSig2 is the only variant in use currently, and I expect it to be the predominant variant of MuSig. If there are other variants in the future, we can be more specific for those, and I doubt that they would be numbered in the same way, considering that the number is not a version number.
34 | +the result would be a MuSig2 aggregate pubkey. 35 | + 36 | +However, it is much simpler to be able to derive from a single extended public key instead of having 37 | +to derive from many extended public keys and aggregate them. As MuSig2 produces a normal looking 38 | +public key, the aggregate public can be used in this way. This reduces the storage and computation 39 | +requirements for generating new aggregate pubkeys.
An additional benefit is that such wallets can be watched by a musig2-unaware wallet, or a tapleaf co-signer who does not need to know about the individual keys, by casting the tr(musig()) descriptor to tr(). Similarly it's compatible with the privacy-preserving rawtr descriptor (needs a BIP).
482 | @@ -483,6 +483,50 @@ The currently defined per-input types are defined as follows: 483 | | 0, 2 484 | | [[bip-0371.mediawiki|371]] 485 | |- 486 | +| MuSig2 Participant Public Keys 487 | +| <tt>PSBT_IN_MUSIG2_participant_PUBKEYS = 0x19</tt>
_participant_ should be in capital letters
Fixed
511 | +| 512 | +| 0, 2 513 | +| [[bip-musig2-psbt.mediawiki|musig2]] 514 | +|- 515 | +| MuSig2 Participant Partial Signature 516 | +| <tt>PSBT_IN_MUSIG_PARTIAL_SIG = 0x1b</tt>
typo: _MUSIG_ ==> _MUSIG2_
Fixed
482 | @@ -483,6 +483,50 @@ The currently defined per-input types are defined as follows: 483 | | 0, 2 484 | | [[bip-0371.mediawiki|371]] 485 | |- 486 | +| MuSig2 Participant Public Keys 487 | +| <tt>PSBT_IN_MUSIG2_participant_PUBKEYS = 0x19</tt> 488 | +| <32 byte xonlypubkey>
Should be <33 byte compressed pubkey> per the latest specs in bip-musig2-psbt, I think
Fixed
43 | +A synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting 44 | +the depth to 0, the child number to 0, and attaching a chaincode with the byte string 45 | +<tt>868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965</tt><ref>'''Where does this 46 | +constant chaincode come from?''' It is the SHA256 of the text <tt>MuSig2MuSig2MuSig2</tt></ref>. 47 | +This fixed chaincode should be used by all such synthetic xpubs following this specification. 48 | +Unhardend child public keys can be derived from the synthetic xpub as with any other xpub.
Typo: Unhardened
Fixed
I've made a minor change with the descriptors regarding sorting. Keys in a musig() can be specified in any order, but will be sorted prior to aggregation, similar to sortedmulti(). However for PSBTs, keys must be supplied in the expected order for aggregation (this is unchanged), which means sorting them if they weren't already.
I've made a minor change with the descriptors regarding sorting. Keys in a
musig()can be specified in any order, but will be sorted prior to aggregation, similar tosortedmulti(). However for PSBTs, keys must be supplied in the expected order for aggregation (this is unchanged), which means sorting them if they weren't already.
What is the rationale for this change? It seems to me that this complicates parsing/processing the descriptor unnecessarily. The only practical advantage I know of sortedmulti versus multi is that with multi an external observer can possibly fingerprint who signed different UTXOs even without knowing the descriptor; but that's not the case anyway for musig.
What is the rationale for this change?
I had a discussion involving @jonasnick and @sipa about this. Since BIP 327 suggests to do sorting, we decided it made sense to do in descriptors as well.
I had a discussion involving @jonasnick and @sipa about this. Since BIP 327 suggests to do sorting, we decided it made sense to do in descriptors as well.
BIP 327 discusses the possibility of sorting and describes a canonical sorting, but I didn't read it as 'suggesting' one way or another.
In general, I'd prefer maximum simplicity and less chances of malleability in descriptors, and this imho goes against both (albeit slightly, not a huge deal).
Note that this removes functionality, as one of $n! - 1$ of the $n!$ possible combinations become inexpressible with descriptors.
The functionality that I would suggest to consider for removal is derivation before aggregation: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022132.html
Unless there are use cases for it that I'm not aware of?
497 | +| 0, 2 498 | +| [[bip-musig2-psbt.mediawiki|musig2]] 499 | +|- 500 | +| MuSig2 Public Nonce 501 | +| <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1a</tt> 502 | +| <33 byte compressed pubkey> <32 byte xonlypubkey> <32 byte hash>
have you thought about putting [] or something around the final hash here to make it clear that it will be omitted if the aggregate key is either the taproot output key or the taproot internal key
+1 on this suggestion. Or use the * notation that's used for other fields. Although I think that would imply 0 .. n occurrences.
I've changed it to also say or omitted.
489 | +| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not 490 | +be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the 491 | +script were derived. 492 | +| <tt><33 byte compressed pubkey>*</tt> 493 | +| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order 494 | +required for aggregation. If sorting was done, then the keys must be in the sorted order.
the specification for the descriptor says that keys must be sorted with KeySort. If unsorted keys are allowed here, then its possible to have a psbt for a musig aggregate key that's not expressible in a descriptor. Maybe that's ok, just flagging it.
Yes, that is allowed. PSBTs is intentionally less restrictive than descriptors.
What's wrong with taking the ordering from the descriptor directly? That seems simpler and more flexible (Not that I can imagine a specific reason why a user would want a particular order).
Yes, that is allowed. PSBTs is intentionally less restrictive than descriptors.
makes sense, you want PSBTs to be a super-set of what you can express in a descriptor
What's wrong with taking the ordering from the descriptor directly? That seems simpler and more flexible (Not that I can imagine a specific reason why a user would want a particular order).
There's no descriptor in psbts.
Right I was commenting on KeySort-ing the participant keys in the descriptor. Seemed on-topic for this thread but I'll put the comment where it belongs.
33 | + 34 | +The <tt>musig(KEY, KEY, ..., KEY)</tt> expression can only be used inside of a <tt>tr()</tt> 35 | +expression as a key expression. The aggregate public key is produced by using the <tt>KeyAgg</tt> 36 | +algorithm on all KEYs specified in the expression after performing all specified derivation. As with 37 | +script expressions, KEY can contain child derivation specified by <tt>/*</tt>. A new aggregate 38 | +public key will be computed for each child index. Keys must be sorted with the <tt>KeySort</tt>
Why KeySort when we already have a explicit ordering from the descriptor? It seems like an unnecessary complication.
As I mentioned in #1540 (comment), there was a discussion about this and that was the conclusion. But I'm also having a hard time remembering the exact reason, maybe @jonasnick and/or @sipa can help me out here.
After talking about this again with @sipa, the conclusion is that philosophically, MuSig2 operates over a set of keys, so the order should not matter. For serialization as an implementation detail, it does, so having it sorted is a logical order for an ostensibly unordered set.
Another argument for sorting is to make the recovery process easier,. As we know from multisig usage that exists currently, users are often surprised to learn that they had to know more than just their key and their cosigners. By sorting, we can eliminate this as a concern. Ostensibly, users should be backing up their descriptors, but in practice, especially with the prevalance of hardware signers which espouse that only the seed needs to be backed up, I don't think that's something that happens that often.
The formatting seems to be in order on these documents. What is the status of the discussion on these proposals?
45 | +only unhardened derivation from the aggregate public key is allowed, and thus the derivation steps 46 | +following the <tt>musig()</tt> expression cannot contain 47 | +<tt>/NUMh</tt> or <tt>/NUM'</tt> derivation steps nor <tt>/*h</tt>, or <tt>/*'</tt> child derivation. 48 | +For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from 49 | +xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>. 50 | +
It might be worth mentioning explicitly that musig() nesting is forbidden (while musig() inside Script-based multisignatures/thresholds is fine).
I thought it was sufficiently implied by the above paragraph which states "The musig(KEY, KEY, ..., KEY) expression can only be used inside of a tr() expression as a key expression."
Since you can put musig() inside any fragment inside tr(), I think it's very easy to miss the fact that musig() itself is not a fragment, despite using a visually identical syntax. Especially since nesting musig() inside musig() is a natural thing that some people will surely want to do.
Added a sentence to make it explicit.
0 | @@ -0,0 +1,79 @@ 1 | +<pre> 2 | + BIP: musig2-derivation 3 | + Layer: Applications 4 | + Title: Derivation Scheme for MuSig2 Aggregate Public Keys
This title exceeds the length limit of 44 characters
Shorted to 44 characters
12 | +</pre> 13 | + 14 | +==Abstract== 15 | + 16 | +This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2 17 | +aggregate public key and how such keys should be used for key derivation.
How about:
This document proposes a BIP 32-based key derivation scheme using a BIP 327 MuSig2 aggregate public key as its starting point. The scheme only supports unhardened derivation.
No, the suggestion is simply incorrect. The derivation scheme is not "BIP 32 based", it is BIP 32. The aggregate pubkey is not a "starting point", I'm not sure what that even means in this context.
23 | +==Motivation== 24 | + 25 | +MuSig2 allows for multiple signers to create a single aggregate public key that is indistinguishable 26 | +from a random public key. However, as the best practice is to use a new address for every payment, 27 | +it is necessary for the cosigners of a single aggregate pubkey to have a way to produce additional 28 | +aggregate pubkeys.
This paragraph is a bit complicated. How about:
Multiple signers can create a single aggregate public key per MuSig2 that is indistinguishable
from a random public key. The cosigners need a simple method for generating additional
aggregate pubkeys to follow the best practice of using a new address for every payment.
Taken some parts of this.
I have taken a look at the first commit, MuSig2 BIP 32 derivation BIP.
I noticed a formatting issue and suggested a couple alternative phrasings. The language in this document feels a bit roundabout. Some parts of the Motivation that describe alternative designs would better fit the Rationale section. I would generally recommend the use of active voice in a specification document. It would be great if at least a first test vectors could be added.
I would recommend to split this PR to make each BIP a separate pull request.
It would be great if at least a first test vectors could be added.
Given that there are still a few active questions and some things may still end up being changed, I prefer to wait a bit longer before committing to the current specs with test vectors.
There are a few for the descriptors BIP.
I would recommend to split this PR to make each BIP a separate pull request.
This was considered originally, however there is a dependency on the derivation BIP from both the descriptor and psbt BIPs, so I'm not sure it makes sense to have them be separate.
BIP-0327 allows participant pubkeys to be duplicates.
Since the psbt fields are using the pubkeys (and not the signer's position in the MuSig) in order to identify the nonce/partial_sig contributions, and given that duplicate pubkeys are AFAIK of no practical value, musig() key expressions should perhaps explicitly forbid repeated pubkeys.
87 | +* <tt>musig()</tt> cannot have hardened child derivation: <tt>tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*h)</tt> 88 | + 89 | +==Backwards Compatibility== 90 | + 91 | +<tt>musig()</tt> expressions use the format and general operation specified in 92 | +[[bip-0380.mediawiki|380]]. As these are a set of wholly new expressions, they are not compatible
[[bip-0380.mediawiki|BIP 380]]. As these are a set of wholly new expressions, they are not compatible
Fixed
138 | + 139 | +If the public key found was derived from an aggregate public key, then all MuSig2 PSBT fields for 140 | +that public key should contain the aggregate public key rather than the found pubkey itself. The 141 | +updater should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> that contains the derivation path used 142 | +to derive the found pubkey from the aggregate pubkey. 143 | +Derivation from the aggregate pubkey can be assumed to follow [[bip-musig2-derivation:BIP-musig2-derivation]
Derivation from the aggregate pubkey can be assumed to follow [[bip-musig2-derivation:BIP-musig2-derivation]]
Fixed
156 | +appear in as a participant in <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt>. 157 | + 158 | +For each aggregate public key that the signer is a participant of that it wants 159 | +to produce a signature for, if the signer does not find an existing 160 | +<tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field for its key, then it should add one use 161 | +the <tt>NonceGen</tt> algorithm (or one of its variations) to produce a public
I think there is something wrong here. Did you mean:
<tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field for its key, then it should add one using
the <tt>NonceGen</tt> algorithm (or one of its variations) to produce a public
Fixed
Let’s call these: • BIP 328: Derivation Scheme for MuSig2 Aggregate Keys • BIP 373: MuSig2 PSBT Fields • BIP 390: musig() Descriptor Key Expression
Updated with assigned numbers
643 | @@ -599,6 +644,20 @@ determine which outputs are change outputs and verify that the change is returni 644 | | 0, 2 645 | | [[bip-0371.mediawiki|371]] 646 | |- 647 | +| MuSig2 Participant Public Keys 648 | +| <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
Should say PSBT_OUT_MUSIG2...?
Fixed
516 | +| MuSig2 Participant Partial Signature 517 | +| <tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt> 518 | +| <33 byte compressed pubkey> <32 byte xonlypubkey> <32 byte hash or omitted> 519 | +| The compressed public key of the participant providing this partial signature, followed by the plain aggregate public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash 520 | +of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or 521 | +the taproot output key, then the tapleaf hash must be omitted. Note that the second public key must
I'm not sure I understand the sentence "Note that the second public key must be...". Does this relate to parent/child key relationships? I assume it does not mean the key must be the (tweaked) Taproot key of the script, since the first sentence mentions it being the "plain aggregate" public key. The sentence is probably fine and my question here just means I need to read up on the whole parent/child key derivation scheme...
No, it's "second public key" as in the second public key in the keydata.
This is unrelated to derivation. I've changed the wording a little bit to try to make this clearer.
497 | +| 0, 2 498 | +| [[bip-0373.mediawiki|373]] 499 | +|- 500 | +| MuSig2 Public Nonce 501 | +| <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt> 502 | +| <33 byte compressed pubkey> <32 byte xonlypubkey> <32 byte hash>
In the standalone BIP file below the second key is described as <33 byte plain aggregate pubkey>. I assume this should be a 33-byte compressed key as well? Same for PSBT_IN_MUSIG2_PARTIAL_SIG?
Fixed.
ACK 1542fda1cafb153fcccc07ccbc74d2b8862e12e4
40 | +==Specification== 41 | + 42 | +A synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting 43 | +the depth to 0, the child number to 0, and attaching a chaincode with the byte string 44 | +<tt>868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965</tt><ref>'''Where does this 45 | +constant chaincode come from?''' It is the SHA256 of the text <tt>MuSig2MuSig2MuSig2</tt></ref>.
Maybe this is obvious, but perhaps it is worth mentioning that if the BIP 327 aggregate public key is revealed by any participant, the fixed chaincode would enable any third party to link the child keys to the aggregate public key, so the participants should ensure that they keep the MuSig2 plain aggregate public key private.
Added a sentence that the aggregate pubkey has the same privacy concerns as normal xpubs.
45 | +[[bip-0328.mediawiki|BIP 328]]. As there is no aggregate private key, 46 | +only unhardened derivation from the aggregate public key is allowed, and thus the derivation steps 47 | +following the <tt>musig()</tt> expression cannot contain 48 | +<tt>/NUMh</tt> or <tt>/NUM'</tt> derivation steps nor <tt>/*h</tt>, or <tt>/*'</tt> child derivation. 49 | +For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from 50 | +xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>.
Given that the first block appears to allow child derivation for KEY expressions, and the second block does not, perhaps it would make sense to split these two into separate sections with their own titles?
Added subsections.
21 | +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. 22 | + 23 | +==Motivation== 24 | + 25 | +BIP 327 introduces the MuSig2 Multi-Signature scheme. It is useful to have a way for keys to be used 26 | +in a MuSig2 aggregate key to be expressed in descriptors so that wallets can more easily use MuSig2.
I noticed that this BIP does not have a rationale section. Were there any relevant design decisions or potential alternate designs that should be documented?
Originally there weren't, however, given the previous discussion about sorting, I've added a rationale for that.
72 | +| rowspan="2"| 73 | +| rowspan="2"| 74 | +| rowspan="2"| 0, 2 75 | +|- 76 | +| The compressed public key of the participant providing this nonce, followed by the plain public 77 | +key the participant is providing the nonce for, followed by the hash of the BIP 341 tapleaf hash of
Do you actually mean the "hash of the hash" or just the tapleaf hash?
Fixed.
66 | +required for aggregation. If sorting was done, then the keys must be in the sorted order. 67 | +|- 68 | +| rowspan="2"|MuSig2 Public Nonce 69 | +| rowspan="2"|<tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt> 70 | +| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt> 71 | +| <tt><66 byte public nonces</tt>
Missing closing bracket:
| <tt><66 byte public nonces></tt>
Also, the text seems to talk about a single nonce being provided, but the data field refers to multiple nonces. Should this be singular?
Fixed
77 | +key the participant is providing the nonce for, followed by the hash of the BIP 341 tapleaf hash of 78 | +the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the 79 | +taproot output key, then the tapleaf hash must be omitted. The plain public key must be 80 | +the key found in the script and not the aggregate public key that it was derived from, if it was 81 | +derived from an aggregate key. 82 | +| The public nonces produced by the <tt>NonceGen</tt> algorithm.
Should this be singular "nonce"?
Fixed
182 | +already been done. 183 | + 184 | +Otherwise, the resulting signature is a BIP 340 compatible signature and finalizers should treat it 185 | +as such. 186 | + 187 | +==Compatibility==
==Backwards Compatibility==
Done
I did a full read-through of all three BIPs. I noted a few open questions and minor formatting suggestions. I noticed that some of the proposals do not go into detail on design decisions, alternate designs that were considered or related work. While the proposals seem straightforward, I thought I mentioned it in case there are things to be added to the rationale section that were forgotten.
It’s not clear to me whether the presence of test vectors would be necessary for the specification to be considered complete, and I noticed that this PR and the mailing list post got little discussion so far. It seems obvious to me that all of these proposals are relevant, so I was wondering whether you would like us to wait for more review or the addition of test vectors before considering merging, or whether you consider this PR ready to be merged—regarding the formal criteria for BIPs, these seem ready to go.
and given that duplicate pubkeys are AFAIK of no practical value,
musig()key expressions should perhaps explicitly forbid repeated pubkeys.
Added a sentence for that.
It’s not clear to me whether the presence of test vectors would be necessary for the specification to be considered complete,
That's not been an issue before. Previous draft proposals have been merged without test vectors completed yet.
I was wondering whether you would like us to wait for more review or the addition of test vectors before considering merging, or whether you consider this PR ready to be merged—regarding the formal criteria for BIPs, these seem ready to go.
I consider these ready for merging.
