Bitcoin Core's MuSig2 PSBT Validation: Making Multisig More Robust

On March 4, 2026, Bitcoin Core merged pull request #34219, completing a security fix for MuSig2 multisignature support in Partially Signed Bitcoin Transactions (PSBTs). The change adds validation for elliptic curve public keys when deserializing MuSig2 public nonces and partial signatures, preventing crashes that could occur when malformed PSBTs contain invalid cryptographic data.

This is unglamorous infrastructure work, but it’s exactly the kind of defensive programming that makes Bitcoin reliable. As MuSig2 adoption grows, ensuring that wallet software handles edge cases correctly matters more.

What the fix does

Bitcoin Core now validates that public keys in PSBT_IN_MUSIG2_PUB_NONCE and PSBT_IN_MUSIG2_PARTIAL_SIG fields are valid elliptic curve points during PSBT deserialization.

Without this validation, a malformed PSBT containing invalid public keys could trigger uninitialized memory reads, assertion failures during MuSig2 signing operations, or node crashes when processing corrupted PSBT data.

The fix ensures that Bitcoin Core rejects invalid PSBTs early with a descriptive error message rather than crashing later when attempting cryptographic operations on invalid data.

Context: MuSig2 and PSBTs

What is MuSig2?

MuSig2 is a multisignature scheme defined in BIP 327 that allows multiple parties to cooperatively create Schnorr signatures that are indistinguishable from single-signature transactions. Key benefits:

• Privacy: N-of-N multisig looks identical to single-key spend on-chain
• Efficiency: Single aggregate public key, single signature (not N separate signatures)
• Two-round protocol: Only two rounds of communication needed between signers
• Taproot compatible: Works with BIP 340 Schnorr signatures introduced in Taproot

Unlike traditional Bitcoin multisig (which uses OP_CHECKMULTISIG and reveals the multisig structure on-chain), MuSig2 produces ordinary Schnorr signatures. An external observer cannot tell whether a transaction was signed by one person or a coordinated group.

What are PSBTs?

Partially Signed Bitcoin Transactions (BIP 174, extended by BIP 370 for PSBTv2) are a standard format for passing incomplete transactions between different signers and devices. They bundle the unsigned transaction, metadata needed to sign (UTXOs, scripts, derivation paths), and partial signatures collected so far.

PSBTs are critical for hardware wallet workflows (wallet software ↔ signing device), multisig coordination (multiple parties signing the same transaction), and air-gapped signing setups.

How MuSig2 uses PSBTs

BIP 373 extends the PSBT format with three new per-input field types specifically for MuSig2:

1. PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS (0x1a): Lists the compressed public keys of all participants in the MuSig2 aggregate key
2. PSBT_IN_MUSIG2_PUB_NONCE (0x1b): Stores the 66-byte public nonce from each participant (required in round 1 of signing)
3. PSBT_IN_MUSIG2_PARTIAL_SIG (0x1c): Stores the 32-byte partial signature from each participant (produced in round 2)

The workflow: an updater adds participant pubkeys to the PSBT. Each signer generates and adds their public nonce. Once all nonces are collected, each signer produces a partial signature. The final signer (or coordinator) aggregates partial signatures into a valid BIP 340 signature.

Each of these fields includes public key identifiers to track which participant provided which nonce or signature. These keys must be valid elliptic curve points. That’s what this fix ensures.

Timeline of the bug and fix

Discovery (December 2025)

Issue #33999 (reported December 3, 2025): Contributors Murch and maflcko discovered via fuzzing that Bitcoin Core could crash when processing PSBTs with invalid MuSig2 pubkeys. Running the PSBT fuzzer with memory sanitizers or Valgrind revealed crashes with span<T>::subspan(offset, count): offset out of range errors.

Issue #34201 (reported January 5, 2026): A second fuzzing crash was found in the utxoupdatepsbt RPC call, triggering Assertion 'tweaked' failed in SignMuSig2 when Bitcoin Core tried to perform signature aggregation on invalid pubkeys.

Both issues were found by Google’s OSS-Fuzz infrastructure running against Bitcoin Core’s fuzzing harnesses. The fuzzer fed Bitcoin Core malformed PSBTs where public keys in MuSig2 fields were not valid curve points.

