MuSig2 is a cryptographic multi-signature scheme described in a 2020 IACR ePrint paper (later published at CRYPTO 2021) by Jonas Nick (Blockstream), Tim Ruffing (Blockstream), and Yannick Seurin (Agence nationale de la sécurité des systèmes d’information, ANSSI France). It defines a protocol for N parties to collaboratively produce a single Schnorr signature that verifies under their aggregated public key — requiring only two communication rounds and provably secure under concurrent session attacks.

MuSig2 is the cryptographic primitive that powers Taproot key-path multi-party spends in Bitcoin, Lightning Network PTLC channels, and threshold wallets that want on-chain privacy.

> IACR ePrint: eprint.iacr.org/2020/1261

> Published at CRYPTO 2021, LNCS 12825, pp. 189–221

---

Publication and Context

The predecessor scheme, MuSig1 (Nick, Ruffing, Seurin, Wuille — 2018), provided the first provably secure Schnorr multi-signature protocol but required three communication rounds:

1. Commitment round (each party commits to their nonce)
2. Nonce round (each party reveals their nonce)
3. Signature round (each party produces partial signature)

Three rounds cause significant UX friction for hardware wallets and distributed signers: each round requires user confirmation or physical device interaction. The goal of MuSig2 was to eliminate one round without sacrificing the security properties.

Why can’t you just do two rounds naively? The commitment round in MuSig1 exists to prevent Wagner’s generalized birthday attack: if a party learns all others’ nonces before committing its own, it can manipulate its nonce to cancel out others’ nonces and produce a forgery. MuSig2’s contribution is a technical insight: using two nonces per party instead of one, and combining them in a specific way, prevents Wagner’s attack without requiring a commitment phase. The security proof (under the Discrete Logarithm assumption in the random oracle model) confirms this.

---

The MuSig2 Protocol

Key Aggregation

Given signers with individual keypairs (x₁, X₁), (x₂, X₂), …, (xₙ, Xₙ):

1. Each party broadcasts their public key Xᵢ to all others
2. All parties compute a key aggregation coefficient for each signer: aᵢ = H_agg(L, Xᵢ) where L is the multiset of all public keys and H_agg is a hash function
3. The aggregate public key is: X̃ = Σ aᵢ · Xᵢ (weighted sum of individual keys)

The coefficients prevent rogue key attacks: without them, a malicious signer could claim their “public key” is constructed to cancel honest parties’ keys.

The aggregate key X̃ is the key published on-chain / used in the Taproot output. On-chain observers see a single standard public key — identical to a solo-key output.

---

Round 1 — Nonce Generation

Each signer i generates two random nonce pairs (rᵢ₁, Rᵢ₁) and (rᵢ₂, Rᵢ₂), where Rᵢⱼ = rᵢⱼ · G, and broadcasts (Rᵢ₁, Rᵢ₂) to all co-signers.

This is the only commitment/broadcast before seeing the message. There is no commitment hash (unlike MuSig1) — the nonces themselves are broadcast.

Why two nonces?

After receiving all nonces, each party computes a binding coefficient:

b = H_non(X̃, (R₁₁, R₁₂, ..., Rₙ₁, Rₙ₂), m)

where m is the message to be signed. Each party then forms their effective nonce:

Rᵢ = Rᵢ₁ + b · Rᵢ₂

and the aggregate nonce is:

R = Σ Rᵢ = R₁ + b · R₂

where R₁ = ΣRᵢ₁ and R₂ = ΣRᵢ₂.

The binding coefficient b binds the nonce combination to the message and the complete set of all nonces and the aggregate key. This makes Wagner’s attack computationally infeasible: an attacker would need to solve a system of discrete log equations simultaneously.

---

Round 2 — Partial Signatures

With the aggregate nonce R and the message m known, each signer computes their partial signature:

sᵢ = rᵢ₁ + b · rᵢ₂ + H_sig(R, X̃, m) · aᵢ · xᵢ

Each party broadcasts sᵢ. All parties verify each partial signature:

sᵢ · G = Rᵢ + H_sig(R, X̃, m) · aᵢ · Xᵢ

If any sᵢ is invalid, the protocol aborts and identifies the cheating party.

Aggregation:

s = Σ sᵢ

The final signature is the pair (R, s) — a standard 64-byte Schnorr signature that any Bitcoin node can verify against the aggregate public key X̃ using the standard Schnorr verification equation: s · G = R + H_sig(R, X̃, m) · X̃.

---

Security Properties

Property	MuSig1	MuSig2
Communication rounds	3	2
Concurrent session security	✅	✅
Security assumption	DL + ROM	DL + ROM + AOMDL
Rogue key attack resistance	✅	✅
Nonce pre-commitment required	✅	❌
Output on-chain	Single sig	Single sig

AOMDL (Algebraic One-More Discrete Log): MuSig2’s security proof relies on one additional assumption beyond standard DL — the Algebraic One-More Discrete Log assumption (a well-accepted interactive hardness assumption). This is a minor additional assumption compared to MuSig1’s pure DL proof, accepted by the cryptographic community as practically sound.

