MuSig2: Aggregated Signatures for Bitcoin Multisig

Bitcoin's adoption of Schnorr signatures through the Taproot upgrade unlocked a class of cryptographic protocols that were previously impractical on the network. Among the most significant is MuSig2: a multi-signature scheme that allows multiple signers to produce a single, compact signature indistinguishable from a regular single-key signature on-chain. The result is better privacy, lower fees, and a foundation for more sophisticated Bitcoin applications.

This article traces the evolution from the original MuSig protocol to MuSig2, explains the two-round signing protocol in detail, compares MuSig2 to FROST for threshold signing, and examines where each scheme fits in the Bitcoin ecosystem.

From Schnorr to Multi-Signatures

Schnorr signatures have a property that ECDSA lacks: linearity. Given two Schnorr signatures on the same message, you can add them together to produce a valid signature under the sum of the two public keys. This algebraic structure makes key aggregation and signature aggregation natural operations rather than cryptographic hacks.

Before Taproot, Bitcoin multisig required listing every public key and every signature in the spending script. A 3-of-3 multisig transaction carried three public keys and three signatures in witness data, making it visually and computationally distinct from a single-signer transaction. With Schnorr-based key aggregation, those three signers can combine their keys into one aggregated public key and produce one aggregated signature. On-chain, the transaction looks identical to any other single-key Taproot spend.

Why this matters for privacy: When a MuSig2 multi-signature spend hits the blockchain, no observer can determine how many parties were involved. A 5-of-5 corporate treasury spend looks the same as an individual sending from a personal wallet. This breaks the heuristic that chain analysis firms use to identify multisig addresses.

The Road to MuSig2

Building a secure multi-signature scheme on Schnorr is harder than the linearity property suggests. The naive approach of simply adding partial signatures is vulnerable to rogue key attacks, where a malicious signer chooses their public key as a function of the honest signers' keys to forge signatures unilaterally. The MuSig family of protocols addressed this and other attacks iteratively.

MuSig (2018)

The original MuSig paper by Maxwell, Poelstra, Seurin, and Wuille introduced a provably secure n-of-n Schnorr multi-signature scheme. It defeated rogue key attacks using a technique where each signer's public key is multiplied by a coefficient derived from the hash of all participants' keys. The protocol required three communication rounds between signers:

