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
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.
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.
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.
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.
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
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>
_MUSIG_ ==> _MUSIG2_
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>
<33 byte compressed pubkey> per the latest specs in bip-musig2-psbt, I think
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.
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>
[] 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
* notation that’s used for other fields. Although I think that would imply 0 .. n occurrences.
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.
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.
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.
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>
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.
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+
musig() nesting is forbidden (while musig() inside Script-based multisignatures/thresholds is fine).
musig(KEY, KEY, ..., KEY) expression can only be used inside of a tr() expression as a key expression.”
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.
0@@ -0,0 +1,79 @@
1+<pre>
2+ BIP: musig2-derivation
3+ Layer: Applications
4+ Title: Derivation Scheme for MuSig2 Aggregate Public Keys
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:
0This 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.
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:
0Multiple signers can create a single aggregate public key per MuSig2 that is indistinguishable
1from a random public key. The cosigners need a simple method for generating additional
2aggregate pubkeys to follow the best practice of using a new address for every payment.
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
0[[bip-0380.mediawiki|BIP 380]]. As these are a set of wholly new expressions, they are not compatible
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]
0Derivation from the aggregate pubkey can be assumed to follow [[bip-musig2-derivation:BIP-musig2-derivation]]
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:
0<tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field for its key, then it should add one using
1the <tt>NonceGen</tt> algorithm (or one of its variations) to produce a public
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>
PSBT_OUT_MUSIG2...?
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
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>
<33 byte plain aggregate pubkey>. I assume this should be a 33-byte compressed key as well? Same for PSBT_IN_MUSIG2_PARTIAL_SIG?
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>.
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>.
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.
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
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:
0| <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?
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.
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==
0==Backwards Compatibility==
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.
