MuSig2 (Multi-Signature Scheme)

What Is MuSig2?

MuSig2 (Multi-Signature 2) is a cryptographic protocol that allows multiple parties to jointly produce a single Schnorr signature indistinguishable from an ordinary single-signer signature. Published at CRYPTO 2021 by Jonas Nick, Tim Ruffing, and Yannick Seurin, MuSig2 represents the second generation of the MuSig family of multi-signature schemes. It is formally standardized in BIP-327, which was merged into the Bitcoin BIPs repository in March 2023.

Traditional Bitcoin multisig using OP_CHECKMULTISIG places every public key and every signature directly on-chain. A 3-of-3 transaction reveals three keys and three signatures, broadcasting both the signer count and the spending structure to any blockchain observer. MuSig2 collapses all of this into a single 32-byte aggregate public key and a single 64-byte signature. On-chain, the transaction is indistinguishable from a payment authorized by one person.

This compression is possible because Schnorr signatures have a property called linearity: partial signatures from multiple signers can be summed to produce a valid aggregate signature. ECDSA, the signature scheme used in pre-Taproot Bitcoin, does not have this property. MuSig2 therefore requires the Taproot soft fork, which activated in November 2021 and introduced native Schnorr signature verification via BIP-340.

How It Works

MuSig2 operates in two phases: a one-time key aggregation setup, followed by a two-round signing protocol that repeats for every transaction.

Key Aggregation

Before signing, participants combine their individual public keys into a single aggregate public key using the KeyAgg algorithm defined in BIP-327:

1. Each signer shares their public key
2. A coefficient is computed for each key using a tagged hash of the complete set of participant keys
3. The aggregate key is the weighted sum of all individual keys, using these coefficients as multipliers

Key aggregation is non-interactive: the only requirement is that each signer knows every other signer's public key. The resulting aggregate key can serve directly as a Taproot internal key. Funds sent to this key are spendable only when all signers cooperate.

Round 1: Nonce Exchange

When a transaction needs to be signed, each participant generates two random secret scalars and computes the corresponding elliptic curve points. The two points form the signer's public nonce (66 bytes), while the secret scalars and the signer's public key form the secret nonce (97 bytes).

Each signer shares only their public nonce. Once all nonces are collected, the NonceAgg algorithm combines them by summing the nonce points. A key optimization: nonces can be generated and exchanged before the transaction is known, allowing this round to be preprocessed and reducing the interactive signing to a single round-trip once the transaction is ready.

Round 2: Partial Signature Exchange

With the transaction message and all public nonces available, each signer computes a partial signature. The effective combined nonce is calculated as:

R = R1 + b * R2

where:
  R1, R2 = aggregated nonce points
  b = tagged_hash(R1, R2, aggregate_pubkey, message)

Each signer then produces their partial signature:

s_i = (k1_i + b * k2_i + e * a_i * d_i) mod n

where:
  k1_i, k2_i = signer i's secret nonce scalars
  e = Schnorr challenge hash(R, aggregate_pubkey, message)
  a_i = key aggregation coefficient for signer i
  d_i = signer i's private key (with parity adjustment)

After exchanging partial signatures, the PartialSigAgg algorithm sums all partial signature scalars to produce the final aggregate signature (R, s). The result is a standard BIP-340 Schnorr signature that verifies against the aggregate public key using ordinary signature verification. No special multisig logic is needed on the verification side.

Identifiable Aborts

BIP-327 includes a PartialSigVerify algorithm that checks each signer's contribution individually. If a participant submits an invalid partial signature (whether through a bug or malicious intent), the other signers can identify exactly which party misbehaved rather than simply detecting that the final aggregate is invalid.

Evolution from MuSig1

The original MuSig protocol, published in 2018 by Gregory Maxwell, Andrew Poelstra, Yannick Seurin, and Pieter Wuille, required three rounds of communication:

1. Nonce commitment: each signer shares a hash committing to their nonce
2. Nonce reveal: each signer opens their commitment after seeing all others
3. Partial signature exchange

The extra commitment round existed to prevent a subtle attack. Without it, an adversary who sees honest signers' nonces before choosing their own can manipulate the combined nonce to forge a valid signature. This is a variant of the rogue-key attack: the attacker effectively controls the aggregate nonce and can compute a valid signature without the honest signers' cooperation.

Three rounds made MuSig1 impractical for many real-world applications, especially those involving high-latency communication or hardware signing devices. An intermediate proposal called MuSig-DN attempted to address this with deterministic nonces and zero-knowledge proofs, but the computational cost was prohibitive.

MuSig2 solved the problem elegantly: each signer generates two nonces instead of one, and the effective nonce is computed as a random linear combination (R = R1 + b * R2). This eliminates the commitment round while maintaining provable security under concurrent signing sessions. The protocol is proven secure under the algebraic one-more discrete logarithm (AOMDL) assumption.

MuSig2 vs. Script-Based Multisig

The practical differences between MuSig2 and traditional OP_CHECKMULTISIG are significant:

