Skip to content

Commit 693e30e

Browse files
achow101achow101
committed
MuSig2 PSBT Fields BIP
1 parent c17ba2f commit 693e30e

File tree

3 files changed

+281
-0
lines changed

3 files changed

+281
-0
lines changed

‎README.mediawiki‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1176,6 +1176,13 @@ Those proposing changes should consider that ultimately consent may rest with th
11761176
| Ava Chow
11771177
| Informational
11781178
| Draft
1179+
|-
1180+
| [[bip-musig2-psbt.mediawiki|musig2-psbt]]
1181+
| Applications
1182+
| MuSig2 PSBT Fields
1183+
| Ava Chow
1184+
| Informational
1185+
| Draft
11791186
|}
11801187

11811188
<!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! -->

‎bip-0174.mediawiki‎

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -483,6 +483,51 @@ The currently defined per-input types are defined as follows:
483483
| 0, 2
484484
| [[bip-0371.mediawiki|371]]
485485
|-
486+
| MuSig2 Participant Public Keys
487+
| <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt>
488+
| <33 byte plain aggregate pubkey>
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.
495+
|
496+
|
497+
| 0, 2
498+
| [[bip-musig2-psbt.mediawiki|musig2]]
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>
503+
| The compressed public key of the participant providing this nonce, followed by the plain aggregate public
504+
key the participant is providing the nonce for, followed by the hash of the BIP 341 tapleaf hash of
505+
the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the
506+
taproot output key, then the tapleaf hash must be omitted. Note that the second public key must be
507+
the key found in the script and not the aggregate public key that it was derived from, if it was
508+
derived from an aggregate key.
509+
| <tt><66 byte public nonces</tt>
510+
| The public nonces produced by the <tt>NonceGen</tt> algorithm.
511+
|
512+
|
513+
| 0, 2
514+
| [[bip-musig2-psbt.mediawiki|musig2]]
515+
|-
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
522+
be the key found in the script and not the aggregate public key that it was derived from, if it was
523+
derived from an aggregate key.
524+
| <tt><32 byte partial signature></tt>
525+
| The partial signature produced by the <tt>Sign</tt> algorithm.
526+
|
527+
|
528+
| 0, 2
529+
| [[bip-musig2-psbt.mediawiki|musig2]]
530+
|-
486531
| Proprietary Use Type
487532
| <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
488533
| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>
@@ -599,6 +644,20 @@ determine which outputs are change outputs and verify that the change is returni
599644
| 0, 2
600645
| [[bip-0371.mediawiki|371]]
601646
|-
647+
| MuSig2 Participant Public Keys
648+
| <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
649+
| <33 byte plain aggregate pubkey>
650+
| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
651+
be in the script directly. It may instead be a parent public key from which the public keys in the
652+
script were derived.
653+
| <tt><33 byte compressed pubkey>*</tt>
654+
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
655+
required for aggregation. If sorting was done, then the keys must be in the sorted order.
656+
|
657+
|
658+
| 0, 2
659+
| [[bip-musig2-psbt.mediawiki|musig2]]
660+
|-
602661
| Proprietary Use Type
603662
| <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
604663
| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>

‎bip-musig2-psbt.mediawiki‎

