Scientific and technical paper. Object of study: migrating artifacts of the MuSig2 interactive protocol to the Partially Signed Bitcoin Transaction (PSBT) format. Regulatory basis: BIP-373 ( Proposed status , June 4, 2024), BIP-327, BIP-340, BIP-341, BIP-174, BIP-370, and BIP-328.
Contents: Abstract; PSBT and MuSig2 context; Cryptographic model; Input and output fields; Protocol roles; Taproot and BIP32 derivation; Cryptanalytic fact about nonces; Test vectors; Validation; Compatibility; Recommendations.
Annotation
BIP-373 defines extensions to PSBT versions 0 and 2 to carry three classes of MuSig2 data: a list of participants’ public keys, public nonces, and partial signatures. The standard does not change Bitcoin consensus or introduce a new signature algorithm: it standardizes the serialization and interdevice state exchange required by BIP-327 to produce a single BIP-340-compatible signature.
A scientifically significant aspect of BIP-373 is that the container format becomes a cryptographic security boundary. The nonce and partial signature fields store provably meaningful intermediate protocol values; misassociating them with a specific session, key, aggregate key, message, or Tapleaf creates the conditions for denial of service, missignature, and, if the secret nonce is reused, algebraic derivation of the long-term secret key.
1. Context of the standard
PSBT separates transaction construction from signing: different devices can add data to independent “global-level-inputs-outputs” maps. Prior to BIP-373, the basic PSBT fields did not express the two interactive rounds of MuSig2—the exchange of public nonces and the transfer of partial signatures—so proper inter-wallet exchange was unstandardized.
MuSig2 aggregates the keys of a fixed set of participants and produces a single Schnorr signature. In a key-path blockchain, spending a Taproot output appears as a regular single BIP-340 signature: the number of participants, their partial signatures, and public nonces are not published in the witness.
Normative status
| Parameter | Meaning |
|---|---|
| Identifier | BIP-373 |
| Layer | Applications |
| Type | Standards Track |
| Status | Proposed — a specification is proposed for implementation; it is not a network consensus rule. |
| License | CC0-1.0 |
| Compatible containers | BIP-174 PSBTv0 and BIP-370 PSBTv2 |
2. Cryptographic model
Let the secp256k1 group have order n and generator G. Participant i owns a scalar x_i and a public key P_i = x_iG. To mitigate the rogue-key attack of simple key addition, MuSig2 computes aggregation coefficients a_i as hash-dependent on an ordered list L of keys.
LaTeX block: key aggregation
\[
L = H_{\mathrm{KeyAgg\ list}}(P_1 \Vert \cdots \Vert P_u), \qquad
a_i = H_{\mathrm{KeyAgg\ coefficient}}(L \Vert P_i),
\]
\[
P_{\mathrm{agg}} = \sum_{i=1}^{u} a_i P_i.
\]
Each participant creates a pair of secret nonces k_{i,1}, k_{i,2} and publishes the points R_{i,1}=k_{i,1}G, R_{i,2}=k_{i,2}G. After aggregating the public nonces and calculating the coefficient b, the protocol forms an effective nonce R; then partial signatures s_i are created, which are summed into a scalar s. The final BIP-340 signature is of the form (r,s).
LaTeX block: simplified MuSig2 circuit
\[
R_1 = \sum_i R_{i,1}, \qquad R_2 = \sum_i R_{i,2}, \qquad
b = H_{\mathrm{noncecoef}}(R_1 \Vert R_2 \Vert P_{\mathrm{agg}} \Vert m),
\]
\[
R = R_1 + bR_2, \qquad e = H_{\mathrm{challenge}}(r \Vert P_{\mathrm{agg}} \Vert m),
\]
\[
s_i = k_{i,1} + b k_{i,2} + e a_i x_i \pmod n, \qquad
s = \sum_i s_i \pmod n.
\]
A real implementation of BIP-327 takes into account parity normalization, key tweaks, and mode-specific details; the expressions provided are a cryptographic model for auditing data relationships. The final check boils down to the Schnorr equality: sG = R + eP, where P is the appropriate aggregated and, if necessary, tweaked public key.
A historical cryptanalytic example
The “repeated nonce reveals the secret” class of errors has been known for a long time, predating Bitcoin: in 2010, a glitch in the random number generator on Sony PlayStation 3 devices allowed a repeated ECDSA nonce to be used to recover the secret key. For Schnorr- and MuSig2-like linear schemes, the similar danger is even more mathematically straightforward: the same secret nonce in two different equations yields a linear system with respect to the long-term secret.
3. New PSBT fields
BIP-373 defines three input fields and one output field. In all cases, aggregate and participant keys are serialized as compressed 33-byte secp256k1 keys, although in Taproot they may appear as x-only 32-byte representations.
| Region | Type | Key data | Meaning | Versions |
|---|---|---|---|---|
| Input | PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS = 0x1a | 33-byte compressed aggregate pubkey | Concatenate 33-byte participant pubkeys in KeyAgg order | v0, v2 |
| Input | PSBT_IN_MUSIG2_PUB_NONCE = 0x1b | participant pubkey (33) || aggregate pubkey (33) || tapleaf hash (32, optional) | public nonce, strictly 66 bytes | v0, v2 |
| Input | PSBT_IN_MUSIG2_PARTIAL_SIG = 0x1c | Same structure as public nonce | partial signature, strictly 32 bytes | v0, v2 |
| Output | PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS = 0x08 | 33-byte compressed aggregate pubkey | Ordered list of participant pubkey | v0, v2 |
3.1. Field 0x1a
PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS Records the set of participants from which a particular aggregate key was obtained. The list order is mandatory: if KeyAgg sorted the keys, the value must contain the sorted order, since the coefficients a_i depend on the list L.
keytype = 0x1a keydata = ser33(P_agg) valuedata = ser33(P_1) || ser33(P_2) || ... || ser33(P_u)
A practical example. In the BIP-373 reference vector, an aggregate 030b58...7107d4 is associated with three participants beginning with 02346b..., , 024faf... and 02f930.... This list allows a hardware signer to discover its own P_i without revealing x_i and determine which aggregate its share belongs to.
3.2. Field 0x1b
PSBT_IN_MUSIG2_PUB_NONCE carries the participant’s public nonce: two compressed dots, or 66 bytes. Its keydata links the nonce simultaneously to the participant, the aggregated key, and, when script-path spent, to a 32-byte BIP-341 Tapleaf hash.
keytype = 0x1b keydata = ser33(P_i) || ser33(P_agg) || [tapleaf_hash] valuedata = ser33(R_i,1) || ser33(R_i,2) # 66 bytes
If the aggregate is an internal or output key of Taproot, the tapleaf hash is absent; it is included for signing a specific leaf. This decoupling is critical: the same P_agg can be used in multiple leaves, but the session nonce should not be implicitly carried over between different messages and spend paths.
3.3. Field 0x1c
PSBT_IN_MUSIG2_PARTIAL_SIG Uses the same identification structure as 0x1b, but contains a single 32-byte partial signature scalar. The aggregator or final signer applies PartialSigAgg only after verifying the complete set of nonces and partial signatures, and then records the result as PSBT_IN_TAP_KEY_SIG or PSBT_IN_TAP_SCRIPT_SIG.
keytype = 0x1c keydata = ser33(P_i) || ser33(P_agg) || [tapleaf_hash] valuedata = bytes32(s_i)
An example from the test archive. To spend a Taproot output, where the output key is a MuSig2 aggregate, BIP-373 publishes a sequence of PSBTs: first a list of keys, then three public nonces, then three partial signatures. This demonstrates that the container reflects the protocol’s state machine and is not a passive repository of arbitrary entries.
3.4. Output 0x08
PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS Transfers the same “aggregate-participant” mapping to outputs. Its primary operational purpose is change-output detection: a wallet can match the aggregate key of a created output with its keyset and BIP32 provenance.
4. Protocol roles
| Role | Regulatory action | Security control |
|---|---|---|
| Updater | Adds 0x1a for the known MuSig2 aggregate, as well as Taproot/BIP32 compatible metadata | When the derived key in MuSig2 fields indicates the parent P_agg, and the path is fixed in PSBT_IN_TAP_BIP32_DERIVATION |
| Signer | Finds its P_i; adds 0x1b; after all nonces, adds 0x1c | Checks the transaction, key/tapleaf context, and nonce secret; applies tweaks |
| Final signer / Finalizer | Executes PartialSigAgg and places the resulting signature into the standard Taproot field | Checks the correctness of partial signatures before aggregation; does not consider the presence of fields as proof of their validity |
Sequence of rounds
- Updater generates or supplements the PSBT with participant and derivation metadata.
- Each signer locally creates a fresh secret nonce and adds only the corresponding public nonce (0x1b).
- Once the full set of public nonces is available, each signer performs NonceAgg and Sign, adding a partial signature (0x1c).
- The last signer or finalizer verifies the shares, executes PartialSigAgg and writes the final BIP-340 signature.
- Standard PSBT finalization and extraction create a completed transaction.
5. Taproot, BIP32 and serialization
BIP-373 intentionally uses a full compressed 33-byte aggregate key rather than the x-only form. The reason is twofold: BIP32 public derivation requires a parity byte, and the master key fingerprint depends on the full public key. This allows devices that don’t fully implement MuSig2 to recognize the key’s origin and correctly apply the tweak.
If the key found in the script or output was not obtained directly by KeyAgg, but by unhardened BIP32 derivation from the aggregate, fields 0x1a–0x1c must contain the original P_agg. The path from P_agg to the found key is specified in PSBT_IN_TAP_BIP32_DERIVATION; in the absence of a synthetic xpub in PSBT_IN_GLOBAL_XPUB BIP-373, the BIP-328 scheme can be assumed.
LaTeX block: unhardened public derivation (schematic)
\[
P_{\mathrm{child}} = P_{\mathrm{parent}} + \mathrm{parse}_{256}(I_L)G,
\]
where \(I_L\) is the left half of the HMAC-SHA512 of the parent and index data.
6. Cryptanalytic Fact: Nonce Repeat
Critical requirement. The public nonce can be stored in the PSBT, but the secret nonce cannot be reused across any two MuSig2 Sign invocations. BIP-327 explicitly states that repeating the same secret nonce across two Sign invocations makes it possible to extract the secret signing key from two partial signatures.
In the simplified case, with a constant effective nonce k and two different challenges e_1, e_2 for the same participant, we have: s_1 = k + e_1 a_i x_i and s_2 = k + e_2 a_i x_i. Subtraction eliminates k; if e_1 is not equal to e_2, the secret is extracted by the usual inversion modulo n.
LaTeX Block: Algebraic Repeated Nonce Attack
\[
s_1 - s_2 = (e_1-e_2)a_i x_i \pmod n,
\]
\[
x_i = (s_1-s_2)\, igl((e_1-e_2)a_i igr)^{-1} \pmod n.
\]
The full MuSig2 formula includes two nonce components and a coefficient b, which can vary between sessions; however, the principle remains the same: two partial signatures with a reused secnonce form a solvable linear system. Therefore, the PSBT coordinator should not be considered a trusted source of the nonce state, and the signer is required to maintain a local, one-time secnonce lifecycle: CSPRNG/NonceGen, session binding, exactly-once use, immediate cryptographically secure erasure.
Connection with the history of cryptanalysis
Insufficient entropy and nonce duplication incidents in DSA/ECDSA demonstrate a classic form of this threat: nonce leakage turns the discrete logarithm problem into a linear computation. Practical studies of Bitcoin signatures repeatedly use the search for duplicate r in ECDSA as an indicator of k duplication; in BIP-340/MuSig2, only the final signature is typically committed to the blockchain, making internal protocol auditing, nonce-less logging, and negative replay tests particularly important.
7. BIP-373 Vectors
The specification includes valid PSBT vectors for three MuSig2 aggregate locations: directly as the Taproot output key, as an internal key, and as a key within a tapscript. For the first two key-path scenarios, the tapleaf hash is omitted; in the script-path scenario, it is included in the keydata public nonce and partial signature.
| Scenario | Semantics | Verifiable invariant |
|---|---|---|
| Output key = P_agg | The unit directly specifies the Taproot output key | 0x1b/0x1c are addressed without tapleaf hash |
| Internal key = P_agg | The aggregate has been tweaked to the output key, taking into account the Taproot tree. | Tweak and BIP341 key-path sighash consistency |
| Tapscript key = P_agg | The unit appears in a specific script sheet | tapleaf hash uniquely associates nonce/doli with leaf |
| Receiving/change | A MuSig2-compatible output is created | 0x08 and Taproot BIP32 derivation provide change recognition |
The set also contains negative vectors: x-only aggregate key where a compressed 33-byte key is expected; public nonce of incorrect length; partial signature of incorrect length; empty participant list; mismatched participant key. These cases should be turned into unit tests of the deserializer and validator before connecting the hardware device to real devices.
8. Compatibility and boundaries
PSBT extensibility means that older applications can ignore unfamiliar BIP-373 fields. This preserves syntactic compatibility, but does not make the older wallet MuSig2-compatible: it will not perform interactive rounds and may not provide the operator with sufficient visibility into the signature context.
Reuse PSBT_IN_TAP_BIP32_DERIVATION for participant paths allows for a situation in which a MuSig2-unaware signer issues a signature for their own key. According to BIP-373, this does not result in a loss of funds: if the key is not directly in the signed leaf script, the signature is unplayable; if it is, the signer has already validated the script as acceptable.
9. Recommendations for the audit
- Accept 0x1a, 0x1b, 0x1c and 0x08 only in PSBTv0/v2, checking for exact lengths: 33-byte compressed keys, 66-byte public nonce, 32-byte partial signature.
- Check that P_i belongs to the list of members of a specific P_agg, that there are no duplicates, and that the canonical order is consistent with KeyAgg.
- For each 0x1b and 0x1c, match the same context: P_i, P_agg, optional tapleaf hash, sighash message, and applicable tweaks.
- Never serialize the secret nonce to the PSBT, log, telemetry, crash dump, or backup; after Sign, erase the secret nonce and prevent re-querying.
- Before issuing 0x1c to the user, independently verify the transaction: inputs, outputs, amounts, commission, network, script path, and derivation path.
- Before PartialSigAgg, perform PartialSigVerify on each share and reject conflicting or incomplete sets of public nonces.
- Test implementations on official BIP-373 positive and negative vectors, including output keys, internal keys, and tapscript branches.
Conclusion
BIP-373 is an interoperability standard for MuSig2 operations in PSBT: it defines how to transfer the aggregate identity, participant contributions, and two interactive signing rounds between wallets without changing the Bitcoin consensus. Its key engineering requirement goes beyond serialization: security is determined by the strict binding of nonces and partial signatures to sessions and the unconditional one-time use of the secret nonce.
Normative sources
Regulatory Standard Bitcoin Core Developers: BIP-373 — MuSig2 PSBT Fields: https://douban.ru/regulatory-standard-bitcoin-core-developers-bip-373-musig2-psbt-fields/