BitGo, the first major custodian to deploy MuSig2, reports approximately 47 vBytes savings per input compared to native SegWit multisig, translating to roughly 30% lower transaction fees. For a detailed comparison, see the multisig wallets research article.

Relationship to FROST

FROST (Flexible Round-Optimized Schnorr Threshold signatures) is a closely related protocol. Both produce standard Schnorr signatures indistinguishable from single-signer outputs on-chain, but they solve different problems:

• MuSig2 is n-of-n: every signer must participate in every signing session, using simple, non-interactive key aggregation
• FROST is m-of-n: only a threshold subset of signers is needed, but setup requires a more complex Distributed Key Generation (DKG) ceremony

MuSig2 can approximate threshold behavior by pre-computing aggregate keys for every valid signer combination and encoding them as leaves in a Taproot script tree. For a 2-of-3 setup, this means three leaf scripts (one per pair). The approach becomes impractical at larger scales: a 5-of-10 configuration would require 252 leaf scripts. For such cases, FROST is the better choice.

Spark uses FROST for its operator-side signing, enabling a flexible custody model where any sufficient subset of operators can participate in signing without requiring every operator to be online for every transaction. For a deeper look at how these schemes compare, see the FROST threshold signatures research article.

Use Cases

Lightning Network Channels

Lightning channel funding outputs are 2-of-2 multisig: both channel partners must sign to spend. MuSig2 replaces the legacy P2WSH multisig format with a single Taproot key path, making channel opens and cooperative closes indistinguishable from ordinary payments. LND integrated MuSig2 for Taproot channels starting in 2023, and Lightning Loop migrated to MuSig2 by default in 2025.

Custodial and Collaborative Wallets

Any arrangement where multiple parties jointly control funds benefits from MuSig2. Custodians use it for hot wallets with the aggregate key as the Taproot internal key for the cooperative spending path. When all signers are online, transactions settle through the key path with maximum privacy and minimum fees. Collaborative setups such as joint accounts, corporate treasury, and inheritance planning all benefit from the reduced on-chain footprint.

Protocol-Level Signing

Layer 2 protocols use MuSig2 for cooperative operations where all parties are expected to be online: channel closures, collaborative exits, and state updates. Combined with PSBTs (using BIP-373 for MuSig2 fields), the signing workflow integrates with existing wallet software including hardware signing devices. For a comprehensive look at how MuSig2 fits into the broader multisignature landscape, see the MuSig2 multisignatures research article.

Risks and Considerations

Nonce Reuse Is Catastrophic

If a signer ever reuses a secret nonce across two different signing sessions, their private key can be extracted algebraically. This is not a theoretical concern: a malicious co-signer can deliberately trigger this by opening two signing sessions and providing different nonces to the victim in each session, while the victim unknowingly reuses the same nonce.

BIP-327 mandates random nonce generation rather than deterministic nonces. Unlike single-signer Schnorr or ECDSA where deterministic nonces (RFC 6979) are safe, in MuSig2 an adversary can replay protocol messages to force nonce reuse. The sole exception is the DeterministicSign variant, which allows exactly one signer (typically a hardware wallet) to generate nonces deterministically after receiving all other signers' nonces.

Interactivity Requirement

Every signing session requires two rounds of communication between all participants. If any signer is offline, the transaction cannot be signed. This contrasts with script-based multisig where signers can independently produce their signatures at different times. For setups involving cold storage or air-gapped devices, the round-trip requirement adds operational complexity.

n-of-n Limitation

MuSig2 requires all signers to participate. Losing access to any single signer's key means the funds are unspendable through the MuSig2 key path. Practical deployments typically combine MuSig2 with Taproot script paths that provide fallback spending conditions (timelocks, alternative signer sets) to mitigate this single-point-of-failure risk. For native threshold signing without combinatorial blowup, protocols like FROST are more appropriate.

Security Assumptions

MuSig2's security proof relies on the algebraic one-more discrete logarithm (AOMDL) assumption in the Random Oracle Model combined with the Algebraic Group Model. This is a stronger assumption than the plain discrete logarithm problem used for single-signer Schnorr signatures. While the cryptographic community considers it sound, implementers should be aware that the protocol's security rests on more assumptions than a standard digital signature.

Ecosystem Adoption

Since standardization, MuSig2 has seen growing adoption across the Bitcoin ecosystem. BitGo deployed it for Taproot multisig hot wallets. Ledger added MuSig2 support in their Bitcoin app (version 2.4.0). The libsecp256k1 library added an optional MuSig2 module in October 2024, and Bitcoin Core is integrating MuSig2 descriptor support via BIP-390. On the protocol side, LND uses MuSig2 for Taproot channel funding outputs, and complementary BIPs ( BIP-328 for key derivation, BIP-373 for PSBT fields) continue to round out the toolchain.

For an interactive reference on Schnorr and MuSig2 operations, see the Schnorr and MuSig2 reference tool.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.