From 48ebcb2191e9738efcff06b425cec41985c43f5f Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Mon, 15 Jan 2024 14:54:19 -0500 Subject: BIP 328: add MuSig2 derivation BIP --- README.mediawiki | 7 +++++ bip-0328.mediawiki | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 87 insertions(+) create mode 100644 bip-0328.mediawiki diff --git a/README.mediawiki b/README.mediawiki index 455d522..1e78405 100644 --- a/README.mediawiki +++ b/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 diff --git a/bip-0328.mediawiki b/bip-0328.mediawiki new file mode 100644 index 0000000..3c07dab --- /dev/null +++ b/bip-0328.mediawiki @@ -0,0 +1,80 @@ +
+  BIP: 328
+  Layer: Applications
+  Title: Derivation Scheme for MuSig2 Aggregate Keys
+  Author: Ava Chow 
+  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
+
+ +==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 +868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965'''Where does this +constant chaincode come from?''' It is the SHA256 of the text MuSig2MuSig2MuSig2. +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 IL 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== + + + +==Reference Implementation== + +TBD + +==Acknowledgements== + +Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who +participated in discussions on this topic. -- cgit v1.2.3 From 6b9138c1a1511719eb0477d2375c81a598ba07a0 Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Mon, 15 Jan 2024 14:07:44 -0500 Subject: BIP 390: Add MuSig2 descriptor BIP --- README.mediawiki | 7 ++++ bip-0380.mediawiki | 3 ++ bip-0390.mediawiki | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 127 insertions(+) create mode 100644 bip-0390.mediawiki diff --git a/README.mediawiki b/README.mediawiki index 1e78405..3d4f259 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1219,6 +1219,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 diff --git a/bip-0380.mediawiki b/bip-0380.mediawiki index 27b7908..823a92c 100644 --- a/bip-0380.mediawiki +++ b/bip-0380.mediawiki @@ -332,4 +332,7 @@ This Table lists all available Script expressions and the BIPs specifying them. |- | tr(KEY), tr(KEY, TREE) | [[bip-0386.mediawiki|386]] +|- +| musig(KEY, KEY, ..., KEY) +| [[bip-0390.mediawiki|390]] |} diff --git a/bip-0390.mediawiki b/bip-0390.mediawiki new file mode 100644 index 0000000..05f5734 --- /dev/null +++ b/bip-0390.mediawiki @@ -0,0 +1,117 @@ +
+  BIP: 390
+  Layer: Applications
+  Title: musig() Descriptor Key Expression
+  Author: Ava Chow 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0390
+  Status: Draft
+  Type: Informational
+  Created: 2024-01-15
+  License: CC0-1.0
+
+ +==Abstract== + +This document specifies a musig() key expression for output script descriptors. +musig() expressions take multiple keys and produce an aggregate public key using BIP 327. + +==Copyright== + +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. + +==Motivation== + +BIP 327 introduces the MuSig2 Multi-Signature scheme. It is useful to have a way for keys to be used +in a MuSig2 aggregate key to be expressed in descriptors so that wallets can more easily use MuSig2. + +==Specification== + +A new key expression is defined: musig(). + +===musig(KEY, KEY, ..., KEY)=== + +The musig(KEY, KEY, ..., KEY) expression can only be used inside of a tr() +expression as a key expression. It additionally cannot be nested within another musig() +expression. Repeated participant public keys are not allowed. The aggregate public key is produced +by using the KeyAgg algorithm on all KEYs specified in the expression after performing all +specified derivation. As with script expressions, KEY can contain child derivation specified by +/*. A new aggregate public key will be computed for each child index. Keys must be sorted +with the KeySort algorithm after all derivation and prior to aggregation'''Why must +the keys be sorted prior to aggregation?''' Although the descriptor's written form sets an order +for the keys that could be used for aggregation, the order should not matter as MuSig2 philosophically +operates over a set of keys, with the order merely being an implementation detail in aggregation +itself. Requiring sorting of keys prior to aggregation enforces this philosophy as keys can be +written in the descriptor in any order with the end result still being the same. Furthermore, this +aids with recovery where the descriptor was not backed up as users will not need to also have +backed up, or guess, the correct order of keys.. + +===musig(KEY, KEY, ..., KEY)/NUM/.../*=== + +musig(KEY, KEY, ..., KEY)/NUM/.../* expressions are also allowed, with the same usage +restrictions as in the previous section. The aggregate public key +is first computed as described above, with the keys also being sorted after all derivation and prior +to aggreation. Then further BIP 32 derivation will be performed on the aggregate public key as described in +[[bip-0328.mediawiki|BIP 328]]. As there is no aggregate private key, +only unhardened derivation from the aggregate public key is allowed, and thus the derivation steps +following the musig() expression cannot contain +/NUMh or /NUM' derivation steps nor /*h, or /*' child derivation. +For these musig() expressions, the KEY expressions contained within must be xpubs or derived from +xpubs, and cannot contain child derivation as specified by a /*, /*', or /*h. + +==Test Vectors== + +Valid descriptors containing followed by the scripts they produce. Descriptors involving derived child keys +will have the 0th, 1st, and 2nd scripts listed. + +* rawtr(musig(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +** 5120789d937bade6673538f3e28d8368dda4d0512f94da44cf477a505716d26a1575 +* tr(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +** 512079e6c3e628c9bfbce91de6b7fb28e2aec7713d377cf260ab599dcbc40e542312 +* rawtr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*) +** 51209508c08832f3bb9d5e8baf8cb5cfa3669902e2f2da19acea63ff47b93faa9bfc +** 51205ca1102663025a83dd9b5dbc214762c5a6309af00d48167d2d6483808525a298 +** 51207dbed1b89c338df6a1ae137f133a19cae6e03d481196ee6f1a5c7d1aeb56b166 +* tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*,pk(f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)) +** 51201d377b637b5c73f670f5c8a96a2c0bb0d1a682a1fca6aba91fe673501a189782 +** 51208950c83b117a6c208d5205ffefcf75b187b32512eb7f0d8577db8d9102833036 +** 5120a49a477c61df73691b77fcd563a80a15ea67bb9c75470310ce5c0f25918db60d +* tr(f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,pk(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*)) +** 512068983d461174afc90c26f3b2821d8a9ced9534586a756763b68371a404635cc8 +** 5120368e2d864115181bdc8bb5dc8684be8d0760d5c33315570d71a21afce4afd43e +** 512097a1e6270b33ad85744677418bae5f59ea9136027223bc6e282c47c167b471d5 + +Invalid descriptors + +* musig() is not allowed in pk(): pk(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +* musig() is not allowed in pkh(): pkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +* musig() is not allowed in wpkh(): wpkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +* musig() is not allowed in combo(): combo(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +* musig() is not allowed in sh(wpkh()): sh(wpkh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66))) +* musig() is not allowed in sh(wsh()): sh(wsh(pk(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)))) +* musig() is not allowed in wsh(): wsh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +* musig() is not allowed in sh(): sh(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) +* Ranged musig() requires all participants to be xpubs: tr(musig(02f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9,03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)/0/0) +* Cannot have ranged participants if musig() is also ranged: tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/*,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*) +* musig() cannot have hardened derivation steps: tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0h/*) +* musig() cannot have hardened child derivation: tr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/0/*h) + +==Backwards Compatibility== + +musig() expressions use the format and general operation specified in +[[bip-0380.mediawiki|BIP 380]]. As these are a set of wholly new expressions, they are not compatible +with any implementation. However the keys are produced using a standard process so existing software +are likely to be familiar with them. + +==Rationale== + + + +==Reference Implementation== + +TBD + +==Acknowledgements== + +Thanks to Pieter Wuille, Andrew Poelstra, Sanket Kanjalkar, Salvatore Ingala, and all others who +participated in discussions on this topic. -- cgit v1.2.3 From 806b8b886fef460a7a812c219f30d5b09d74d2d0 Mon Sep 17 00:00:00 2001 From: Ava Chow Date: Mon, 15 Jan 2024 14:07:56 -0500 Subject: BIP 373: add MuSig2 PSBT Fields BIP --- README.mediawiki | 7 ++ bip-0174.mediawiki | 60 +++++++++++++++ bip-0373.mediawiki | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 283 insertions(+) create mode 100644 bip-0373.mediawiki diff --git a/README.mediawiki b/README.mediawiki index 3d4f259..91f7c4c 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -1149,6 +1149,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 diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index 95a5573..94a52f2 100644 --- a/bip-0174.mediawiki +++ b/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 +| PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a +| <33 byte plain aggregate pubkey> +| The MuSig2 aggregate plain public key from the KeyAgg 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. +| <33 byte compressed pubkey>* +| 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 +| PSBT_IN_MUSIG2_PUB_NONCE = 0x1b +| <33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted> +| 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. +| <66 byte public nonce> +| The public nonce produced by the NonceGen algorithm. +| +| +| 0, 2 +| [[bip-0373.mediawiki|373]] +|- +| MuSig2 Participant Partial Signature +| PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c +| <33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted> +| 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. +| <32 byte partial signature> +| The partial signature produced by the Sign algorithm. +| +| +| 0, 2 +| [[bip-0373.mediawiki|373]] +|- | Proprietary Use Type | PSBT_IN_PROPRIETARY = 0xFC | @@ -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 +| PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08 +| <33 byte plain aggregate pubkey> +| The MuSig2 aggregate plain public key from the KeyAgg 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. +| <33 byte compressed pubkey>* +| 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 | PSBT_OUT_PROPRIETARY = 0xFC | diff --git a/bip-0373.mediawiki b/bip-0373.mediawiki new file mode 100644 index 0000000..d9dec45 --- /dev/null +++ b/bip-0373.mediawiki @@ -0,0 +1,216 @@ +
+  BIP: 373
+  Layer: Applications
+  Title: MuSig2 PSBT Fields
+  Author: Ava Chow 
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0373
+  Status: Draft
+  Type: Standards Track
+  Created: 2024-01-15
+  License: CC0-1.0
+
+ +==Introduction== + +===Abstract=== + +This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP +327 MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for +the participants' keys, the public nonces, and the partial signatures produced with MuSig2. + +===Copyright=== + +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. + +===Motivation=== + +BIP 327 specifies a way to create BIP 340 compatible public keys and signatures using the MuSig2 +Multi-Signature scheme. The existing PSBT fields are unable to support MuSig2 as it introduces new +concepts and additional rounds of communication. Therefore new fields must be defined to allow PSBTs +to carry the information necessary to produce a valid signature with MuSig2. + +==Specification== + +The new per-input types are defined as follows: + +{| +! Name +! +! +! +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| rowspan="2"|MuSig2 Participant Public Keys +| rowspan="2"|PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a +| <33 byte plain aggregate pubkey> +| <33 byte compressed pubkey>* +| rowspan="2"| +| rowspan="2"| +| rowspan="2"| 0, 2 +|- +| The MuSig2 aggregate plain public key'''Why the plain aggregate public key instead of x-only?''' +BIP 32 requires public keys to include their evenness byte. Aggregate public keys are expected to be +derived from, following [[bip-0328.mediawiki|BIP 328]], and therefore will +need to include the evenness. Furthermore, PSBT_IN_TAP_BIP32_DERIVATION fields include fingerprints +to identify master keys, and these fingerprints require full compressed public keys. By including +the aggregate key as a full public key, signers that are unaware of the MuSig2 outside of the PSBT +will still be able to identify which keys are derived from the aggregate key by computing and then +comparing the fingerprints. This is necessary for the signer to apply the correct tweaks to their +partial signature. from the KeyAgg 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. +| 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. +|- +| rowspan="2"|MuSig2 Public Nonce +| rowspan="2"|PSBT_IN_MUSIG2_PUB_NONCE = 0x1b +| <33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted> +| <66 byte public nonce> +| rowspan="2"| +| rowspan="2"| +| rowspan="2"| 0, 2 +|- +| 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. +| The public nonce produced by the NonceGen algorithm. +|- +| rowspan="2"|MuSig2 Participant Partial Signature +| rowspan="2"|PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c +| <33 byte compressed pubkey> <33 byte plain pubkey> <32 byte hash or omitted> +| <32 byte partial signature> +| rowspan="2"| +| rowspan="2"| +| rowspan="2"| 0, 2 +|- +| 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. +| The partial signature produced by the Sign algorithm. +|} + +The new per-output types are defined as follows: + +{| +! Name +! +! +! +! Versions Requiring Inclusion +! Versions Requiring Exclusion +! Versions Allowing Inclusion +|- +| rowspan="2"|MuSig2 Participant Public Keys +| rowspan="2"|PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08 +| <33 byte compressed pubkey> +| <33 byte compressed pubkey>* +| rowspan="2"| +| rowspan="2"| +| rowspan="2"|0, 2 +|- +| The MuSig2 aggregate plain public key from the KeyAgg 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. +| 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. +|} + +==Roles== + +===Updater=== + +When an updater observes a Taproot output which involves a MuSig2 aggregate public key that it is +aware if, it can add a PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS field containing the public keys +of the participants. This aggregate public key may be directly in the script, the Taproot internal +key, the Taproot output key, or a public key from which the key in the script was derived from. + +An aggregate public key that appears directly in the script or internal key may be from the result +of deriving child pubkeys from participant xpubs. If the updater has this derivation information, it +should also add PSBT_IN_TAP_BIP32_DERIVATION for each participant public key. + +If the public key found was derived from an aggregate public key, then all MuSig2 PSBT fields for +that public key should contain the aggregate public key rather than the found pubkey itself. The +updater should also add PSBT_IN_TAP_BIP32_DERIVATION that contains the derivation path used +to derive the found pubkey from the aggregate pubkey. +Derivation from the aggregate pubkey can be assumed to follow [[bip-0328.mediawiki|BIP 328]] +if there is no PSBT_IN_GLOBAL_XPUB that specifies the synthetic xpub for the aggregate +public key. + +Updaters should add PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS and +PSBT_OUT_TAP_BIP32_DERIVATION similarly to inputs to aid in change detection. + +===Signer=== + +To determine whether a signer is a participant in the MuSig2 aggregate key, the signer should first +look at all PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS and see if any key which it knows the +private key for appears as a participant in any aggregate pubkey. Signers should also check whether +any of the keys in PSBT_IN_TAP_BIP32_DERIVATION belong to it, and if any of those keys +appear in as a participant in PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS. + +For each aggregate public key that the signer is a participant of that it wants +to produce a signature for, if the signer does not find an existing +PSBT_IN_MUSIG2_PUB_NONCE field for its key, then it should add one using +the NonceGen algorithm (or one of its variations) to produce a public +nonce that is added in a PSBT_IN_MUSIG2_PUB_NONCE field. However +signers must keep in mind that '''improper nonce usage can compromise private +keys.''' Please see BIP 327 for best practices on nonce generation and usage. + +Once all signers have added their PSBT_IN_MUSIG2_PUB_NONCE fields, each signer will perform +the NonceAgg algorithm followed by the Sign algorithm in order to produce the +partial signature for their key. The result will be added to the PSBT in a +PSBT_IN_MUSIG2_PARTIAL_SIG field. + +Signers must remember to apply any relevant tweaks such as a tweak that is the result of performing +BIP 32 unhardened dervation with the aggregate public key as the parent key. + +If all other signers have provided a PSBT_IN_MUSIG2_PARTIAL_SIG, then the final signer may +perform the PartialSigAgg algorithm and produce a BIP 340 compatible signature that can be +placed into a PSBT_IN_TAP_KEY_SIG or a PSBT_IN_TAP_SCRIPT_SIG. + +===Finalizer=== + +A finalizer may perform the same PartialSigAgg step as the final signer if it has not +already been done. + +Otherwise, the resulting signature is a BIP 340 compatible signature and finalizers should treat it +as such. + +==Backwards Compatibility== + +These are simply new fields added to the existing PSBT format. Because PSBT is designed to be +extensible, old software will ignore the new fields. + +Reusing PSBT_IN_TAP_BIP32_DERIVATION to provide derivation paths for participant public +keys may cause software unaware of MuSig2 to produce a signature for that public key. This is still +safe. If that public key does not directly appear in the leaf script that was signed, then the +signature produced will not be useful and so cannot be replayed. If the public key does directly +appear in the leaf script, then the signer will have validated the script as if it did not involve a +MuSig2 and will have found it acceptable in order for it to have produced a signature. In either +case, producing a signature does not give rise to the possibility of losing funds. + +==Test Vectors== + +TBD + +==Rationale== + + + +==Reference implementation== + +The reference implementation of the PSBT format is available at TBD. + +==Acknowledgements== + +Thanks to Sanket Kanjalkar whose notes on this topic formed the initial basis of this BIP. Also +thanks to Pieter Wuille, Jonas Nick, Tim Ruffing, Marko Bencun, Salvatore Ingala, and all others who +have participated in discussions about these fields. -- cgit v1.2.3