First fix: PR #34010 (merged January 5, 2026)

Contributor rkrux submitted PR #34010 titled “psbt: detect invalid MuSig2 pubkeys in deserialization.”

What it fixed: Added validation for the PSBT_IN_MUSIG2_PARTICIPANT_PUBKEYS field. If an aggregate or participant pubkey was not a valid elliptic curve point, Bitcoin Core would now throw an error during PSBT deserialization instead of crashing later.

What it missed: The PR only validated participant pubkeys. It did not add validation for pubkeys embedded in the PSBT_IN_MUSIG2_PUB_NONCE and PSBT_IN_MUSIG2_PARTIAL_SIG fields.

Second fix: PR #34219 (merged March 4, 2026)

Contributor tboy1337 submitted PR #34219 titled “psbt: validate pubkeys in MuSig2 pubnonce/partial sig deserialization” to complete the fix.

What it added:

• Extended validation to cover pubkeys in both PSBT_IN_MUSIG2_PUB_NONCE and PSBT_IN_MUSIG2_PARTIAL_SIG
• Updated the DeserializeMuSig2ParticipantDataIdentifier function to check that both aggregate and participant pubkeys are fully valid elliptic curve points
• Added comprehensive test coverage to prevent regression

The fix validates pubkeys immediately when parsing PSBT fields, ensuring that any invalid key triggers a deserialization error before it can cause problems downstream.

Maintainer fanquake merged the PR on March 4, 2026, after review by wallet and PSBT experts including achow101 and darosior.

Why this matters

Hardware wallet interoperability

Hardware wallets (Ledger, Trezor, Coldcard) rely on the PSBT format to coordinate signing with host software. As MuSig2 support arrives on hardware devices (Ledger Bitcoin app v2.4.0 added MuSig2 support in April 2025), hardware wallets must correctly parse and validate MuSig2 PSBT fields.

A malformed PSBT could crash wallet software or cause silent failures in multisig coordination. This fix ensures that Bitcoin Core validates PSBT data before sending it to hardware signers or receiving it from external sources.

Multisig wallet security

MuSig2 is being adopted for corporate treasuries (BitGo’s Taproot multisig integration), personal multisig setups (2-of-2, 3-of-3 cold storage), and future Lightning Network channel factories.

Without proper validation, an attacker could craft a malicious PSBT that causes a coordinator node to crash, wallet software might accept invalid partial signatures and fail silently, or debugging signing failures becomes harder when invalid data is not caught early.

Robust error handling

The fix improves Bitcoin Core’s defensive posture. It fails fast (invalid data is rejected at deserialization, not deep in signing logic), provides clear errors (users and developers get descriptive error messages instead of cryptic crashes), and maintains forward compatibility (as MuSig2 adoption grows, robust PSBT parsing prevents future bugs).

Growing MuSig2 adoption

MuSig2 usage is expanding. BIP 327 (MuSig2 specification) finalized in 2023. BIP 373 (MuSig2 PSBT fields) was adopted in 2024. Hardware wallet support arrived in 2025. Wallet software (Sparrow, Electrum, BTCPay Server) is adding support.

As more tools implement MuSig2, ensuring that Bitcoin Core’s PSBT handling is bulletproof becomes critical for ecosystem-wide interoperability.

Technical details: the vulnerable fields

Both PSBT_IN_MUSIG2_PUB_NONCE (0x1b) and PSBT_IN_MUSIG2_PARTIAL_SIG (0x1c) have a key structure that includes public keys with this format: <33-byte participant pubkey> <33-byte aggregate pubkey> [<32-byte hash>].

Before the fix, Bitcoin Core would deserialize these byte sequences without verifying that the 33-byte compressed pubkeys represented valid points on the secp256k1 elliptic curve.

A compressed secp256k1 public key is 33 bytes: 0x02 or 0x03 prefix + 32-byte x-coordinate. Valid keys satisfy the curve equation: y² = x³ + 7 (mod p).

Invalid examples include random 33 bytes that don’t correspond to a curve point, pubkeys with invalid prefix bytes, or all-zero or all-0xFF byte strings.

