Solo Mining Calculator: Estimate Odds and Timeframes
Use a solo mining calculator correctly: enter productive hashrate, network conditions, uptime and time horizon, then read expected time and probability without.
Read article
ASIC mining knowledge centre
BIP 373 MuSig2 PSBT Fields: Multi-Signer Workflow Guide
BIP 373 guide to MuSig2 participant, public-nonce and partial-signature PSBT fields, signer roles, Taproot context, nonce safety and finalisation.
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.
What this means in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of a mempool as one node’s waiting room for valid transactions that have not yet entered a block. Different nodes can have different waiting rooms, and the contents can change from one second to the next.
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 BIP 373 MuSig2 PSBT Fields?
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.
Is BIP 373 MuSig2 PSBT Fields active or supported today?
BIP 373 is a Complete application-layer specification adding MuSig2 data to both PSBT version 0 and version 2.
Why does BIP 373 MuSig2 PSBT Fields matter?
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.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
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.
On this page
Search More Guides
BIP-110 Explained: Rules, Signalling and Why It Closed
BIP-110 explained in detail: its seven consensus restrictions, 55% signalling threshold, chain-split risk and August 2026 closure.
Read article
Bitcoin Core 29.4 Release: Chainstate Disk I/O Guide
Bitcoin Core 29.4 guide covering repeated chainstate rewrites, regular compaction, LevelDB seek compaction, transaction-data lifetime and wallet sizing fixes.
Read article
Need Advice for Your Mining Setup?
Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.