1. Exchange commitments to nonces (hash of each signer's nonce)
2. Exchange the actual nonces
3. Exchange partial signatures

The three-round structure existed to prevent a subtle vulnerability: if a signer could see other signers' nonces before choosing their own, they could manipulate the aggregate nonce to produce a forgery. The commitment round (round 1) solved this by forcing all signers to commit to their nonces before any nonce was revealed.

Three rounds of communication made MuSig impractical for many real-world use cases. Each round requires all signers to be online, exchange messages, and wait for responses, a significant burden for protocols like Lightning where signing happens on every channel state update.

MuSig-DN (2020)

The MuSig-DN paper (Deterministic Nonce) by Nick, Ruffing, Seurin, and Wuille attempted to reduce communication to two rounds by using deterministic nonces derived from the signing key and message. By making nonces deterministic, there was no need for a commitment round: each signer could prove they generated their nonce honestly using a zero-knowledge proof.

While cryptographically sound, MuSig-DN was computationally expensive. Generating the required zero-knowledge proofs took significant time and the proofs themselves were large. This made MuSig-DN more of a theoretical stepping stone than a practical protocol for Bitcoin wallets or Lightning nodes.

MuSig2 (2020)

The MuSig2 paper by Nick, Ruffing, and Seurin solved the round-reduction problem elegantly. Instead of deterministic nonces or commitment rounds, each signer generates multiple nonces per signing session and sends them all in the first round. The aggregate nonce is then computed as a linear combination of these nonces, weighted by a hash-derived coefficient. This prevents the nonce manipulation attack without requiring commitments.

The Two-Round Signing Protocol

MuSig2's two-round protocol is now standardized as BIP 327. Understanding the mechanics requires walking through what each signer does in each round.

Setup: Key Aggregation

Before any signing takes place, participants aggregate their individual public keys into a single aggregated key. Each signer's key is multiplied by a coefficient computed from the hash of all participants' public keys (the KeyAgg algorithm in BIP 327). This step needs to happen only once for a given set of signers and produces the aggregated public key that goes on-chain.

The coefficient multiplication is what prevents rogue key attacks. A malicious signer cannot choose their key to cancel out honest signers' contributions because the coefficient depends on all keys, creating a circular dependency.

Round 1: Nonce Exchange

Each signer generates a pair of secret nonces (two random scalars) and computes the corresponding public nonce points. These public nonces are broadcast to all other participants. Critically, nonces can be pre-shared before the message to be signed is even known, which allows for a "non-interactive signing" workflow in practice: nonces are exchanged ahead of time, and when a signing request arrives, only one more round of communication is needed.

Round 2: Partial Signatures

Once all nonces are collected and the message is known, each signer computes an aggregate nonce from everyone's nonce contributions. The aggregate nonce is a linear combination of each signer's two nonce points, weighted by a coefficient derived from hashing the nonces and the message. Each signer then produces a partial signature using their secret key, their secret nonces, and the aggregate nonce.

Partial signatures are collected and summed to produce the final aggregated signature. This final signature is a standard Schnorr signature that can be verified against the aggregated public key using Bitcoin's existing BIP 340 verification algorithm. No special verification logic is needed.

Nonce reuse is fatal: If a signer ever reuses a nonce pair across two different signing sessions, their secret key can be extracted algebraically. This is not a theoretical concern: it is a fundamental property of Schnorr signatures. BIP 327 implementations must ensure nonces are generated fresh for each session and securely deleted after use.

Walking Through a Signing Session

Consider a 3-of-3 MuSig2 setup with signers Alice, Bob, and Carol who want to collaboratively sign a Bitcoin transaction.

1. Alice, Bob, and Carol each generate two secret nonces and share the corresponding public nonce points with each other.
2. Once all six public nonce points are collected (two per signer), each signer locally computes the aggregate nonce using the deterministic combination algorithm from BIP 327.
3. Each signer computes a partial signature: a Schnorr signature using their individual key and nonces, relative to the aggregate nonce and aggregated public key.
4. The three partial signatures are summed. The result is a single 64-byte Schnorr signature.
5. The transaction is broadcast. Any Bitcoin node verifies it as a standard Taproot key-path spend. The signature occupies the same space as any single-signer transaction.

Why N-of-N: The Design Constraint

MuSig2 is fundamentally an n-of-n scheme: every registered signer must participate in every signing session. This is not an arbitrary limitation but a consequence of the key aggregation math. The aggregated public key is a function of all signers' keys, and a valid signature under that aggregated key requires a partial signature from every participant.

For scenarios where all parties are expected to be online and cooperative (such as both sides of a Lightning channel), n-of-n is the natural fit. Both channel partners must agree on every state update, making the n-of-n requirement align with the protocol's existing assumptions.

However, n-of-n becomes a liability when signers may be unavailable. If one signer in a 5-of-5 MuSig2 setup loses their keys or goes offline, the funds are permanently locked. There is no fallback for partial participation within the MuSig2 protocol itself.

MuSig2 vs FROST: N-of-N vs T-of-N

FROST (Flexible Round-Optimized Schnorr Threshold Signatures) solves the availability problem by enabling t-of-n threshold signing. In a FROST setup, any t signers out of n total can produce a valid signature. Like MuSig2, the resulting signature is a standard Schnorr signature indistinguishable from single-key spends on-chain.

FROST achieves this through Shamir's Secret Sharing, distributing key shares such that any t shares can reconstruct the signing capability (without ever reconstructing the full secret key). The tradeoff is additional protocol complexity: FROST requires a Distributed Key Generation (DKG) ceremony during setup, which is more involved than MuSig2's simple key aggregation.

The choice between MuSig2 and FROST depends on the application's trust and availability assumptions. Spark, for example, uses FROST rather than MuSig2 because the protocol requires threshold signing across its operator set. Spark operators collectively hold one key in a two-of-two arrangement with the user, and FROST ensures that any sufficient subset of operators can participate in signing without requiring every operator to be online for every transaction. This 1-of-n security model (where only one honest operator is needed) would be impossible with MuSig2's all-or-nothing design.

Applications in Bitcoin

Lightning Channel Outputs

Lightning channels are inherently two-party: the channel opener and the counterparty must both sign every commitment transaction. This makes Lightning a natural fit for 2-of-2 MuSig2. With Taproot channels, the funding output can be a single aggregated key, and cooperative closes produce a single Schnorr signature.

The privacy improvement is substantial. Under the legacy format, Lightning channel opens and cooperative closes were identifiable on-chain by their 2-of-2 multisig pattern. With MuSig2, these transactions become indistinguishable from ordinary single-signer Taproot spends, making it harder for chain analysis to map the Lightning Network's topology.

The efficiency gain also matters. Each Taproot channel close saves roughly 33 vbytes compared to legacy SegWit multisig outputs because the aggregated signature replaces two individual signatures and the multisig script.

Collaborative Custody

For custody arrangements where all keyholders are expected to sign (such as a business checking account requiring both co-founders), MuSig2 provides a straightforward n-of-n setup. The traditional multisig approach reveals the number of signers and the threshold on-chain, while MuSig2 hides this entirely.

For more complex custody setups requiring fault tolerance (corporate treasuries, inheritance schemes), MuSig2 alone is insufficient, and FROST or a Taproot script-path fallback is needed. A common pattern combines MuSig2 for the key-path spend (the happy path where all parties cooperate) with script-path leaves encoding fallback spending conditions using Bitcoin Script and timelocks.

Privacy Enhancement

MuSig2 collapses multi-party operations into single-party appearances on-chain. This applies beyond multisig wallets:

• CoinJoin coordinators can use MuSig2 for the coordinator-participant relationship, making coordinated transactions harder to identify
• Atomic swaps can hide the multi-party nature of cross-chain trades
• Lightning routing nodes operating as businesses can obscure their channel management activity
• Exchanges performing batched withdrawals can aggregate internal signing into single-sig appearances

PTLCs and Adaptor Signatures

MuSig2 is a building block for Point Time-Locked Contracts (PTLCs), which use adaptor signatures instead of hash-based HTLCs for Lightning payments. In a PTLC, the payment secret is a discrete logarithm rather than a hash preimage, and adaptor signatures allow the secret to be extracted from a valid signature. MuSig2 enables two-party adaptor signatures for Taproot-based PTLC implementations while maintaining the single-sig on-chain appearance.

Implementation Status

MuSig2 has moved from academic paper to production-ready code. The primary implementation lives in libsecp256k1-zkp, Blockstream Research's fork of the libsecp256k1 library that Bitcoin Core uses for cryptographic operations. The module provides the full MuSig2 API: key aggregation, nonce generation, nonce aggregation, partial signing, partial signature aggregation, and verification.

BIP 327

BIP 327 formalizes the MuSig2 protocol for Bitcoin. It specifies the exact algorithms for key aggregation (KeyAgg), nonce generation (NonceGen), nonce aggregation (NonceAgg), signing (Sign), partial signature aggregation (PartialSigAgg), and verification (PartialSigVerify). The BIP includes test vectors and a reference implementation in Python.

BIP 327 also defines how MuSig2 interacts with Taproot key-path spends and how tweaking (for Taproot commitment) works with aggregated keys. This is essential for using MuSig2 in scripts that commit to a Taproot tree of alternative spending conditions.

Wallet and Protocol Adoption

Several Bitcoin projects have implemented or are integrating MuSig2:

• LND's Taproot channel implementation uses MuSig2 for funding outputs and cooperative closes
• BitGo has integrated MuSig2 for Taproot-based multisig wallets
• The PSBT format is being extended (BIP 373) to carry MuSig2 participant public keys and nonces, enabling hardware wallet interoperability
• LDK (Lightning Dev Kit) supports MuSig2 for Taproot channels

Security Considerations

Nonce Management

The single most critical implementation concern with MuSig2 is nonce management. Reusing a nonce across two signing sessions leaks the signer's secret key. BIP 327 addresses this with a deterministic nonce derivation that incorporates the signer's secret key, the aggregated public key, the message, and a session-unique random value. Implementations must also ensure that secret nonces are stored securely and deleted after the signing session completes.

For hardware wallets, nonce management is particularly challenging. A hardware signer that participates in round 1 (generating nonces) must persist those nonces across a potentially long delay before round 2 (signing). If the device loses power between rounds, it must either regenerate the nonces deterministically or refuse to sign, as generating new nonces for the same session could lead to nonce reuse in edge cases.

Concurrent Signing Sessions

MuSig2 supports concurrent signing sessions, meaning a signer can participate in multiple signing sessions simultaneously using different nonces. However, this requires careful bookkeeping to ensure nonces are never mixed between sessions. The BIP 327 specification defines a session context structure that binds nonces to specific signing sessions, preventing accidental cross-session contamination.

Wagner's Attack and Multi-Nonces

The reason MuSig2 uses two nonces per signer (rather than one) is to defeat a generalized birthday attack (Wagner's algorithm) on the nonce aggregation step. With a single nonce per signer, an attacker running many parallel sessions could potentially forge signatures using related nonce values. The linear combination of two independent nonces per signer, weighted by a hash-derived coefficient, breaks this attack. This is the core innovation that makes MuSig2 simultaneously two-round and provably secure under standard cryptographic assumptions.

Limitations and Tradeoffs

MuSig2 is not a universal solution for every multi-party signing scenario. Understanding its boundaries helps developers choose the right tool.

• N-of-n requirement means no fault tolerance: a single lost key permanently locks funds unless a script-path fallback is included
• All signers must be online (or pre-share nonces) for both rounds: asynchronous signing workflows require careful nonce pre-generation
• Key aggregation is specific to a fixed signer set: adding or removing a participant requires creating a new aggregated key and moving funds
• No native accountability: if a signing session fails, MuSig2 does not reveal which signer refused to cooperate (FROST can provide accountability through share verification)
• Taproot script-path fallbacks (for recovery if a signer disappears) partially negate the privacy benefits by revealing the multisig structure when invoked

MuSig2 in the Broader Signature Landscape

MuSig2 and FROST are complementary protocols, not competitors. The Bitcoin ecosystem benefits from both, deployed where their respective strengths align with application requirements.

Lightning channels use MuSig2 because both parties must always agree. Spark uses FROST because its operator model requires threshold participation. Multisig custody solutions may combine both: MuSig2 on the key-path for efficient cooperative spends, with Taproot script-path leaves encoding threshold or timelocked fallbacks.

Both protocols produce standard Schnorr signatures that are indistinguishable on-chain. This is the deeper point: Schnorr linearity provides a unified signature format regardless of how many parties or what threshold was involved, and Bitcoin's Taproot upgrade makes this universally available. MuSig2 is one of the first major protocols to capitalize on that foundation, and its BIP 327 standardization ensures interoperability across wallets, hardware signers, and protocol implementations for years to come.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.