Skip to content

Commit 806b8b8

Browse files
achow101achow101
committed
BIP 373: add MuSig2 PSBT Fields BIP
1 parent 6b9138c commit 806b8b8

File tree

3 files changed

+283
-0
lines changed

3 files changed

+283
-0
lines changed

‎README.mediawiki

+7
Original file line numberDiff line numberDiff line change
@@ -1149,6 +1149,13 @@ Those proposing changes should consider that ultimately consent may rest with th
11491149
| Standard
11501150
| Draft
11511151
|-
1152+
| [[bip-0373.mediawiki|373]]
1153+
| Applications
1154+
| MuSig2 PSBT Fields
1155+
| Ava Chow
1156+
| Standard
1157+
| Draft
1158+
|-
11521159
| [[bip-0380.mediawiki|380]]
11531160
| Applications
11541161
| Output Script Descriptors General Operation

‎bip-0174.mediawiki

+60
Original file line numberDiff line numberDiff line change
@@ -483,6 +483,52 @@ 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-0373.mediawiki|373]]
499+
|-
500+
| MuSig2 Public Nonce
501+
| <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt>
502+
| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
503+
| The compressed public key of the participant providing this nonce, followed by the plain public
504+
key the participant is providing the nonce for, followed by 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. The plain 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 nonce></tt>
510+
| The public nonce produced by the <tt>NonceGen</tt> algorithm.
511+
|
512+
|
513+
| 0, 2
514+
| [[bip-0373.mediawiki|373]]
515+
|-
516+
| MuSig2 Participant Partial Signature
517+
| <tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt>
518+
| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
519+
| The compressed public key of the participant providing this partial signature, followed by the
520+
plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash
521+
of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or
522+
the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must
523+
be the key found in the script and not the aggregate public key that it was derived from, if it was
524+
derived from an aggregate key.
525+
| <tt><32 byte partial signature></tt>
526+
| The partial signature produced by the <tt>Sign</tt> algorithm.
527+
|
528+
|
529+
| 0, 2
530+
| [[bip-0373.mediawiki|373]]
531+
|-
486532
| Proprietary Use Type
487533
| <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
488534
| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>
@@ -599,6 +645,20 @@ determine which outputs are change outputs and verify that the change is returni
599645
| 0, 2
600646
| [[bip-0371.mediawiki|371]]
601647
|-
648+
| MuSig2 Participant Public Keys
649+
| <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
650+
| <33 byte plain aggregate pubkey>
651+
| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
652+
be in the script directly. It may instead be a parent public key from which the public keys in the
653+
script were derived.
654+
| <tt><33 byte compressed pubkey>*</tt>
655+
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
656+
required for aggregation. If sorting was done, then the keys must be in the sorted order.
657+
|
658+
|
659+
| 0, 2
660+
| [[bip-0373.mediawiki|373]]
661+
|-
602662
| Proprietary Use Type
603663
| <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
604664
| <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>

‎bip-0373.mediawiki