Lines changed: 215 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,215 @@
1+
<pre>
2+
BIP: musig2-psbt
3+
Layer: Applications
4+
Title: MuSig2 PSBT Fields
5+
Author: Ava Chow <[email protected]>
6+
Comments-Summary: No comments yet.
7+
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-musig2-psbt
8+
Status: Draft
9+
Type: Standards Track
10+
Created: 2024-01-15
11+
License: CC0-1.0
12+
</pre>
13+
14+
==Introduction==
15+
16+
===Abstract===
17+
18+
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP
19+
327 MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for
20+
the participants' keys, the public nonces, and the partial signatures produced with MuSig2.
21+
22+
===Copyright===
23+
24+
This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
25+
26+
===Motivation===
27+
28+
BIP 327 specifies a way to create BIP 340 compatible public keys and signatures using the MuSig2
29+
Multi-Signature scheme. The existing PSBT fields are unable to support MuSig2 as it introduces new
30+
concepts and additional rounds of communication. Therefore new fields must be defined to allow PSBTs
31+
to carry the information necessary to produce a valid signature with MuSig2.
32+
33+
==Specification==
34+
35+
The new per-input types are defined as follows:
36+
37+
{|
38+
! Name
39+
! <tt><keytype></tt>
40+
! <tt><keydata></tt>
41+
! <tt><valuedata></tt>
42+
! Versions Requiring Inclusion
43+
! Versions Requiring Exclusion
44+
! Versions Allowing Inclusion
45+
|-
46+
| rowspan="2"|MuSig2 Participant Public Keys
47+
| rowspan="2"|<tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt>
48+
| <tt><33 byte plain aggregate pubkey></tt>
49+
| <tt><33 byte compressed pubkey>*</tt>
50+
| rowspan="2"|
51+
| rowspan="2"|
52+
| rowspan="2"| 0, 2
53+
|-
54+
| The MuSig2 aggregate plain public key<ref>'''Why the plain aggregate public key instead of x-only?'''
55+
BIP 32 requires public keys to include their evenness byte. Aggregate public keys are expected to be
56+
derived from, following [[bip-musig2-derivation.mediawiki|BIP-musig2-derivation]], and therefore will
57+
need to include the evenness. Furthermore, PSBT_IN_TAP_BIP32_DERIVATION fields include fingerprints
58+
to identify master keys, and these fingerprints require full compressed public keys. By including
59+
the aggregate key as a full public key, signers that are unaware of the MuSig2 outside of the PSBT
60+
will still be able to identify which keys are derived from the aggregate key by computing and then
61+
comparing the fingerprints. This is necessary for the signer to apply the correct tweaks to their
62+
partial signature.</ref> from the <tt>KeyAgg</tt> algorithm. This key may or may not
63+
be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the
64+
script were derived.
65+
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
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 aggregate pubkey> <32 byte hash or omitted></tt>
71+
| <tt><66 byte public nonces</tt>
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 aggregate public
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. Note that the second 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.
83+
|-
84+
| rowspan="2"|MuSig2 Participant Partial Signature
85+
| rowspan="2"|<tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt>
86+
| <tt><33 byte compressed pubkey> <33 byte plain aggregate pubkey> <32 byte hash or omitted></tt>
87+
| <tt><32 byte partial signature></tt>
88+
| rowspan="2"|
89+
| rowspan="2"|
90+
| rowspan="2"| 0, 2
91+
|-
92+
| 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
93+
of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or
94+
the taproot output key, then the tapleaf hash must be omitted. Note that the second public key must
95+
be the key found in the script and not the aggregate public key that it was derived from, if it was
96+
derived from an aggregate key.
97+
| The partial signature produced by the <tt>Sign</tt> algorithm.
98+
|}
99+
100+
The new per-output types are defined as follows:
101+
102+
{|
103+
! Name
104+
! <tt><keytype></tt>
105+
! <tt><keydata></tt>
106+
! <tt><valuedata></tt>
107+
! Versions Requiring Inclusion
108+
! Versions Requiring Exclusion
109+
! Versions Allowing Inclusion
110+
|-
111+
| rowspan="2"|MuSig2 Participant Public Keys
112+
| rowspan="2"|<tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
113+
| <tt><33 byte compressed pubkey></tt>
114+
| <tt><33 byte compressed pubkey>*</tt>
115+
| rowspan="2"|
116+
| rowspan="2"|
117+
| rowspan="2"|0, 2
118+
|-
119+
| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
120+
be in the script directly. It may instead be a parent public key from which the public keys in the
121+
script were derived.
122+
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
123+
required for aggregation. If sorting was done, then the keys must be in the sorted order.
124+
|}
125+
126+
==Roles==
127+
128+
===Updater===
129+
130+
When an updater observes a Taproot output which involves a MuSig2 aggregate public key that it is
131+
aware if, it can add a <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> field containing the public keys
132+
of the participants. This aggregate public key may be directly in the script, the Taproot internal
133+
key, the Taproot output key, or a public key from which the key in the script was derived from.
134+
135+
An aggregate public key that appears directly in the script or internal key may be from the result
136+
of deriving child pubkeys from participant xpubs. If the updater has this derivation information, it
137+
should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> for each participant public key.
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]
144+
if there is no <tt>PSBT_IN_GLOBAL_XPUB</tt> that specifies the synthetic xpub for the aggregate
145+
public key.
146+
147+
Updaters should add <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS</tt> and
148+
<tt>PSBT_OUT_TAP_BIP32_DERIVATION</tt> similarly to inputs to aid in change detection.
149+
150+
===Signer===
151+
152+
To determine whether a signer is a participant in the MuSig2 aggregate key, the signer should first
153+
look at all <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> and see if any key which it knows the
154+
private key for appears as a participant in any aggregate pubkey. Signers should also check whether
155+
any of the keys in <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> belong to it, and if any of those keys
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
162+
nonce that is added in a <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field. However
163+
signers must keep in mind that '''improper nonce usage can compromise private
164+
keys.''' Please see BIP 327 for best practices on nonce generation and usage.
165+
166+
Once all signers have added their <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> fields, each signer will perform
167+
the <tt>NonceAgg</tt> algorithm followed by the <tt>Sign</tt> algorithm in order to produce the
168+
partial signature for their key. The result will be added to the PSBT in a
169+
<tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt> field.
170+
171+
Signers must remember to apply any relevant tweaks such as a tweak that is the result of performing
172+
BIP 32 unhardened dervation with the aggregate public key as the parent key.
173+
174+
If all other signers have provided a <tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt>, then the final signer may
175+
perform the <tt>PartialSigAgg</tt> algorithm and produce a BIP 340 compatible signature that can be
176+
placed into a <tt>PSBT_IN_TAP_KEY_SIG</tt> or a <tt>PSBT_IN_TAP_SCRIPT_SIG</tt>.
177+
178+
===Finalizer===
179+
180+
A finalizer may perform the same <tt>PartialSigAgg</tt> step as the final signer if it has not
181+
already been done.
182+
183+
Otherwise, the resulting signature is a BIP 340 compatible signature and finalizers should treat it
184+
as such.
185+
186+
==Compatibility==
187+
188+
These are simply new fields added to the existing PSBT format. Because PSBT is designed to be
189+
extensible, old software will ignore the new fields.
190+
191+
Reusing <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> to provide derivation paths for participant public
192+
keys may cause software unaware of MuSig2 to produce a signature for that public key. This is still
193+
safe. If that public key does not directly appear in the leaf script that was signed, then the
194+
signature produced will not be useful and so cannot be replayed. If the public key does directly
195+
appear in the leaf script, then the signer will have validated the script as if it did not involve a
196+
MuSig2 and will have found it acceptable in order for it to have produced a signature. In either
197+
case, producing a signature does not give rise to the possibility of losing funds.
198+
199+
==Test Vectors==
200+
201+
TBD
202+
203+
==Rationale==
204+
205+
<references/>
206+
207+
==Reference implementation==
208+
209+
The reference implementation of the PSBT format is available at TBD.
210+
211+
==Acknowledgements==
212+
213+
Thanks to Sanket Kanjalkar whose notes on this topic formed the initial basis of this BIP. Also
214+
thanks to Pieter Wuille, Jonas Nick, Tim Ruffing, Marko Bencun, Salvatore Ingala, and all others who
215+
have participated in discussions about these fields.

0 commit comments

Comments
 (0)