When cryptographic operations (nonce aggregation, signature verification) attempt to use an invalid pubkey, they fail unpredictably. Sometimes returning errors, sometimes hitting assertions, sometimes reading uninitialized memory.

The DeserializeMuSig2ParticipantDataIdentifier function now calls validation on both the participant and aggregate pubkeys during PSBT deserialization, before any signing logic runs.

What this doesn’t fix

This is not a remote exploit or consensus issue.

Not a network vulnerability: This only affects local PSBT parsing. An attacker cannot crash a remote node just by broadcasting transactions.

Not a consensus issue: Invalid PSBTs are rejected and never make it into blocks. The Bitcoin network consensus rules are unaffected.

Not a fund loss risk: Even without the fix, invalid PSBTs would fail to produce valid signatures. No scenario allows stealing funds.

The real risk is denial of service in wallet software and signing coordinators. A malicious actor could feed corrupted PSBTs to a multisig coordinator to disrupt signing operations.

Implications for wallet developers

If you maintain Bitcoin wallet software that handles MuSig2 PSBTs:

• Validate early: Check pubkey validity when parsing PSBT fields, not when attempting to sign
• Handle errors gracefully: Invalid PSBTs should produce clear error messages for users
• Test with fuzzed inputs: Use the Bitcoin Core qa-assets corpus to test your PSBT parser
• Follow BIP 373 strictly: Ensure your MuSig2 PSBT implementation matches the specification exactly

Expected in Bitcoin Core 31.0

This fix is part of the Bitcoin Core 31.0 milestone, which is currently in development (as of March 2026). The milestone has 96 closed issues and 11 remaining open issues. A release date has not been announced, but Bitcoin Core typically releases major versions every 6-8 months.

Users running Bitcoin Core 30.x or earlier do not have this fix. While the risk is low (requires processing malicious PSBTs), upgrading to 31.0 when released is recommended for anyone coordinating MuSig2 multisig wallets.

Broader context: Taproot maturation

This fix is part of the ongoing maturation of Taproot (activated November 2021) and its associated technologies:

• 2021: Taproot activation (BIP 340/341/342: Schnorr signatures, Taproot, Tapscript)
• 2023: BIP 327 (MuSig2) finalized
• 2024: BIP 373 (MuSig2 PSBT fields) adopted
• 2025: Hardware wallets add MuSig2 support
• 2026: Bitcoin Core continues hardening MuSig2 PSBT handling

As Taproot adoption increases (as of early 2026, around 15% of Bitcoin transactions use Taproot outputs), ensuring that multisig tools work reliably is critical for the ecosystem.

Traditional multisig vs. MuSig2

Feature	Traditional Multisig	MuSig2
On-chain footprint	Reveals M-of-N structure	Single pubkey (private)
Signature size	M signatures (64+ bytes each)	1 signature (64 bytes)
Transaction size	Larger (scales with M)	Same as single-sig
Fees	Higher (more witness data)	Lower (minimal witness data)
Privacy	Low (multisig visible)	High (indistinguishable from single-sig)
Coordination	Simpler (less rounds)	Requires 2-round protocol + nonce management
Trust model	M-of-N (flexible threshold)	N-of-N only (all participants must sign)

MuSig2’s efficiency and privacy benefits come at the cost of more complex coordination. Robust PSBT handling is essential to make that coordination reliable.

Key takeaways

Bitcoin Core PR #34219 completes validation for MuSig2 public keys in PSBT pubnonce and partial signature fields. Merged March 4, 2026, as part of the Bitcoin Core 31.0 milestone.

The fix prevents crashes when processing malformed PSBTs with invalid elliptic curve points. It benefits multisig wallet users, hardware wallet developers, and MuSig2 coordinators.

Impact: low severity (requires local malicious PSBT), high importance (prevents denial of service in multisig workflows).

The bugs were caught by fuzzing before public exposure. This is the kind of unglamorous but essential work that keeps Bitcoin infrastructure secure as new technologies like MuSig2 mature and gain adoption.

Sources: GitHub PR #34219, GitHub Issue #33999, GitHub Issue #34201, GitHub PR #34010, BIP 327, BIP 373, BIP 174, Ledger Bitcoin App v2.4.0. Data current as of March 5, 2026.