---

Nonce Security and Reuse Risks

Nonce reuse is catastrophic for Schnorr: If two different messages m and m’ are signed with the same nonce R, the private key is directly recoverable from the two signatures. This is not unique to MuSig2 — it applies to all Schnorr/ECDSA implementations — but multi-party protocols face additional complexity because nonces must be coordinated without the ability to abort and restart mid-protocol if a device reboots.

MuSig2 implementations must:

• Generate nonces from a cryptographically secure random source (CSPRNG)
• Never reuse nonces across sessions
• For hardware wallets: use stateful nonce commitment (store a nonce commitment in non-volatile memory before the first round)

The Bitcoin Secp256k1 library (libsecp256k1) includes a hardened MuSig2 implementation with nonce generation designed to resist reuse even under power interruption.

---

Applications in Bitcoin

Taproot key-path spend: A 2-of-2 between Alice and Bob uses MuSig2 to produce a single Schnorr signature. On-chain, the spend is indistinguishable from a regular single-key spend. Lightning cooperative channel closes use this.

Threshold Taproot wallets: 3-of-5 threshold signing can be implemented as MuSig2 + a FROST (Flexible Round-Optimized Schnorr Threshold Signatures) integration. FROST extends MuSig2 to t-of-n thresholds; the final output is still a single Schnorr signature.

Lightning Network PTLCs: Point Time-Locked Contracts (PTLCs) are a proposed Lightning upgrade over HTLCs. PTLCs use adaptor signatures built on Schnorr/MuSig2 to link payment routing to discrete log problems, improving privacy and enabling novel payment patterns. MuSig2 is a prerequisite for PTLC deployment.

Bitkey and hardware wallet implementations: Square’s Bitkey (a 2-of-3 hardware wallet product) uses MuSig2 for its multi-party key scheme.

---

FROST — Threshold Extension

FROST (Flexible Round-Optimized Schnorr Threshold Signatures), introduced by Komlo and Goldberg (2020), extends the MuSig2 paradigm from N-of-N to t-of-N threshold signing. FROST uses Shamir’s Secret Sharing to distribute the signing key such that any t-of-N signers can cooperate to produce a valid single Schnorr signature.

FROST adopts MuSig2’s two-round nonce approach and achieves similar efficiency. It is being standardized in IETF RFC 9591 and is being adopted for Bitcoin federated custody schemes (Fedimint) and Lightning channel factories.

---

Reality Check

MuSig2 is cryptographically sound and well-peer-reviewed. It was specifically designed to be practical for Bitcoin’s deployment context. The main operational challenges are:

• Hardware wallet coordination complexity: Round 1 nonce exchange typically requires online communication between devices; hardware-only offline signers need careful state management to avoid nonce reuse
• Abort handling: If a co-signer goes offline between Round 1 and Round 2, the session must be aborted and restarted; a malicious aborter can force multiple restarts to extract information (though MuSig2 is designed to limit this)
• Adoption lag: Most Bitcoin wallets still use ECDSA multisig (OP_CHECKMULTISIG) rather than MuSig2 Taproot key-path spends, so privacy benefits are not yet widespread

---

Legacy

MuSig2 is the cryptographic standard for Schnorr multi-signatures in Bitcoin and is specified in BIP 327 (authored by Nick, Ruffing, Seurin, and Wuille, finalized 2023). BIP 327 makes MuSig2 the official Bitcoin standard for interactive Schnorr threshold signing. It is implemented in Bitcoin Core’s libsecp256k1 and is a dependency for Taproot lightning adoption and PTLC rollout.

---

Related Terms

• Schnorr Signatures
• Multi-Signature (Multisig)
• Taproot Whitepaper
• Lightning Network
• Zero-Knowledge Proof
• Threshold Signature

---

Research

• Nick, J., Ruffing, T., & Seurin, Y. (2021). MuSig2: Simple Two-Round Schnorr Multi-Signatures. CRYPTO 2021, LNCS 12825, pp. 189–221. https://eprint.iacr.org/2020/1261

— Primary paper; defines the MuSig2 two-round protocol, nonce binding mechanism, and security proof under DL + AOMDL in the random oracle model.

• Nick, J., Ruffing, T., Seurin, Y., & Wuille, P. (2023). BIP 327: MuSig2 for BIP340-compatible Multi-Signatures. Bitcoin Improvement Proposals. https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki

— The Bitcoin specification implementing MuSig2 as a standard; includes serialization formats, test vectors, and security guidance for nonce handling.

• Komlo, C., & Goldberg, I. (2021). FROST: Flexible Round-Optimized Schnorr Threshold Signatures. SAC 2020, LNCS 12804, pp. 34–65. https://eprint.iacr.org/2020/852

— Extends MuSig2’s approach to t-of-N threshold signing; being standardized as IETF RFC 9591; the threshold extension of MuSig2 for Bitcoin custody applications.