MuSig2: Simple Two-Round Schnorr Multi-Signatures

The five-minute read

One action, walked through

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

The argument, unpacked

What has to be true

• All n signers are available and follow the rounds.
• Nonce material is not reused across a malformed implementation. The proof does not supervise the code.
• Key aggregation includes the rogue-key countermeasure the paper specifies.
• The verifier uses Schnorr verification and the aggregated key. A different signature scheme is a different protocol.

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.

What to check before you use the idea

• Is every signer required?
• What happens if one device is lost?
• Are concurrent sessions part of the implementation's claim?
• Does the output reveal the number of signers? It should not.

Terms

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.

The problem the paper 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 a venture studio 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.