Skip to content
Blockchain LabBlockchain LabTHE VENTURE STUDIO

LibraryPrivacy2020Design paperCorpus record

MuSig2: Simple Two-Round Schnorr Multi-Signatures

MuSig2. Jonas Nick, Tim Ruffing and Yannick Seurin.

n signers, all of them, produce one Schnorr signature that verifies under one aggregated key. Two rounds, and concurrent sessions are in the security claim. This is n-of-n, not a threshold. It is the multi-signature Bitcoin-style schemes reached for.

MuSig2 lets n signers, all of them, produce one Schnorr signature under one aggregated key, in two rounds, with concurrent sessions allowed in the security claim. It is not a threshold scheme. One missing signer means no signature. The chain sees a single key.
Evidence
Primary paper
Re-measured
No
Assumptions
4
Records linked
8

Code

Source, repository, and what is actually hosted

  • ePrint 2020/1261https://eprint.iacr.org/2020/1261
  • The source URL is not a GitHub repository. No code remote is invented.
  • Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
  • Add to a reading list

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

  1. Claim 01 · Paper model

    n-of-n

    Every signer participates. If the product needs a subset, the paper to read is FROST, not this one.

  2. Claim 02 · Paper model

    Concurrent sessions were the bug

    Earlier two-round schemes in this setting broke when a signer ran two sessions at once. MuSig2's claim is that this class of attack is covered. Sequential-only safety is the weaker property it is trying to leave behind.

  3. Claim 03 · Paper model

    Ordinary Schnorr out

    The combined signature verifies like a single-signer Schnorr signature. Bitcoin script does not grow with n.

  4. Claim 04 · Paper model

    Aggregation is before signing

    Public keys are combined into the key the chain will know. A rogue-key attack is what the aggregation rule has to prevent. Skipping the rule recreates the attack.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

  1. 01 n-of-n

    Observation

    What the study says

    Every signer participates. If the product needs a subset, the paper to read is FROST, not this one.

    Model

    What has to hold

    Key aggregation includes the rogue-key countermeasure the paper specifies.

    Falsifier

    What would retire it

    Is every signer required?

  2. 02 Concurrent sessions were the bug

    Observation

    What the study says

    Earlier two-round schemes in this setting broke when a signer ran two sessions at once. MuSig2's claim is that this class of attack is covered. Sequential-only safety is the weaker property it is trying to leave behind.

    Model

    What has to hold

    Nonce material is not reused across a malformed implementation. The proof does not supervise the code.

    Falsifier

    What would retire it

    Are concurrent sessions part of the implementation's claim?

  3. 03 Ordinary Schnorr out

    Observation

    What the study says

    The combined signature verifies like a single-signer Schnorr signature. Bitcoin script does not grow with n.

    Model

    What has to hold

    The verifier uses Schnorr verification and the aggregated key. A different signature scheme is a different protocol.

    Falsifier

    What would retire it

    Is every signer required?

  4. 04 Aggregation is before signing

    Observation

    What the study says

    Public keys are combined into the key the chain will know. A rogue-key attack is what the aggregation rule has to prevent. Skipping the rule recreates the attack.

    Model

    What has to hold

    Key aggregation includes the rogue-key countermeasure the paper specifies.

    Falsifier

    What would retire it

    Does the output reveal the number of signers? It should not.

03 Sequence

One action, as an operating tape

  1. 01Signers exchange keys and compute the aggregated public key.
  2. 02They exchange nonce commitments for this message, and they may have more than one session open.
  3. 03They exchange partial signatures and add them.
  4. 04The result is published as a single signature.
  5. 05A signer who does not complete a round stalls this signature. There is no alternate subset.

04 Load-bearing

The argument, and where a pitch drops it

  1. Concurrency is the result

    The cut

    A summary that says 'two-round multi-signature' and omits concurrent sessions has omitted the reason the paper exists. Three-round MuSig already existed.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    n-of-n means one missing signer stalls the signature. There is no built-in recovery.

  2. Indistinguishability cuts both ways

    The cut

    A MuSig2 output does not reveal that several parties signed. That helps a channel or a joint wallet look ordinary. It also means the chain is not a roster of who approved the payment.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    Aggregation hides which device signed. It does not hide the amount or the fact of the payment.

05 Register

What has to be true

  • Data · Not re-measured

    All n signers are available and follow the rounds.

  • Cryptography · Not re-measured

    Nonce material is not reused across a malformed implementation. The proof does not supervise the code.

  • Cryptography · Not re-measured

    Key aggregation includes the rogue-key countermeasure the paper specifies.

  • Cryptography · Not re-measured

    The verifier uses Schnorr verification and the aggregated key. A different signature scheme is a different protocol.

06 Divergence

What happened after the paper

MuSig2 is the multi-signature used in discussions of Taproot wallets and Lightning. The deployment standard, where there is one, should be cited next to the paper. The paper does not become a threshold custody design by wishing.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

  5. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

The problem it names

Earlier two-round multi-signatures in the pure discrete-log setting broke when a signer opened several sessions at once. The safe alternatives were three rounds or a ban on concurrency. MuSig2 wants two rounds without that ban.

What the design proposes

  • Keys aggregate into one public key, so the chain sees a single signer.
  • A first round exchanges nonces. A second round exchanges partial signatures.
  • The combined signature is an ordinary Schnorr signature.

How the mechanism is specified

  • All n parties must participate. There is no t-of-n in this paper. That is FROST's job.
  • The security argument covers concurrent sessions, which is the specific hole the authors are closing.
  • Nonce reuse and a missing nonce commitment are still fatal in an implementation. The paper does not make careless code safe.

What this page does not treat as proven

  • Aggregation hides which device signed. It does not hide the amount or the fact of the payment.
  • n-of-n means one missing signer stalls the signature. There is no built-in recovery.
  • A later standard can add details. Citing the 2020 paper does not certify a library.

Why the desk still reads it

Do not let a pitch say threshold when it means MuSig2. Everyone must sign. Then ask what happens when one device is lost, because the paper's answer is: the signature does not exist.

09 Lexicon

Terms, opened into the record

Key aggregation
Combining signer public keys into one key that the signature will verify under.
Partial signature
One signer's contribution in the second round, useless on its own and combinable into a Schnorr signature.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.