This guide explains BIP 373 MuSig2 PSBT Fields in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 373 is a Complete application-layer specification adding MuSig2 data to both PSBT version 0 and version 2. Its per-input fields carry the ordered participant public keys, each participant’s public nonce and each partial signature.
- Why it matters: BIP 373 makes MuSig2 coordination portable through PSBT, but it cannot replace signer-side transaction validation or nonce discipline. Each participant should treat the PSBT as untrusted state and prove every field before signing.
- Current position: BIP 373 is a Complete application-layer specification adding MuSig2 data to both PSBT version 0 and version 2.
BIP 373 MuSig2 PSBT Fields in simple English
BIP 373 MuSig2 PSBT Fields: Updaters assemble context, signers verify and add round data, and finalizers combine valid partial signatures and remove fields according to the specification.
Simple example
A node operator is checking BIP 373 MuSig2 PSBT Fields. Persist session identifiers atomically, reject changed PSBT data after commitment and test interrupted and duplicated workflows.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- PSBT:
- A portable format for passing an unsigned or partly signed Bitcoin transaction between tools and signers.
- Taproot:
- A Bitcoin upgrade that added new signature and script options for spending outputs.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Status and dependencies
BIP 373 is Complete, Specification, and depends on BIPs 32, 174, 327, 328 and 370. It extends PSBT interchange rather than Bitcoin consensus.
Participant keys
The participant field is keyed by the compressed aggregate public key and contains compressed participant keys in aggregation order. If KeySort was used, the sorted order must be preserved.
Public nonce
Each public-nonce field identifies the participant, aggregate key and optional tapleaf hash, then stores the 66-byte public nonce produced by MuSig2 NonceGen.
Partial signature
The partial-signature field uses the corresponding identity tuple and carries a 32-byte partial signature. It must bind to the same transaction, input, aggregate key and leaf context.
Taproot context
The tapleaf hash is omitted for an internal-key or output-key spend and supplied for a script leaf. Do not substitute a parent aggregate key where the output or script participant key is required.
Role separation
Updaters assemble context, signers verify and add round data, and finalizers combine valid partial signatures and remove fields according to the specification. Capability checks remain local.
Nonce safety
Never reuse secret nonce material across messages, inputs or aborted sessions. Persist session identifiers atomically, reject changed PSBT data after commitment and test interrupted and duplicated workflows. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is the main point of BIP 373 MuSig2 PSBT Fields?
BIP 373 MuSig2 PSBT Fields: Updaters assemble context, signers verify and add round data, and finalizers combine valid partial signatures and remove fields according to the specification.
For BIP 373 MuSig2 PSBT Fields, what should a beginner know about status and dependencies?
BIP 373 is Complete, Specification, and depends on BIPs 32, 174, 327, 328 and 370.
For BIP 373 MuSig2 PSBT Fields, what should a beginner know about participant keys?
The participant field is keyed by the compressed aggregate public key and contains compressed participant keys in aggregation order.
For BIP 373 MuSig2 PSBT Fields, what should a beginner know about public nonce?
Each public-nonce field identifies the participant, aggregate key and optional tapleaf hash, then stores the 66-byte public nonce produced by MuSig2 NonceGen.
Conclusion
BIP 373 makes MuSig2 coordination portable through PSBT, but it cannot replace signer-side transaction validation or nonce discipline. Each participant should treat the PSBT as untrusted state and prove every field before signing.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.



Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.