If you have already read about MuSig2 and PSBTs, you may wonder how the two technologies actually work together.
MuSig2 allows multiple Bitcoin participants to cooperate in creating a single Schnorr signature. PSBTs provide a standardized way for wallets and signing devices to exchange transaction information.
But there was a problem.
A normal PSBT did not contain all the information required by the MuSig2 signing process.
That’s where BIP-373 comes in.
BIP-373, titled “MuSig2 PSBT Fields,” extends the Partially Signed Bitcoin Transaction format with fields specifically designed to carry MuSig2 information.
In simple terms:
BIP-327 defines how MuSig2 works.
BIP-371 adds Taproot information to PSBTs.
BIP-373 adds MuSig2 information to PSBTs.
This makes BIP-373 an important bridge between collaborative signing and the wallet software that needs to coordinate it.
What Is BIP-373?
BIP-373 is a Bitcoin Improvement Proposal that adds new fields to PSBTv0 and PSBTv2.
These fields allow a PSBT to carry information needed for a MuSig2 signing process.
The specification focuses on three important types of information:
- MuSig2 participant public keys
- MuSig2 public nonces
- MuSig2 partial signatures
It also defines a MuSig2-related output field.
The idea is straightforward.
A normal PSBT can carry transaction information and many types of signing data.
MuSig2 introduces additional participants and additional communication steps.
BIP-373 gives that additional information a standardized place inside the PSBT.
Why Did MuSig2 Need New PSBT Fields?
To understand BIP-373, it helps to remember how ordinary signing works.
With a simple Bitcoin transaction, one wallet may control the private key.
The basic process can look like:
Create transaction → Sign → Finalize → Broadcast
MuSig2 is different.
Multiple participants cooperate to produce one signature.
For example, imagine:
Alice
Bob
Carol
All three participate in one MuSig2 aggregate key.
The participants need to coordinate information before they can produce the final Schnorr signature.
That creates additional steps.
The existing PSBT fields were not designed to carry all of this MuSig2-specific information.
BIP-373 therefore adds new fields for that information.
A Quick Reminder: What Is MuSig2?
MuSig2 is a multisignature protocol based on Schnorr signatures.
Instead of putting several ordinary public keys and signatures directly into the final transaction, multiple participants can cooperate to produce a single aggregate public key and a single BIP-340-compatible signature.
A simplified structure looks like this:
Alice's key ──┐
│
Bob's key ────┼──→ MuSig2 aggregate key
│
Carol's key ──┘
↓
Collaborative signing
↓
One Schnorr signature
The blockchain can therefore see a single public key and signature, while the signing process behind that result involved several participants.
This is one of the reasons MuSig2 can be useful for advanced Bitcoin custody and multisigner systems.
Why Can’t a Normal PSBT Just Handle MuSig2?
This is the key question.
A PSBT already supports signatures and key information.
So why add another BIP?
Because MuSig2 is not simply:
“Three people each sign the same transaction.”
The participants must coordinate a specific signing protocol.
Among other things, they need to exchange:
Participant information
Public nonces
Partial signatures
The final signature is produced only after the participants complete the necessary MuSig2 steps.
A normal signature field cannot fully describe that process.
BIP-373 therefore gives these pieces their own standardized fields.
The Three Main MuSig2 PSBT Fields
BIP-373 introduces three important new input fields.
They are:
PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS
This field identifies the public keys participating in a MuSig2 aggregate key.
PSBT_IN_MUSIG2_PUB_NONCE
This field carries a participant’s public nonce.
PSBT_IN_MUSIG2_PARTIAL_SIG
This field carries a participant’s partial signature.
These fields represent different stages of the MuSig2 process.
You can think of them as:
Who is participating?
↓
What nonce did each participant commit?
↓
What partial signature did each participant produce?
↓
Combine the partial signatures
↓
Final Schnorr signature
1. MuSig2 Participant Public Keys
The first field is:
PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS
Before participants can cooperate, the signing software needs to know who belongs to the aggregate key.
Imagine an aggregate key created from three participants.
The PSBT can carry the participant public keys in a defined order.
Conceptually:
Aggregate Key
|
├── Alice
├── Bob
└── Carol
The PSBT therefore provides the signer with the information needed to understand which keys make up the MuSig2 aggregate.
This is important because participants need to derive the same aggregate key and use the same participant set.
Why Participant Order Matters
MuSig2 uses an aggregate public key derived from the participants.
The PSBT does not simply need a random collection of keys.
It needs the participant information in the appropriate structure and order.
This allows participating software to reproduce the same aggregate key rather than accidentally calculating a different one.
In other words, BIP-373 helps different wallet applications agree on:
“These are the participants in this MuSig2 key.”
That consistency is essential.
2. MuSig2 Public Nonces
The next field is:
PSBT_IN_MUSIG2_PUB_NONCE
This field is connected to one of the most important parts of the MuSig2 signing process: nonces.
A nonce is temporary signing information generated for a particular signing session.
In MuSig2, participants generate public nonce information that other participants need before they can produce their partial signatures.
The PSBT gives that information a standardized field.
Conceptually:
Alice → Public Nonce
Bob → Public Nonce
Carol → Public Nonce
↓
Nonce aggregation
↓
Signing continues
The important point is that these are not the participants’ private keys.
They are public nonce data used during the collaborative signing process.
Why Nonces Matter So Much
Nonce handling is one of the most sensitive parts of Schnorr-style signing.
A badly implemented nonce system can expose private-key information.
MuSig2 therefore requires careful nonce generation and state management.
BIP-373 does not invent the MuSig2 nonce algorithm.
That comes from BIP-327.
Instead, BIP-373 provides a way to carry the resulting public nonce information through the PSBT workflow.
So the relationship is:
BIP-327
defines the MuSig2 signing procedure.
BIP-373
defines how MuSig2 information can be transported through PSBTs.
3. MuSig2 Partial Signatures
After participants have the necessary nonce information, they can perform their individual part of the signing process.
The result is a partial signature.
BIP-373 stores that information using:
PSBT_IN_MUSIG2_PARTIAL_SIG
Imagine the three participants produce:
Alice → Partial Signature A
Bob → Partial Signature B
Carol → Partial Signature C
These are not yet the final Bitcoin signature.
They are pieces of the collaborative MuSig2 signing process.
From Partial Signatures to One Signature
Once all required partial signatures are available, they can be combined.
Conceptually:
Partial Signature A ──┐
Partial Signature B ──┼──→ PartialSigAgg
Partial Signature C ──┘
↓
Final BIP-340 Signature
The final result is a normal BIP-340-compatible Schnorr signature.
That distinction is important.
BIP-373 is not creating a new type of Bitcoin signature that the blockchain needs to understand.
Instead, it helps software coordinate the process that eventually produces a standard Schnorr signature.
Why This Is Useful
This structure allows multiple independent signing devices or participants to work together.
For example:
Alice’s hardware wallet
↓
provides her MuSig2 information
Bob’s hardware wallet
↓
provides his information
Carol’s hardware wallet
↓
provides her information
The PSBT can carry the relevant pieces between the participants and the software coordinating the transaction.
That means participants do not have to rely on one custom communication format invented by a single wallet developer.
BIP-373 provides a common standard.
BIP-373 and BIP-371 Work Together
You’ve already covered BIP-371, which adds Taproot fields to PSBT.
BIP-373 builds on that environment.
A Taproot output may use a MuSig2 aggregate key as its internal key or in another Taproot construction.
When that happens, software may need both:
Taproot information
and:
MuSig2 information
BIP-371 handles the Taproot side.
BIP-373 handles the MuSig2 side.
A simplified relationship looks like this:
PSBT
|
┌─────────┴─────────┐
│ │
BIP-371 BIP-373
Taproot data MuSig2 data
│ │
└─────────┬─────────┘
↓
Collaborative
Taproot signing
This is why these BIPs fit naturally together.
BIP-373 and BIP-327
The easiest way to remember their relationship is:
BIP-327 = MuSig2 protocol
BIP-373 = MuSig2 PSBT fields
BIP-327 explains how participants generate nonces, aggregate keys, create partial signatures, verify them, and eventually produce a final signature.
BIP-373 explains how the relevant MuSig2 information can travel through the PSBT system.
One defines the signing machinery.
The other defines the communication container for that machinery.
Does BIP-373 Change Bitcoin’s Consensus Rules?
No.
BIP-373 is an application-layer specification.
It doesn’t introduce a new Bitcoin transaction type.
It doesn’t change how Bitcoin nodes validate a Schnorr signature.
It doesn’t change the rules of Taproot.
Instead, it extends the PSBT format used by wallets and signing software.
The distinction is important:
Bitcoin consensus
decides whether the final transaction is valid.
BIP-373
helps software create that valid transaction by coordinating MuSig2 signing information.
Does BIP-373 Create a New Type of Multisig?
Not exactly.
MuSig2 itself is a multi-party signing protocol.
But the final result is a regular BIP-340-compatible Schnorr signature.
BIP-373 doesn’t create another on-chain multisignature format.
It provides the communication infrastructure needed to use MuSig2 in PSBT-based workflows.
This means you should think of BIP-373 as a coordination standard, not a new blockchain consensus mechanism.
A Simple BIP-373 Example
Imagine Alice, Bob, and Carol control a Taproot output through a MuSig2 aggregate key.
Alice starts creating a transaction.
Her wallet creates a PSBT.
The PSBT contains the transaction information.
BIP-373 can then provide the MuSig2-specific information required for the signing process.
The participants are identified.
Public nonces are exchanged through the PSBT.
Each participant produces a partial signature.
The partial signatures are combined.
The result is one BIP-340-compatible Schnorr signature.
The transaction can then be finalized and broadcast.
So the overall process becomes:
Create transaction
↓
Create PSBT
↓
Identify MuSig2 participants
↓
Exchange public nonces
↓
Create partial signatures
↓
Aggregate partial signatures
↓
Final Schnorr signature
↓
Finalize PSBT
↓
Broadcast transaction
Why BIP-373 Matters for Modern Bitcoin Wallets
Bitcoin wallets are becoming more sophisticated.
A modern wallet may need to work with:
- Taproot
- Schnorr signatures
- PSBTs
- Hardware wallets
- Multisigner custody
- MuSig2
- HD key derivation
- Descriptors
Each system solves a different problem.
BIP-373 helps connect MuSig2 with the PSBT infrastructure that wallets already use.
That makes it especially relevant for advanced custody systems where multiple participants need to cooperate without exposing their private keys to a central coordinator.
The Three Main Input Fields
BIP-373 defines three new per-input MuSig2 fields:
PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYSPSBT_IN_MUSIG2_PUB_NONCEPSBT_IN_MUSIG2_PARTIAL_SIG
It also defines a corresponding output field:
PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS
All of these fields can be included in PSBTv0 and PSBTv2.
Let’s look at what each one does.
1. PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS
This is the field that tells the signing software which public keys participate in a particular MuSig2 aggregate key.
Imagine three participants:
Alice → Public Key A
Bob → Public Key B
Carol → Public Key C
MuSig2 combines their keys into one aggregate public key.
The PSBT therefore needs a way to represent the relationship between:
Aggregate Key
and:
Participant Keys
BIP-373 does this with PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS.
Why Does the Aggregate Key Need to Be Identified?
A PSBT may contain several inputs.
A wallet could also be involved with several MuSig2 aggregate keys.
The signer therefore needs to know exactly which participant keys belong to which aggregate key.
The field uses the compressed 33-byte aggregate public key as its keydata and carries the participants’ compressed public keys in the defined order.
Conceptually:
Aggregate Key A
|
├── Alice
├── Bob
└── Carol
Aggregate Key B
|
├── Dave
└── Erin
That prevents software from confusing one group of participants with another.
Why Is Participant Ordering Important?
MuSig2 does not treat the participant set as an unordered bag of keys.
The aggregate-key calculation depends on the participant keys and their ordering within the protocol.
That means every participant needs to derive the same aggregate key.
If one participant calculates:
Alice + Bob + Carol
while another interprets the participant arrangement differently, the resulting key information would not match.
BIP-373 therefore preserves the participant list in a defined order.
This gives different wallets and signing devices a common representation of the same MuSig2 group.
2. PSBT_IN_MUSIG2_PUB_NONCE
After identifying the participants, the next major step is nonce exchange.
BIP-373 represents this using:
PSBT_IN_MUSIG2_PUB_NONCE
A MuSig2 participant generates public nonce information for the signing session.
The PSBT then carries that public information so the other participants can use it.
The field’s keydata identifies:
- The participant’s compressed public key
- The compressed MuSig2 aggregate public key
- Optionally, a 32-byte hash that identifies the relevant transaction/input context
The value contains a 66-byte public nonce produced through the MuSig2 NonceGen process.
What Exactly Is a Public Nonce?
A nonce is temporary signing information.
In MuSig2, participants need nonces to collaboratively construct the final Schnorr signature.
You can think of the process like this:
Alice → Public Nonce A
Bob → Public Nonce B
Carol → Public Nonce C
↓
NonceAgg
↓
Combined nonce data
↓
Partial signing
The important distinction is that the public nonce is not the private key.
It is information that participants intentionally share as part of the signing protocol.
Why Is Nonce Security Important?
Nonce handling is one of the most sensitive parts of Schnorr-based cryptography.
BIP-373 itself warns signers that improper nonce use can compromise private keys and points implementations back to BIP-327 for nonce-generation and usage requirements.
This matters because MuSig2 signing is stateful.
A wallet cannot casually regenerate or reuse nonce material without following the protocol’s rules.
That is one reason professional wallet software needs careful MuSig2 implementation rather than simply treating it like an ordinary single-signature transaction.
3. PSBT_IN_MUSIG2_PARTIAL_SIG
After the participants have exchanged the required nonce information, they can perform their individual MuSig2 signing steps.
Each participant produces a partial signature.
BIP-373 stores it in:
PSBT_IN_MUSIG2_PARTIAL_SIG
The field identifies:
- The participant’s compressed public key
- The relevant compressed aggregate public key
- Optionally, the associated 32-byte hash
Its value is the participant’s 32-byte partial signature produced by the MuSig2 Sign algorithm.
Partial Signatures Are Not Final Signatures
This distinction is extremely important.
Suppose Alice, Bob, and Carol are participating.
They might produce:
Alice → Partial Signature A
Bob → Partial Signature B
Carol → Partial Signature C
None of these alone is the final Bitcoin signature.
Instead, they must be combined through the MuSig2 partial-signature aggregation process.
Conceptually:
Partial A ──┐
Partial B ──┼──→ PartialSigAgg → Final Schnorr Signature
Partial C ──┘
The resulting signature is compatible with BIP-340.
What Happens When All Partial Signatures Are Present?
Once all required participants have provided their partial signatures, the final signer can perform the MuSig2 PartialSigAgg operation.
The resulting signature is a standard BIP-340-compatible signature.
For a Taproot key-path spend, that signature can then be placed in:
PSBT_IN_TAP_KEY_SIG
For a Taproot script-path spend, it can instead be placed in:
PSBT_IN_TAP_SCRIPT_SIG
This is where BIP-373 and BIP-371 connect directly.
BIP-373 handles the MuSig2 signing process.
BIP-371 handles the Taproot PSBT fields that ultimately carry the completed Taproot signature.
The MuSig2 PSBT Workflow
Let’s put the pieces together.
Step 1: Identify the MuSig2 Aggregate Key
The wallet or PSBT updater recognizes that a Taproot input uses a MuSig2 aggregate key.
It can add:
PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS
This tells the other software which participants belong to the aggregate key.
Step 2: Each Signer Checks Whether It Is a Participant
A signer examines the participant information.
If the signer controls one of the participant private keys, it knows that it may have a role in the signing process.
BIP-373 describes the signer checking the participant fields and related Taproot BIP32 derivation information to determine whether it is a participant.
Step 3: Generate the Public Nonce
If that signer needs to participate and a public nonce has not already been provided for its key, the signer runs the appropriate MuSig2 nonce-generation procedure.
It then adds:
PSBT_IN_MUSIG2_PUB_NONCE
to the PSBT.
The other participants do the same.
Step 4: Aggregate the Nonces
Once the required public nonces are available, each signer can perform the MuSig2 nonce-aggregation step.
This creates the combined nonce information required for the next phase.
The participants must work from the same transaction and signing context.
Otherwise, they would not be producing compatible partial signatures.
Step 5: Create Partial Signatures
Each participant performs the MuSig2 signing operation.
The resulting partial signature is added as:
PSBT_IN_MUSIG2_PARTIAL_SIG
Now the PSBT contains multiple pieces of collaborative signing data.
For example:
Participant Keys
↓
Public Nonces
↓
Partial Signatures
Step 6: Aggregate the Partial Signatures
Once all required partial signatures are available, the final signer or a finalizer can perform the PartialSigAgg operation.
The result is the complete BIP-340-compatible Schnorr signature.
At this point, the MuSig2-specific signing work has produced the signature needed by the underlying Bitcoin transaction.
Step 7: Add the Final Taproot Signature
If the transaction uses a Taproot key-path spend, the resulting signature can be placed into:
PSBT_IN_TAP_KEY_SIG
The wallet can then proceed with PSBT finalization.
This is a useful way to understand the relationship between the two standards:
BIP-373
helps participants create the signature.
BIP-371
provides the Taproot PSBT field for the completed signature.
What Does the Updater Do?
BIP-373 defines different roles within the PSBT workflow.
The first is the updater.
The updater examines the transaction and adds information that other participants need.
When the updater recognizes a Taproot output involving a MuSig2 aggregate public key, it can add the participant public-key information.
It may also add Taproot BIP32 derivation information when the participant keys are derived from extended public keys.
Think of the updater as the person preparing the PSBT for the signing process.
Its job is to make sure the PSBT contains the information signers need.
What Does the Signer Do?
The signer is the participant who controls a relevant private key.
The signer:
- Identifies whether it is part of the MuSig2 aggregate.
- Generates the required public nonce.
- Adds the public nonce to the PSBT.
- Waits for the required nonce information.
- Creates its partial signature.
- Adds the partial signature to the PSBT.
The signer must also account for relevant key tweaks when the aggregate key has undergone derivation or other Taproot-related transformations.
What Does the Finalizer Do?
The finalizer completes the PSBT workflow.
If the partial signatures have not already been aggregated, the finalizer can perform that aggregation when it has the necessary information.
Once the final BIP-340 signature exists, the finalizer can treat it like the appropriate Taproot signature and continue the normal transaction-finalization process.
So the simplified roles are:
Updater
↓
Prepares MuSig2 information
Signer
↓
Creates nonce + partial signature
Finalizer
↓
Produces/uses final signature and completes PSBT
Where Does BIP-328 Fit?
BIP-373 also relates to BIP-328, the derivation scheme for MuSig2 aggregate keys.
This matters when the aggregate key is derived from a parent aggregate key.
For example:
Parent MuSig2 Aggregate Key
↓
Child Aggregate Key
↓
Taproot Output
If the PSBT needs to explain how the relevant public key was derived, BIP-373 can use Taproot BIP32 derivation information alongside the MuSig2 participant information.
BIP-373 states that derivation from an aggregate public key can be assumed to follow BIP-328 when the relevant synthetic extended public key is not separately specified.
This helps wallets reproduce the same keys without requiring private keys to be exchanged.
MuSig2 Change Outputs
BIP-373 isn’t limited to inputs.
It also defines:
PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS
This output field helps describe MuSig2 participant keys associated with a MuSig2 aggregate public key used in an output.
Why does that matter?
Consider a wallet creating a transaction that sends some Bitcoin to a recipient and sends the remaining change back to a MuSig2-controlled wallet.
The wallet needs to recognize its own change output.
MuSig2 participant information can help software understand that relationship.
BIP-373 therefore allows output information to be represented in a standardized way rather than forcing each wallet to invent its own method.
MuSig2 Inside a Taproot Input
Let’s look at a simplified example.
Suppose a Taproot output uses a MuSig2 aggregate key.
Three participants control that aggregate key:
Alice
+
Bob
+
Carol
↓
MuSig2 Aggregate Key
↓
Taproot Output
Alice begins a transaction.
Her wallet creates a PSBT.
The updater identifies the aggregate key and adds:
Participant Public Keys
The PSBT is passed to Bob.
Bob recognizes that he controls one of the participant keys.
He adds:
Public Nonce
Alice also adds her nonce.
Carol adds hers.
Once the required nonce information is available, each participant generates:
Partial Signature
The partial signatures are aggregated.
The result becomes:
One BIP-340 Schnorr Signature
The final signature is then handled through the Taproot PSBT workflow.
Why This Is Better Than Exchanging Random Files
Without a common standard, every wallet developer could design a custom MuSig2 signing package.
One wallet might use:
JSON
Another might use:
a proprietary binary format
Another might use:
a custom QR-code protocol
Those systems would not necessarily understand each other.
BIP-373 instead uses the existing PSBT framework.
That means MuSig2 information can travel alongside the transaction data already used by Bitcoin wallet software.
This improves interoperability.
Does Every MuSig2 PSBT Look the Same?
No.
Different transactions require different information.
A simple MuSig2 key-path spend may require a relatively small amount of MuSig2 information.
A more advanced transaction might involve:
- Multiple inputs.
- Multiple aggregate keys.
- Key derivation.
- Taproot scripts.
- Several signing participants.
- Multiple nonce sets.
The PSBT only needs the fields relevant to the transaction and signing process.
What Happens If Software Doesn’t Understand BIP-373?
PSBT was designed to be extensible.
BIP-373 states that older software will ignore the new MuSig2 fields.
However, this does not mean older software can perform MuSig2 signing.
Ignoring a field is different from understanding what the field means.
A wallet that doesn’t understand MuSig2 may simply leave those fields untouched.
A MuSig2-capable signer, however, can recognize them and continue the collaborative process.
This design helps preserve backward compatibility without pretending that old software has capabilities it doesn’t actually have.
A Useful Mental Model
The easiest way to remember BIP-373 is to imagine the PSBT as a shared folder.
Inside that folder are different pieces of information:
PSBT
|
┌──────────┼──────────┐
│ │ │
Participants Nonces Partial Sigs
│ │ │
└──────────┼──────────┘
↓
Final Signature
↓
Taproot Spend
The PSBT doesn’t perform the cryptography by itself.
Instead, it gives different pieces of Bitcoin wallet software a standardized place to exchange the information required by the cryptographic process.
BIP-373 in One Complete Flow
Here’s the entire process in simplified form:
1. Create transaction
↓
2. Create PSBT
↓
3. Identify MuSig2 aggregate key
↓
4. Add participant public keys
↓
5. Each signer identifies its own participant key
↓
6. Generate public nonces
↓
7. Add public nonces to PSBT
↓
8. Aggregate nonces
↓
9. Produce partial signatures
↓
10. Add partial signatures
↓
11. Aggregate partial signatures
↓
12. Produce BIP-340 Schnorr signature
↓
13. Add final Taproot signature
↓
14. Finalize PSBT
↓
15. Broadcast Bitcoin transaction
This is the central workflow that BIP-373 helps standardize.
Why BIP-373 Matters
BIP-373 may look like a collection of technical field definitions.
But its broader purpose is easier to understand.
MuSig2 makes collaborative signing possible.
PSBT makes transaction-signing information portable.
BIP-373 connects the two.
That connection allows several participants, wallets, and signing devices to exchange MuSig2 information without inventing a completely separate transaction format.
It makes advanced Bitcoin custody systems easier to build around common standards.
And because the final result is a BIP-340-compatible Schnorr signature, the Bitcoin network does not need to understand the entire communication process that happened behind the scenes.
The participants perform the complicated work.
The blockchain ultimately receives a valid Bitcoin transaction.
A Real-World MuSig2 PSBT Example
Imagine a company uses three independent hardware wallets to control Bitcoin.
The participants are:
Alice
Bob
Carol
They use MuSig2 to create one aggregate public key.
That aggregate key is then used for a Taproot output.
The company wants to spend some Bitcoin.
Here’s what happens.
Step 1: Create the Transaction
The wallet creates a transaction containing:
- One or more inputs.
- One or more outputs.
- Transaction amounts.
- The required fee.
The transaction still needs authorization.
Instead of immediately signing it, the wallet creates a PSBT.
Step 2: Add MuSig2 Information
The PSBT updater identifies the relevant MuSig2 aggregate key.
It can add:
PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS
This tells compatible software which participant public keys make up the aggregate key.
BIP-373 also allows related Taproot BIP32 derivation information to help signers identify participant keys derived from extended public keys.
Step 3: Send the PSBT to Participants
The PSBT can now move between the participating wallets or signing devices.
Alice receives it.
She checks whether one of her keys belongs to the MuSig2 participant set.
Bob does the same.
Carol does the same.
Each participant can determine whether they have a signing role for the relevant aggregate key.
Step 4: Generate Public Nonces
Each signer generates the required MuSig2 nonce information.
The public portion is added to the PSBT using:
PSBT_IN_MUSIG2_PUB_NONCE
The PSBT can therefore accumulate:
Alice’s public nonce
Bob’s public nonce
Carol’s public nonce
The participants can then use the complete nonce information for the next stage of the protocol.
Why Nonce Security Is Critical
This is one area where beginners should not treat MuSig2 like ordinary transaction signing.
Nonce generation and nonce reuse are security-sensitive.
BIP-373 specifically warns signers that improper nonce usage can compromise private keys and directs implementations to the nonce-generation and usage requirements in BIP-327.
In practical terms, users should rely on properly implemented wallet and hardware-wallet software rather than trying to manually manage MuSig2 nonce data.
The cryptographic protocol is designed to be safe when implemented and used correctly.
Poor implementation can change that.
Step 5: Produce Partial Signatures
After the participants have the necessary public nonce information, each signer performs the relevant MuSig2 signing operations.
Each participant produces a partial signature.
Those signatures are added to the PSBT using:
PSBT_IN_MUSIG2_PARTIAL_SIG
The PSBT might now contain:
Alice → Partial Signature
Bob → Partial Signature
Carol → Partial Signature
These are still not the final Bitcoin signature.
Step 6: Aggregate the Partial Signatures
Once the required partial signatures are available, MuSig2 can aggregate them.
The result is a BIP-340-compatible Schnorr signature.
BIP-373 explains that the final signer can perform this aggregation once the required partial signatures from the other signers are present. A finalizer can also perform the same aggregation if it has not already happened.
Conceptually:
Partial Signature A ──┐
Partial Signature B ──┼──→ MuSig2 aggregation
Partial Signature C ──┘
↓
Final Schnorr Signature
That final signature can then be handled as the appropriate Taproot signature.
Step 7: Connect Back to Taproot
This is where BIP-373 and BIP-371 fit together.
BIP-373 handles the MuSig2-specific signing information.
BIP-371 handles Taproot-specific PSBT information.
After MuSig2 produces the final BIP-340-compatible signature, BIP-373 specifies that it can be placed into:
PSBT_IN_TAP_KEY_SIG
or:
PSBT_IN_TAP_SCRIPT_SIG
depending on the Taproot spending path.
So the broader workflow looks like:
MuSig2 participants
↓
BIP-373 fields
↓
Final Schnorr signature
↓
BIP-371 Taproot signature field
↓
Final Bitcoin transaction
Hardware Wallets and BIP-373
Hardware wallets are a natural use case for this kind of architecture.
A hardware wallet can keep a participant’s private key inside the device while communicating with wallet software through a PSBT workflow.
For example:
Desktop wallet
creates the transaction.
↓
PSBT
carries the transaction and MuSig2 information.
↓
Hardware wallet
identifies its participant key and performs its signing operations.
↓
Signed PSBT
returns to the coordinating software.
Other participants can then perform their own signing steps.
This design allows a collaborative signing process without requiring participants to hand their private keys to a central computer.
However, the exact user experience depends on whether the wallet and hardware device actually support BIP-373 and the relevant MuSig2 functionality.
Bitcoin Core’s current documentation lists BIP-373 MuSig2 PSBT support as available starting in v30.0.
BIP-373 and Key Derivation
MuSig2 doesn’t have to stop at one fixed aggregate key.
More advanced wallet systems can derive child keys from an aggregate key.
This is where BIP-328 becomes relevant.
BIP-373 requires BIP-328 and specifically references MuSig2 aggregate-key derivation when appropriate.
A simplified structure looks like:
Participant Keys
↓
MuSig2 Aggregate Key
↓
Derived Child Key
↓
Taproot Output
This becomes useful for HD wallet systems because a single collaborative setup can produce a hierarchy of related keys.
The PSBT can carry the derivation information needed by participating software.
Taproot Tweaks Matter Too
A MuSig2 aggregate key can be used within a Taproot construction.
That means the signer may need to account for the relevant Taproot or BIP32 tweaks when producing the signature.
BIP-373 explicitly tells signers to apply relevant tweaks, including tweaks resulting from BIP32 unhardened derivation using the aggregate public key as the parent key.
This is another reason BIP-373 is more than a simple “signature-sharing” format.
The signer has to understand how the key used for signing relates to the actual output being spent.
MuSig2 vs Traditional Bitcoin Multisig
It is useful to distinguish MuSig2 from the traditional concept of Bitcoin multisig.
With a traditional multisig construction, the spending condition can explicitly require multiple signatures.
For example:
2-of-3
means that two out of three keys must authorize the transaction.
The transaction can reveal information about that spending structure.
MuSig2 approaches the problem differently.
Multiple participants cooperate to create a single aggregate public key and eventually one Schnorr signature.
That can create a much smaller and more ordinary-looking on-chain result, depending on how the output is constructed.
However, MuSig2 is not simply a drop-in replacement for every multisig policy.
It is an interactive signing protocol, and participants need to coordinate.
That makes its wallet and operational requirements different from a traditional script-based multisig setup.
BIP-373 vs BIP-327
These two BIPs are closely related, but they solve different problems.
BIP-327
Defines the MuSig2 cryptographic signing protocol.
It covers things such as:
- Key aggregation.
- Nonce generation.
- Nonce aggregation.
- Partial signing.
- Partial-signature verification.
- Partial-signature aggregation.
BIP-373
Defines the PSBT fields for carrying MuSig2 information.
It covers:
- Participant public keys.
- Public nonces.
- Partial signatures.
- MuSig2 participant information for outputs.
The easiest way to remember it is:
BIP-327 = How MuSig2 works
BIP-373 = How MuSig2 information travels through PSBTs
BIP-373 vs BIP-371
These BIPs are also easy to confuse.
BIP-371
Taproot Fields for PSBT
It adds PSBT fields for Taproot information.
BIP-373
MuSig2 PSBT Fields
It adds PSBT fields for MuSig2 information.
They can work together.
For a MuSig2-based Taproot transaction, the PSBT may contain both types of information.
Think of it like this:
PSBT
|
┌─────────┴─────────┐
↓ ↓
BIP-371 BIP-373
Taproot MuSig2
↓ ↓
└─────────┬─────────┘
↓
Signed Transaction
Is BIP-373 Required for Every Bitcoin Transaction?
No.
A normal single-key transaction doesn’t need MuSig2 information.
Even a traditional multisig transaction doesn’t automatically require BIP-373.
BIP-373 becomes relevant when a PSBT needs to carry MuSig2-specific data.
That means most ordinary Bitcoin users will never manually interact with a BIP-373 field.
Wallet software handles the details.
Does BIP-373 Change Bitcoin’s Blockchain?
No.
BIP-373 is an application-layer specification.
It does not introduce a new consensus rule.
It doesn’t require every Bitcoin node to understand MuSig2 PSBT fields.
Instead, wallet software uses the fields before the final transaction reaches the blockchain.
Once the final signature has been produced, Bitcoin nodes validate the resulting transaction using Bitcoin’s normal consensus rules.
This separation is important.
PSBT coordination happens off-chain.
Transaction validity is enforced on-chain.
Backward Compatibility
BIP-373 was designed as an extension to PSBT rather than a replacement for it.
The specification states that older PSBT software can ignore the new MuSig2 fields because PSBT is designed to be extensible.
However, there is an important limitation.
A wallet that ignores MuSig2 fields does not suddenly become a MuSig2 signer.
It may be able to transport or preserve the data without understanding it.
Actual MuSig2 participation requires software that understands the protocol and the corresponding PSBT fields.
So compatibility has two different meanings:
Can the software preserve the PSBT?
and:
Can the software perform MuSig2 signing?
Those are not the same thing.
Common BIP-373 Mistakes
Treating Partial Signatures as Final Signatures
A MuSig2 partial signature is only one participant’s contribution.
It cannot simply be broadcast as the finished Bitcoin signature.
It must be combined according to the MuSig2 protocol.
Reusing Nonce Material Incorrectly
Nonce handling is security-critical.
Poor nonce management can expose private-key information.
Wallet software should follow the nonce requirements defined by MuSig2 rather than attempting to improvise a custom process.
Confusing Participant Keys With the Aggregate Key
A MuSig2 setup contains individual participant keys and an aggregate key.
These serve different purposes.
The PSBT needs enough information to identify both the aggregate relationship and the individual participant.
Forgetting Relevant Derivation Information
When participant or aggregate keys are derived through HD wallet structures, signing software needs the appropriate derivation information.
Otherwise, a hardware wallet may not know which private key corresponds to the public key referenced by the PSBT.
Assuming Every Wallet Supports MuSig2
Bitcoin wallets do not automatically support every BIP.
A PSBT implementation may support basic PSBT functionality without supporting MuSig2.
Always verify that the wallet and signer actually support the required MuSig2 workflow.
What Are the Advantages of BIP-373?
Standardization
Wallet developers can use a common structure for MuSig2 PSBT data.
Better Interoperability
Different compatible applications can exchange participant keys, nonces, and partial signatures using PSBT.
Hardware-Wallet Workflows
The standard fits naturally into signing workflows that keep private keys inside secure devices.
Works With PSBTv0 and PSBTv2
BIP-373 adds fields that can be included in both supported PSBT versions.
Supports Advanced Custody
MuSig2 can support collaborative custody arrangements where multiple participants need to authorize spending.
Connects Existing Standards
BIP-373 bridges MuSig2 with the broader PSBT and Taproot ecosystem.
What Are the Limitations?
BIP-373 doesn’t eliminate the complexity of collaborative signing.
Participants Still Need to Coordinate
MuSig2 is an interactive signing protocol.
Participants need to exchange the required information.
Nonce Management Remains Critical
A standardized PSBT field doesn’t make bad cryptographic practices safe.
Wallet Support Varies
Users need compatible wallet and signer software.
It Doesn’t Replace Security Practices
Users still need secure backups, trusted hardware, and careful transaction verification.
It Doesn’t Change Bitcoin’s Consensus Rules
The BIP helps produce transactions; it doesn’t make the blockchain itself understand the entire MuSig2 signing workflow.
Frequently Asked Questions
What is BIP-373?
BIP-373 is the Bitcoin Improvement Proposal titled “MuSig2 PSBT Fields.” It adds PSBT fields for information used by the MuSig2 signing protocol.
What is the status of BIP-373?
BIP-373 is currently listed as Complete.
Who authored BIP-373?
The specification was authored by Ava Chow.
What does PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS do?
It identifies the participant public keys belonging to a MuSig2 aggregate public key.
What does PSBT_IN_MUSIG2_PUB_NONCE do?
It carries a participant’s MuSig2 public nonce for the signing process.
What does PSBT_IN_MUSIG2_PARTIAL_SIG do?
It carries the partial signature created by a MuSig2 participant.
What is the final MuSig2 signature?
After the required partial signatures are aggregated, the result is a BIP-340-compatible Schnorr signature.
Does BIP-373 create a new Bitcoin signature type?
No. It helps coordinate MuSig2 signing, which ultimately produces a BIP-340-compatible Schnorr signature.
Does BIP-373 replace BIP-327?
No.
BIP-327 defines the MuSig2 protocol.
BIP-373 defines the PSBT fields used to carry MuSig2 information.
Does BIP-373 replace BIP-371?
No.
BIP-371 handles Taproot PSBT fields, while BIP-373 handles MuSig2 PSBT fields.
Does BIP-373 work with PSBTv2?
Yes. The specification allows its fields in PSBTv0 and PSBTv2.
Can BIP-373 be used with hardware wallets?
It can support hardware-wallet workflows when the wallet and signing device implement the required MuSig2 and PSBT functionality.
Does BIP-373 make Bitcoin more private?
Not by itself.
BIP-373 is a PSBT/application-layer specification. Any privacy characteristics come from the underlying Bitcoin construction and how the wallet uses it.
Does BIP-373 reduce transaction fees?
Not directly.
Its job is to transport MuSig2 signing information. Fee savings, where they occur, come from the transaction structure and other Bitcoin features rather than from the PSBT field definitions themselves.
BIP-373 in Simple Terms
Imagine three people need to approve one Bitcoin transaction.
Instead of putting three independent signatures directly into the final transaction, they use MuSig2 to collaborate on one Schnorr signature.
But the participants still need to exchange information during the signing process.
BIP-373 gives them a standardized PSBT-based way to do that.
The simplified process is:
Participant keys
↓
Public nonces
↓
Partial signatures
↓
Final Schnorr signature
↓
Taproot transaction
That’s BIP-373’s role.
It is the communication layer connecting MuSig2’s collaborative signing process with the PSBT infrastructure used by Bitcoin wallets.
Final Thoughts
What is BIP-373?
BIP-373 is the Bitcoin standard that adds MuSig2-specific fields to PSBTs.
It exists because MuSig2 introduces information and communication steps that older PSBT fields could not represent.
The specification gives wallets and signing devices standardized fields for:
Participant public keys
Public nonces
Partial signatures
It also supports MuSig2 participant information for outputs.
The result is a structured workflow:
Create transaction
↓
Create PSBT
↓
Identify MuSig2 participants
↓
Exchange public nonces
↓
Generate partial signatures
↓
Aggregate partial signatures
↓
Create BIP-340 Schnorr signature
↓
Finalize the PSBT
↓
Broadcast the transaction
BIP-373 doesn’t change Bitcoin’s consensus rules.
It doesn’t replace Taproot.
It doesn’t replace MuSig2.
And it doesn’t replace PSBT.
Instead, it connects them.
That is what makes it valuable.
As Bitcoin wallets become more sophisticated, standards such as BIP-371 and BIP-373 allow advanced cryptographic systems to work with common wallet infrastructure rather than requiring every application to invent its own communication format.
For beginners, the most important takeaway is simple:
BIP-327 explains how MuSig2 works. BIP-373 explains how MuSig2 information can move through PSBTs.
Once you understand that relationship, the rest of BIP-373 becomes much easier to follow.
Related posts:
Bitcoin Silent Payments Explained: How to Send Bitcoin Privately Without Revealing Your Address
Bitcoin Payment Links & QR Codes: What Is a Bitcoin Payment URI?
Bitcoin Payments Are Getting a Human Friendly Upgrade: What Is BIP 353?
Bitcoin’s Hidden Superpower: What Is BIP-371 and Why Does It Matter?