BIP: 373
  Layer: Applications
  Title: MuSig2 PSBT Fields
  Author: Ava Chow <me@achow101.com>
  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:

The new per-output types are defined as follows:

Roles

Updater

When an updater observes a Taproot output which involves a MuSig2 aggregate public key that it is aware of, 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 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 derivation 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