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 --- bip-0373.mediawiki | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 216 insertions(+) create mode 100644 bip-0373.mediawiki (limited to 'bip-0373.mediawiki') 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