MuSig2: Multi-Signatures for Bitcoin
WHAT IS MUSIG2?
BIP-327 specifies a multi-signature protocol built on BIP-340 Schnorr signatures. It lets n parties collaboratively produce a single valid Schnorr signature for a single aggregate public key — indistinguishable from a regular single-signer signature on chain.
THE 2-ROUND PROTOCOL
Round 1: Each signer generates nonces and shares commitments.
Round 2: Each signer produces a partial signature using their secret key, the aggregate nonce, and the message. Partial signatures are combined into one final Schnorr signature.
Round 2: Each signer produces a partial signature using their secret key, the aggregate nonce, and the message. Partial signatures are combined into one final Schnorr signature.
KEY AGGREGATION
Public keys are aggregated non-interactively — anyone can compute the aggregate key from the set of individual keys. No communication needed.
The aggregate key is a standard 32-byte x-only public key, indistinguishable from a solo key.
The aggregate key is a standard 32-byte x-only public key, indistinguishable from a solo key.
WHY IT MATTERS
MuSig2 gives Bitcoin privacy (observers can't tell how many signers were involved), efficiency (one signature regardless of signer count), and fee savings (smaller on-chain footprint than traditional multisig). It is rapidly becoming the standard for cooperative signing in Taproot-based wallets and Lightning.
The Nesting Problem
THE ASSUMPTION EVERYONE MADE
Since MuSig2 aggregate keys look like ordinary public keys, people naturally proposed using a MuSig2-aggregated key as a participant in another MuSig2 session. A 3-of-3 where one "participant" is itself a 2-of-2 MuSig2 group, for example. Many protocols were designed around this assumption.
THE GAP: NO SECURITY PROOF
Despite widespread use in protocol designs, no formal security argument had ever been presented for nesting MuSig2. The original MuSig2 paper proved security when all participant keys are "honestly generated" single keys — but an aggregate MuSig2 key has a fundamentally different internal structure. Subtle attacks on nonce handling or key cancellation could potentially break the scheme in ways the original proof didn't cover.
WHAT COULD GO WRONG?
Multi-signature schemes have a history of subtle attacks. Rogue key attacks (a malicious participant choosing their key to cancel others), nonce manipulation (reusing or biasing nonces to extract secret keys), and Wagner's algorithm on Schnorr blind signatures all demonstrate that "it seems like it should work" is not a substitute for a formal security reduction.
NestedMuSig2: The Proof
THE PAPER
Nadav Kohen (Chaincode Labs) published the first formal security proof for nested MuSig2 as ePrint 2026/223. The scheme is called NestedMuSig2 — a recursive variant enabling a tree of nested cosigners to privately generate aggregate Schnorr signatures.
PROPERTY 1
Recursive Trees
Nesting can be applied to arbitrary depth. Any leaf signer can itself be a MuSig2 group, forming a tree of cosigners.
PROPERTY 2
Privacy Preserved
Nested signers cannot distinguish between cosigners using further nesting and those that are not. The tree structure is invisible.
PROPERTY 3
Full Compatibility
NestedMuSig2 is compatible with all existing MuSig2 protocols. No changes required to verifiers or on-chain logic.
PROPERTY 4
Non-Interactive KeyAgg
Public key aggregation remains non-interactive. The efficiency and simplicity of MuSig2 key aggregation is fully preserved.
SECURITY REDUCTION TO AOMDL
The proof reduces the security of NestedMuSig2 to the Algebraic One-More Discrete Logarithm (AOMDL) assumption in the random oracle model — the same assumption underlying the original MuSig2 proof. This means NestedMuSig2 is exactly as hard to break as standard MuSig2, which is itself as hard as computing discrete logarithms on the secp256k1 curve.
What This Enables for Bitcoin
LIGHTNING NETWORK
Channel opens with nested cosigners. A Lightning channel between two "participants" where one side is actually a federated group of custodians, a hardware wallet quorum, or a multisig treasury. The counterparty doesn't need to know or care — it looks like a normal 2-of-2 MuSig2 channel.
FEDERATED CUSTODY
Custodians can internally use MuSig2 for their own key management (e.g. a 3-of-5 internal quorum) while appearing as a single signer to external protocols. Nested layers of governance become cryptographically invisible.
COMPLEX POLICIES
Taproot key-path spends can encode arbitrarily complex signing trees without any on-chain footprint. A corporate treasury with departments, sub-teams, and individual signers — all collapsing into one 32-byte key.
BACKWARD COMPATIBLE
Because NestedMuSig2 produces standard BIP-340 Schnorr signatures for standard aggregate public keys, it requires no consensus changes, no new opcodes, and no changes to existing MuSig2 implementations. Verifiers and the blockchain are completely unaware nesting occurred. Existing wallets, Lightning nodes, and protocols that already support MuSig2 can adopt nesting without any coordination.
PAPER & AUTHOR
Nadav Kohen, Chaincode Labs. "NestedMuSig2" — ePrint 2026/223.
Based on BIP-327 (MuSig2) by Jonas Nick, Tim Ruffing, and Elliott Jin, and BIP-340 (Schnorr) by Pieter Wuille, Jonas Nick, and Tim Ruffing.
Based on BIP-327 (MuSig2) by Jonas Nick, Tim Ruffing, and Elliott Jin, and BIP-340 (Schnorr) by Pieter Wuille, Jonas Nick, and Tim Ruffing.