Skip to content

Commit 5d77440

Browse files
murchandamusmurchandamus
authored
Merge pull request bitcoin#1540 from achow101/musig2
328, 390, 373: BIPs for MuSig2 derivation, descriptors, and PSBT fields
2 parents 3d299b4 + 806b8b8 commit 5d77440

6 files changed

+497
-0
lines changed

‎README.mediawiki

+21
Original file line numberDiff line numberDiff line change
@@ -1016,6 +1016,13 @@ Those proposing changes should consider that ultimately consent may rest with th
10161016
| Informational
10171017
| Draft
10181018
|-
1019+
| [[bip-0328.mediawiki|328]]
1020+
| Applications
1021+
| Derivation Scheme for MuSig2 Aggregate Keys
1022+
| Ava Chow
1023+
| Informational
1024+
| Draft
1025+
|-
10191026
| [[bip-0329.mediawiki|329]]
10201027
| Applications
10211028
| Wallet Labels Export Format
@@ -1149,6 +1156,13 @@ Those proposing changes should consider that ultimately consent may rest with th
11491156
| Standard
11501157
| Draft
11511158
|-
1159+
| [[bip-0373.mediawiki|373]]
1160+
| Applications
1161+
| MuSig2 PSBT Fields
1162+
| Ava Chow
1163+
| Standard
1164+
| Draft
1165+
|-
11521166
| [[bip-0380.mediawiki|380]]
11531167
| Applications
11541168
| Output Script Descriptors General Operation
@@ -1219,6 +1233,13 @@ Those proposing changes should consider that ultimately consent may rest with th
12191233
| Informational
12201234
| Draft
12211235
|-
1236+
| [[bip-0390.mediawiki|390]]
1237+
| Applications
1238+
| musig() Descriptor Key Expression
1239+
| Ava Chow
1240+
| Informational
1241+
| Draft
1242+
|-
12221243
| [[bip-0431.mediawiki|431]]
12231244
| Applications
12241245
| Topology Restrictions for Pinning

‎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-0328.mediawiki

+80
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
<pre>
2+
BIP: 328
3+
Layer: Applications
4+
Title: Derivation Scheme for MuSig2 Aggregate Keys
5+
Author: Ava Chow <[email protected]>
6+
Comments-Summary: No comments yet.
7+
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0328
8+
Status: Draft
9+
Type: Informational
10+
Created: 2024-01-15
11+
License: CC0-1.0
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.
18+
19+
==Copyright==
20+
21+
This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
22+
23+
==Motivation==
24+
25+
Multiple signers can create a single aggregate public key with MuSig2 that is indistinguishable
26+
from a random public key. The cosigners need a method for generating additional aggregate pubkeys
27+
to follow the best practice of using a new address for every payment.
28+
29+
The obvious method is for the cosigners to generate multiple public keys and produce a
30+
new aggregate pubkey every time one is needed. This is similar to how multisig using Bitcoin script
31+
works where all of the cosigners share their extended public keys and do derivation to produce
32+
the multisig script. The same could be done with MuSig2 and instead of producing a multisig script,
33+
the result would be a MuSig2 aggregate pubkey.
34+
35+
However, it is much simpler to be able to derive from a single extended public key instead of having
36+
to derive from many extended public keys and aggregate them. As MuSig2 produces a normal looking
37+
public key, the aggregate public can be used in this way. This reduces the storage and computation
38+
requirements for generating new aggregate pubkeys.
39+
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>.
46+
This fixed chaincode should be used by all such synthetic xpubs following this specification.
47+
Unhardened child public keys can be derived from the synthetic xpub as with any other xpub. Since
48+
the aggregate public key is all that is necessary to produce the synthetic xpub, any aggregate
49+
public key that will be used in this way shares the same privacy concerns as typical xpubs.
50+
51+
Furthermore, as there is no aggregate private key, only unhardened derivation from the aggregate
52+
public key is possible.
53+
54+
When signing, all signers must compute the tweaks used in the BIP 32 derivation for the child key
55+
being signed for. The I<sub>L</sub> value computed in ''CKDpub'' is the tweak used at each
56+
derivation step. These are provided in the session context, each with a tweak mode of plain
57+
(''is_xonly_t = false''). When the ''Sign'' algorithm is used, the tweaks will be applied to the
58+
partial signatures.
59+
60+
==Test Vectors==
61+
62+
TBD
63+
64+
==Backwards Compatibility==
65+
66+
Once a synthetic xpub is created, it is fully backwards compatible with BIP 32 - only unhardened
67+
derivation can be done, and the signers will be able to produce a signature for any derived children.
68+
69+
==Rationale==
70+
71+
<references/>
72+
73+
==Reference Implementation==
74+
75+
TBD
76+
77+
==Acknowledgements==
78+
79+
Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who
80+
participated in discussions on this topic.

0 commit comments

Comments
 (0)