Schnorr vs MuSig2 (BIP 340 vs BIP 327)
BIP 340 defines Schnorr signatures, the 64-byte signature scheme that Taproot made part of Bitcoin's consensus rules; BIP 327 defines MuSig2, a protocol that lets several people combine their public keys into one and jointly produce a single BIP 340 signature. MuSig2 needed no consensus change of its own: its result is an ordinary Schnorr signature that nodes verify like any other.
Updated · 3 min read
At a glance
| BIP 340 | BIP 327 | |
|---|---|---|
| Title | Schnorr Signatures for secp256k1 | MuSig2 for BIP340-compatible Multi-Signatures |
| Status | Deployed | Deployed |
| Type | Specification | Informational |
| Assigned | 2020-01-19 | 2022-03-22 |
| Authors | Pieter Wuille, Jonas Nick, Tim Ruffing | Jonas Nick, Tim Ruffing, Elliott Jin |
| In plain English | Defines a standard for Schnorr signatures, a simpler and more flexible signing method than the ECDSA scheme Bitcoin originally used, on the same elliptic curve. Schnorr signatures are compact (64 bytes) and allow several signers to combine their keys and signatures into one, enabling cheaper and more private multi-party transactions. | Standardizes MuSig2, a scheme that lets several people jointly create a single signature that looks like an ordinary one-person Taproot signature. This makes shared-control wallets cheaper and more private, since outsiders cannot tell a multi-party spend from a single-owner one. |
What BIP 340 (Schnorr) defines
BIP 340, by Pieter Wuille, Jonas Nick and Tim Ruffing, standardizes Schnorr signatures over secp256k1, the same curve Bitcoin already used for ECDSA. Public keys are 32 bytes ("x-only", with an implied even Y coordinate) and signatures are a fixed 64 bytes, compared with 33-byte compressed keys and DER-encoded ECDSA signatures of up to 72 bytes. The scheme is provably secure under standard assumptions, non-malleable, supports batch verification, and uses tagged hashes such as BIP0340/challenge.
Its most important property for multi-party use is linearity: several parties can produce one signature that is valid for the sum of their public keys. BIP 340 became consensus-enforced through Taproot, together with BIP 341 and BIP 342, at block 709,632 in November 2021.
What BIP 327 (MuSig2) defines
BIP 327, by Jonas Nick, Tim Ruffing and Elliott Jin, standardizes MuSig2, an n-of-n multisignature scheme built on that linearity:
- Key aggregation: the signers' 33-byte public keys go into KeyAgg, which outputs one 32-byte x-only aggregate key without any interaction. Keys can be sorted first so that their order doesn't matter.
- Round one, nonces: each signer generates a secret and a public nonce (two curve points) and shares the public part. This round can happen before the message is known.
- Round two, partial signatures: each signer produces a partial signature, and anyone can combine them into a final 64-byte signature that passes BIP 340 verification for the aggregate key.
BIP 327 also supports tweaking, so an aggregate key can serve as a BIP 32 parent key or as a Taproot internal key with hidden script paths, and it can identify a signer who sends an invalid partial signature.
Schnorr vs MuSig2 compared
| Schnorr (BIP 340) | MuSig2 (BIP 327) | |
|---|---|---|
| What it is | A signature scheme | A multi-party signing protocol |
| Consensus change? | Yes, activated with Taproot | No; the output is a BIP 340 signature |
| Signers | One | n-of-n: every key holder must sign |
| Interaction | None | Two communication rounds |
| Input keys | 32-byte x-only keys | 33-byte compressed keys |
| Result on-chain | One 32-byte key, one 64-byte signature | The same: one aggregate key, one 64-byte signature |
| Nonces | Derived from the key, message and optional randomness | Must be random; reusing a secret nonce leaks the key |
| Security assumption | Discrete logarithm, in the random oracle model | Algebraic one-more discrete logarithm (AOMDL) |
| Related BIPs | 341, 342 | BIP 328 derivation, BIP 373 PSBT fields, BIP 390 musig() descriptor |
How MuSig2 relates to Schnorr
MuSig2 is an application of BIP 340, not an alternative to it. BIP 340 chose key-prefixed Schnorr signatures partly because key prefixing "seems to be a requirement for proving multiparty signing protocols (such as MuSig, MuSig2, and FROST) secure". BIP 340 also warns that its default signing method is unsafe for multisignatures, which is why MuSig2 defines its own nonce generation. On-chain, a MuSig2 key-path spend is indistinguishable from a single-signer Taproot spend.
Which should you use?
- One key: plain BIP 340 signing, as in a BIP 86 wallet.
- Everyone must sign (n-of-n): MuSig2 gives the smallest and most private result, one key and one signature, and consensus rules put no limit on the number of signers. The costs are two rounds of interaction and careful handling of nonces and signing state.
- k-of-n, such as 2-of-3: MuSig2 alone can't do this. Options in tapscript include a script using
OP_CHECKSIGADD(BIP 342), which reveals the keys involved, or a Taproot tree with one MuSig2 aggregate key for each allowed group of signers. Threshold schemes such as FROST exist but are outside BIP 327.
The multisig guide compares these approaches, and the Taproot guide explains key-path and script-path spending.
Frequently asked questions
Is MuSig2 a soft fork?
No. MuSig2 (BIP 327) is a protocol the signers run among themselves. Its output is a standard BIP 340 Schnorr signature for an aggregate public key, which nodes verify exactly like a single-signer Taproot spend. It relied only on Taproot, which made BIP 340 signatures valid in November 2021; no further consensus change was needed.
Can MuSig2 do 2-of-3 multisig?
Not directly: MuSig2 is n-of-n, so every key in the aggregate must sign. For 2-of-3, you can place a MuSig2 key for each pair of signers in a Taproot tree (one pair can use the key path), or use a tapscript with OP_CHECKSIGADD. Threshold signature schemes such as FROST are separate protocols not covered by BIP 327.
Can you tell a MuSig2 signature from a normal Schnorr signature?
No. The aggregate key is a normal 32-byte x-only key and the final signature is a normal 64-byte BIP 340 signature, so an observer sees what looks like a single-signer Taproot key-path spend. BIP 327 lists this privacy, together with a smaller footprint than OP_CHECKSIGADD scripts, among its main motivations.
Why must MuSig2 nonces never be reused?
If a signer runs the signing step twice with the same secret nonce, the two partial signatures reveal their secret key. BIP 327 therefore requires nonces from a high-quality random number generator and suggests overwriting the secret nonce once it is used. Unlike single-signer BIP 340 signing, MuSig2 nonces must not be derived deterministically from the session data.
How big is a Schnorr signature?
A BIP 340 Schnorr signature is always 64 bytes, and its public key is 32 bytes. In a Taproot transaction a 65th byte is added only when a sighash type other than the default is used. By comparison, Bitcoin's ECDSA signatures are DER-encoded and take up to 72 bytes, with 33-byte compressed public keys.