Home › Glossary › MuSig2

MuSig2

Also called: MuSig, MuSig 2, Schnorr multisig, key aggregation, aggregate signature, BIP327.

MuSig2 is a Schnorr multi-signature scheme (BIP 327): several signers share one aggregate key and produce one ordinary-looking signature.

MuSig2 lets several people control coins together while appearing on chain as a single key. The signers combine their public keys into one aggregate key, and to spend they cooperate on one Schnorr signature that is valid for it.

How it works

BIP 327, by Jonas Nick, Tim Ruffing and Elliott Jin, standardizes the scheme for BIP 340 keys and signatures:

  1. Key aggregation. The signers' keys are combined into one 32-byte aggregate key, with no interaction needed.
  2. Nonce round. Signers exchange public nonces. This can happen before the transaction is known.
  3. Partial signatures. Each signer sends a partial signature, and these combine into one 64-byte signature.

Signing takes two communication rounds; the earlier MuSig1 needed three. MuSig2 is n-of-n: every signer must take part. Threshold (t-of-n) setups need a different scheme or a Taproot script path.

Why it matters

A MuSig2 P2TR output looks the same as a single-signer one, and spending it takes one signature however many signers there are. That makes it cheaper and more private than script multisig with OP_CHECKSIGADD. The aggregate key can also be tweaked to add hidden Taproot script paths.

The catch is signing state. Nonces can't be generated deterministically, and BIP 327 warns that signing twice with the same secret nonce lets others extract the secret key, so implementations must handle sessions carefully.

BIP 328 defines how to build an xpub from an aggregate key for deriving fresh addresses, BIP 373 adds MuSig2 fields to PSBTs, and BIP 390 proposes a musig() output descriptor expression. Compare it with single-signer Schnorr in BIP 340 vs BIP 327.

BIPs that define MuSig2

  • BIP 327: MuSig2 for BIP340-compatible Multi-Signatures: Deployed. 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…
  • BIP 340: Schnorr Signatures for secp256k1: Deployed. 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…
  • BIP 341: Taproot: SegWit version 1 spending rules: Deployed. Taproot introduces a new kind of Bitcoin output that can be spent either with a single signature or by revealing just one of many possible alternative spending conditions, kept hidden in a tree…
  • BIP 328: Derivation Scheme for MuSig2 Aggregate Keys: Complete. Explains how to turn a MuSig2 combined public key into a standard extended public key, so wallets can generate many fresh addresses from it. This lets groups using MuSig2 multisig manage addresses…
  • BIP 373: MuSig2 PSBT Fields: Complete. Extends the Partially Signed Bitcoin Transaction (PSBT) format so it can carry the data needed for MuSig2, a method where several people jointly produce one ordinary-looking signature. This makes it…
  • BIP 390 (MuSig2 descriptors): musig() Descriptor Key Expression: Draft. Adds a 'musig()' expression to descriptors, which combines several people's public keys into a single shared key using the MuSig2 method. The resulting coins look like an ordinary single-key payment…

Related terms

  • Schnorr signatures: Schnorr signatures are the 64-byte digital signatures standardized in BIP 340 and used by Taproot. They are simpler and more flexible than ECDSA.
  • Multisig: Multisig (multi-signature) locks bitcoin so that M of N chosen keys must sign to spend it, for example any 2 of 3 keys kept in different places.
  • P2TR: P2TR (Pay to Taproot) is the SegWit version 1 output type from BIP 341: one 32-byte key with optional hidden scripts. Addresses start with bc1p.
  • PSBT: A PSBT (Partially Signed Bitcoin Transaction) is the standard format, from BIP 174, for passing a not-yet-signed transaction between wallets and signers.

Learn more

Guides