+216
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,216 @@
1+
<pre>
2+
BIP: 373
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-0373
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-0328.mediawiki|BIP 328]], 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 pubkey> <32 byte hash or omitted></tt>
71+
| <tt><66 byte public nonce></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 public
77+
key the participant is providing the nonce for, followed by 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 nonce 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 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
93+
plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash
94+
of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or
95+
the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must
96+
be the key found in the script and not the aggregate public key that it was derived from, if it was
97+
derived from an aggregate key.
98+
| The partial signature produced by the <tt>Sign</tt> algorithm.
99+
|}
100+
101+
The new per-output types are defined as follows:
102+
103+
{|
104+
! Name
105+
! <tt><keytype></tt>
106+
! <tt><keydata></tt>
107+
! <tt><valuedata></tt>
108+
! Versions Requiring Inclusion
109+
! Versions Requiring Exclusion
110+
! Versions Allowing Inclusion
111+
|-
112+
| rowspan="2"|MuSig2 Participant Public Keys
113+
| rowspan="2"|<tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
114+
| <tt><33 byte compressed pubkey></tt>
115+
| <tt><33 byte compressed pubkey>*</tt>
116+
| rowspan="2"|
117+
| rowspan="2"|
118+
| rowspan="2"|0, 2
119+
|-
120+
| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
121+
be in the script directly. It may instead be a parent public key from which the public keys in the
122+
script were derived.
123+
| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
124+
required for aggregation. If sorting was done, then the keys must be in the sorted order.
125+
|}
126+
127+
==Roles==
128+
129+
===Updater===
130+
131+
When an updater observes a Taproot output which involves a MuSig2 aggregate public key that it is
132+
aware if, it can add a <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> field containing the public keys
133+
of the participants. This aggregate public key may be directly in the script, the Taproot internal
134+
key, the Taproot output key, or a public key from which the key in the script was derived from.
135+
136+
An aggregate public key that appears directly in the script or internal key may be from the result
137+
of deriving child pubkeys from participant xpubs. If the updater has this derivation information, it
138+
should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> for each participant public key.
139+
140+
If the public key found was derived from an aggregate public key, then all MuSig2 PSBT fields for
141+
that public key should contain the aggregate public key rather than the found pubkey itself. The
142+
updater should also add <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> that contains the derivation path used
143+
to derive the found pubkey from the aggregate pubkey.
144+
Derivation from the aggregate pubkey can be assumed to follow [[bip-0328.mediawiki|BIP 328]]
145+
if there is no <tt>PSBT_IN_GLOBAL_XPUB</tt> that specifies the synthetic xpub for the aggregate
146+
public key.
147+
148+
Updaters should add <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS</tt> and
149+
<tt>PSBT_OUT_TAP_BIP32_DERIVATION</tt> similarly to inputs to aid in change detection.
150+
151+
===Signer===
152+
153+
To determine whether a signer is a participant in the MuSig2 aggregate key, the signer should first
154+
look at all <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt> and see if any key which it knows the
155+
private key for appears as a participant in any aggregate pubkey. Signers should also check whether
156+
any of the keys in <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> belong to it, and if any of those keys
157+
appear in as a participant in <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS</tt>.
158+
159+
For each aggregate public key that the signer is a participant of that it wants
160+
to produce a signature for, if the signer does not find an existing
161+
<tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field for its key, then it should add one using
162+
the <tt>NonceGen</tt> algorithm (or one of its variations) to produce a public
163+
nonce that is added in a <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> field. However
164+
signers must keep in mind that '''improper nonce usage can compromise private
165+
keys.''' Please see BIP 327 for best practices on nonce generation and usage.
166+
167+
Once all signers have added their <tt>PSBT_IN_MUSIG2_PUB_NONCE</tt> fields, each signer will perform
168+
the <tt>NonceAgg</tt> algorithm followed by the <tt>Sign</tt> algorithm in order to produce the
169+
partial signature for their key. The result will be added to the PSBT in a
170+
<tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt> field.
171+
172+
Signers must remember to apply any relevant tweaks such as a tweak that is the result of performing
173+
BIP 32 unhardened dervation with the aggregate public key as the parent key.
174+
175+
If all other signers have provided a <tt>PSBT_IN_MUSIG2_PARTIAL_SIG</tt>, then the final signer may
176+
perform the <tt>PartialSigAgg</tt> algorithm and produce a BIP 340 compatible signature that can be
177+
placed into a <tt>PSBT_IN_TAP_KEY_SIG</tt> or a <tt>PSBT_IN_TAP_SCRIPT_SIG</tt>.
178+
179+
===Finalizer===
180+
181+
A finalizer may perform the same <tt>PartialSigAgg</tt> step as the final signer if it has not
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+
==Backwards Compatibility==
188+
189+
These are simply new fields added to the existing PSBT format. Because PSBT is designed to be
190+
extensible, old software will ignore the new fields.
191+
192+
Reusing <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> to provide derivation paths for participant public
193+
keys may cause software unaware of MuSig2 to produce a signature for that public key. This is still
194+
safe. If that public key does not directly appear in the leaf script that was signed, then the
195+
signature produced will not be useful and so cannot be replayed. If the public key does directly
196+
appear in the leaf script, then the signer will have validated the script as if it did not involve a
197+
MuSig2 and will have found it acceptable in order for it to have produced a signature. In either
198+
case, producing a signature does not give rise to the possibility of losing funds.
199+
200+
==Test Vectors==
201+
202+
TBD
203+
204+
==Rationale==
205+
206+
<references/>
207+
208+
==Reference implementation==
209+
210+
The reference implementation of the PSBT format is available at TBD.
211+
212+
==Acknowledgements==
213+
214+
Thanks to Sanket Kanjalkar whose notes on this topic formed the initial basis of this BIP. Also
215+
thanks to Pieter Wuille, Jonas Nick, Tim Ruffing, Marko Bencun, Salvatore Ingala, and all others who
216+
have participated in discussions about these fields.

0 commit comments

Comments
 (0)