Merge pull request #1540 from achow101/musig2

328, 390, 373: BIPs for MuSig2 derivation, descriptors, and PSBT fields

README.mediawiki

@@ -1016,6 +1016,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |-
+| [[bip-0328.mediawiki|328]]
+| Applications
+| Derivation Scheme for MuSig2 Aggregate Keys
+| Ava Chow
+| Informational
+| Draft
+|-
 | [[bip-0329.mediawiki|329]]
 | Applications
 | Wallet Labels Export Format
@@ -1149,6 +1156,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0373.mediawiki|373]]
+| Applications
+| MuSig2 PSBT Fields
+| Ava Chow
+| Standard
+| Draft
+|-
 | [[bip-0380.mediawiki|380]]
 | Applications
 | Output Script Descriptors General Operation
@@ -1219,6 +1233,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |-
+| [[bip-0390.mediawiki|390]]
+| Applications
+| musig() Descriptor Key Expression
+| Ava Chow
+| Informational
+| Draft
+|-
 | [[bip-0431.mediawiki|431]]
 | Applications
 | Topology Restrictions for Pinning

bip-0174.mediawiki

@@ -483,6 +483,52 @@ The currently defined per-input types are defined as follows:
 | 0, 2
 | [[bip-0371.mediawiki|371]]
 |-
+| MuSig2 Participant Public Keys
+| <tt>PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a</tt>
+| <33 byte plain aggregate pubkey>
+| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
+be in the script directly (as x-only). It may instead be a parent public key from which the public keys in the
+script were derived.
+| <tt><33 byte compressed pubkey>*</tt>
+| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
+required for aggregation. If sorting was done, then the keys must be in the sorted order.
+|
+|
+| 0, 2
+| [[bip-0373.mediawiki|373]]
+|-
+| MuSig2 Public Nonce
+| <tt>PSBT_IN_MUSIG2_PUB_NONCE = 0x1b</tt>
+| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
+| The compressed public key of the participant providing this nonce, followed by the plain public
+key the participant is providing the nonce for, followed by the BIP 341 tapleaf hash of
+the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or the
+taproot output key, then the tapleaf hash must be omitted. The plain public key must be
+the key found in the script and not the aggregate public key that it was derived from, if it was
+derived from an aggregate key.
+| <tt><66 byte public nonce></tt>
+| The public nonce produced by the <tt>NonceGen</tt> algorithm.
+|
+|
+| 0, 2
+| [[bip-0373.mediawiki|373]]
+|-
+| MuSig2 Participant Partial Signature
+| <tt>PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c</tt>
+| <tt><33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted></tt>
+| The compressed public key of the participant providing this partial signature, followed by the
+plain public key the participant is providing the signature for, followed by the BIP 341 tapleaf hash
+of the Taproot leaf script that will be signed. If the aggregate key is the taproot internal key or
+the taproot output key, then the tapleaf hash must be omitted. Note that the plain public key must
+be the key found in the script and not the aggregate public key that it was derived from, if it was
+derived from an aggregate key.
+| <tt><32 byte partial signature></tt>
+| The partial signature produced by the <tt>Sign</tt> algorithm.
+|
+|
+| 0, 2
+| [[bip-0373.mediawiki|373]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
 | <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
 | 0, 2
 | [[bip-0371.mediawiki|371]]
 |-
+| MuSig2 Participant Public Keys
+| <tt>PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08</tt>
+| <33 byte plain aggregate pubkey>
+| The MuSig2 aggregate plain public key from the <tt>KeyAgg</tt> algorithm. This key may or may not
+be in the script directly. It may instead be a parent public key from which the public keys in the
+script were derived.
+| <tt><33 byte compressed pubkey>*</tt>
+| A list of the compressed public keys of the participants in the MuSig2 aggregate key in the order
+required for aggregation. If sorting was done, then the keys must be in the sorted order.
+|
+|
+| 0, 2
+| [[bip-0373.mediawiki|373]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
 | <tt><compact size uint identifier length> <bytes identifier> <compact size uint subtype> <bytes subkeydata></tt>

bip-0328.mediawiki

@@ -0,0 +1,80 @@
+<pre>
+  BIP: 328
+  Layer: Applications
+  Title: Derivation Scheme for MuSig2 Aggregate Keys
+  Author: Ava Chow <[email protected]>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0328
+  Status: Draft
+  Type: Informational
+  Created: 2024-01-15
+  License: CC0-1.0
+</pre>
+
+==Abstract==
+
+This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2
+aggregate public key and how such keys should be used for key derivation.
+
+==Copyright==
+
+This BIP is licensed under the Creative Commons CC0 1.0 Universal license.
+
+==Motivation==
+
+Multiple signers can create a single aggregate public key with MuSig2 that is indistinguishable
+from a random public key. The cosigners need a method for generating additional aggregate pubkeys
+to follow the best practice of using a new address for every payment.
+
+The obvious method is for the cosigners to generate multiple public keys and produce a
+new aggregate pubkey every time one is needed. This is similar to how multisig using Bitcoin script
+works where all of the cosigners share their extended public keys and do derivation to produce
+the multisig script. The same could be done with MuSig2 and instead of producing a multisig script,
+the result would be a MuSig2 aggregate pubkey.
+
+However, it is much simpler to be able to derive from a single extended public key instead of having
+to derive from many extended public keys and aggregate them. As MuSig2 produces a normal looking
+public key, the aggregate public can be used in this way. This reduces the storage and computation
+requirements for generating new aggregate pubkeys.
+
+==Specification==
+
+A synthetic xpub can be created from a BIP 327 MuSig2 plain aggregate public key by setting
+the depth to 0, the child number to 0, and attaching a chaincode with the byte string
+<tt>868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965</tt><ref>'''Where does this
+constant chaincode come from?''' It is the SHA256 of the text <tt>MuSig2MuSig2MuSig2</tt></ref>.
+This fixed chaincode should be used by all such synthetic xpubs following this specification.
+Unhardened child public keys can be derived from the synthetic xpub as with any other xpub. Since
+the aggregate public key is all that is necessary to produce the synthetic xpub, any aggregate
+public key that will be used in this way shares the same privacy concerns as typical xpubs.
+
+Furthermore, as there is no aggregate private key, only unhardened derivation from the aggregate
+public key is possible.
+
+When signing, all signers must compute the tweaks used in the BIP 32 derivation for the child key
+being signed for. The I<sub>L</sub> value computed in ''CKDpub'' is the tweak used at each
+derivation step. These are provided in the session context, each with a tweak mode of plain
+(''is_xonly_t = false''). When the ''Sign'' algorithm is used, the tweaks will be applied to the
+partial signatures.
+
+==Test Vectors==
+
+TBD
+
+==Backwards Compatibility==
+
+Once a synthetic xpub is created, it is fully backwards compatible with BIP 32 - only unhardened
+derivation can be done, and the signers will be able to produce a signature for any derived children.
+
+==Rationale==
+
+<references/>
+
+==Reference Implementation==
+
+TBD
+
+==Acknowledgements==
+
+Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who
+participated in discussions on this topic.