Taproot, Schnorr & MuSig2

Taproot (activated November 2021) is the most important upgrade since SegWit, and almost everyone who hasn’t built with it describes it wrong. Its real magic is a privacy property that sounds impossible at first: a complex multi-party smart contract and a simple single-person payment can be made indistinguishable on-chain. Getting there requires three ideas — Schnorr signatures, key aggregation, and MAST — that compose beautifully.

Foundation: Schnorr signatures (BIP 340)

Bitcoin originally used ECDSA. Taproot adds Schnorr signatures over the same curve (secp256k1). Schnorr is simpler, provably secure under cleaner assumptions, and — crucially — has one property ECDSA lacks: linearity.

ECDSA:    signatures don't add up nicely  →  no clean aggregation
Schnorr:  sig(key A) + sig(key B) behaves like sig(key A + B)  →  aggregation works

That linearity is the unlock for everything below. It means multiple keys and multiple signatures can be combined into one key and one signature that still verifies correctly.

The ”+” is schematic

sig(A) + sig(B) ≈ sig(A+B) captures the intuition, not the literal protocol. Safe key aggregation (MuSig2, below) does not naively add keys/signatures — it mixes in a per-key coefficient and aggregated nonces precisely to defeat the rogue-key attack a naive sum would enable. Read the ”+” as “combines cleanly,” not literal addition.

Key aggregation: MuSig2

With Schnorr’s linearity, a group of signers can compute a single aggregate public key from their individual keys, and later produce a single aggregate signature that satisfies it. MuSig2 is the modern, secure protocol for doing this (earlier naïve schemes were vulnerable to rogue-key attacks, where one participant cancels out others’ keys; MuSig2 defends against this).

Alice's key ┐
Bob's key   ├──MuSig2──►  ONE aggregate key  (looks like a single ordinary pubkey)
Carol's key ┘                    │
                                 ▼
        cooperative spend  ──►  ONE Schnorr signature

The consequence is profound. A 2-of-2 (or n-of-n) multisig, when all parties cooperate, produces a transaction that is byte-for-byte identical to a normal single-key payment. No one watching the chain can tell it was multisig at all.

Why this matters for Lightning

Every Lightning channel is a 2-of-2 multisig. Pre-Taproot, opening and cooperatively closing a channel was visible as a 2-of-2 — analysts could map the Lightning network on-chain. With Taproot + MuSig2, a cooperative channel open/close looks like any other ordinary payment. Privacy improves for everyone, because the “boring single payments” set now secretly contains channels, multisig vaults, and more.

MAST: hide the conditions you don’t use

Real contracts have multiple spending paths — “Alice can spend after a timelock, OR Bob and Carol together, OR a 3-of-5 emergency key set.” In legacy Script, every branch had to be revealed on-chain when you spent, even the ones you didn’t use, exposing your entire policy and wasting space.

MAST (Merkelized Alternative Script Trees) fixes this: arrange all the spending conditions as leaves of a Merkle tree, and commit only to the Merkle root. When you spend, you reveal only the one branch you’re using, plus a small Merkle proof that it was part of the committed tree.

                 Merkle root  ◄── this is all that's committed
                /          \
          hash(AB)        hash(CD)
          /     \          /     \
   [path A] [path B]  [path C] [path D]

   To spend via path C: reveal ONLY path C + a proof it's in the tree.
   Paths A, B, D are never disclosed.

You get smaller transactions and better privacy: the unused contract terms stay secret forever.

Putting it together: the Taproot output

A Taproot output (bc1p…, P2TR) commits to a single public key Q that secretly encodes both a key and a script tree:

Q  =  P  +  hash(P, merkle_root) · G
      │              │
   the "key path"   the "script path"
   (an aggregated   (a MAST of alternative
    cooperative     spending conditions)
    pubkey)

This gives two ways to spend, by design:

• Key path — if everyone cooperates, sign with the aggregated key P. The output looks like an ordinary single-sig payment; the script tree is never revealed. This is the common, happy case.
• Script path — if cooperation fails, reveal one branch of the MAST and satisfy it, proving it was committed in Q.

The headline result

The optimistic case is invisible. A 12-of-15 corporate treasury, a Lightning channel, a vault with a dozen escape hatches — as long as the participants cooperate, every one of them settles as a plain Taproot key-path spend that’s indistinguishable from buying a coffee. The complex machinery only becomes visible if and when someone is forced to use a fallback branch. Privacy by default; complexity only on dispute.

Why it’s also more efficient

• Schnorr signatures are fixed-size and aggregation means one signature instead of N for multisig — smaller transactions, lower fees.
• MAST means you pay for (and reveal) only the one branch you use, not the whole policy.
• Batch verification: many Schnorr signatures can be verified together faster than one-by-one.

Smaller, cheaper, and more private — a rare trifecta in protocol design, which is why Taproot is considered such an elegant upgrade.

By the numbers — what aggregation saves

The privacy win has a measurable efficiency twin. A Schnorr signature is a fixed 64 bytes, and a cooperative key-path Taproot spend reveals just that one signature against a single 32-byte key — regardless of how many people actually signed.

traditional 3-of-3 multisig:  3 sigs + 3 pubkeys + script   ≈ 300+ bytes revealed on-chain
MuSig2 3-of-3 (key path):     ONE 64-byte sig + ONE 32-byte key   ≈ 100 bytes, looks single-sig

The aggregate spend isn’t just smaller — it’s constant-size: a cooperative 2-of-2 and a 20-of-20 weigh the same on-chain and look identical. Fewer bytes (lower fees) and zero leakage about the signer set, both falling out of the one linearity trick.

The thread

How does this help untrusting strangers agree on one ledger? Taproot changes what the ledger reveals without changing what it enforces. Strangers still verify every rule, but the rules are now expressed so that honest cooperation leaks nothing about the contract behind it. It pushes Bitcoin toward a world where using a sophisticated trust-minimized contract costs no more privacy than a trivial payment — making the strongest setups the cheapest and most private to use, which is exactly the incentive you want.

The architect’s lens

Taproot is a designed trifecta — smaller, cheaper, more private — so ask what each part buys:

• Why does it exist? To make a complex multi-party contract and a simple single-key payment indistinguishable on-chain — Schnorr’s linearity lets many keys/signatures aggregate into one, and MAST hides the spending paths you don’t use.
• What problem does it solve? Pre-Taproot, every multisig and contract announced itself on-chain, leaking policy and wasting bytes. MuSig2 collapses an n-of-n into a single 64-byte signature against one key; MAST reveals only the branch you spend; the key/script-path output makes the cooperative case look like an ordinary payment.
• What are the trade-offs? MuSig2 isn’t naive addition — it must mix per-key coefficients and aggregated nonces to defeat the rogue-key attack, adding interactivity; and the privacy holds only in the cooperative case — a forced script-path spend still reveals a branch.
• When should I avoid it? Key aggregation needs signers to cooperate interactively, so it’s the wrong fit when you specifically want an on-chain-auditable multisig, or for legacy inputs that can’t use it — and a non-cooperative dispute leaks the contract anyway.
• What breaks if I remove it? Lightning channels and large treasuries stay publicly fingerprintable as multisig; transactions get bigger and costlier (3 sigs + 3 keys ≈ 300 B vs one constant-size ≈ 100 B); and the “boring single payments” anonymity set that protects everyone shrinks.

Check your understanding

1. What single mathematical property of Schnorr signatures (vs ECDSA) makes key and signature aggregation possible?
2. What problem does MuSig2 solve that a naïve “just add the keys” scheme does not?
3. Why can a cooperative 2-of-2 Taproot spend be indistinguishable from an ordinary single-key payment — and why does that help non-multisig users too?
4. What does MAST commit to on-chain, and what do you reveal when you actually spend?
5. Describe the two spend paths of a Taproot output and when each is used.

Show answers

1. Linearity: with Schnorr, sig(A) + sig(B) behaves like sig(A+B), so multiple keys and signatures combine cleanly into one key and one signature. ECDSA signatures don’t add up this way, so they can’t be aggregated.
2. The rogue-key attack: a naïve “just add the keys” scheme lets one participant craft a key that cancels out the others’ and seize control of the aggregate. MuSig2 defends against it by mixing in a per-key coefficient and aggregated nonces instead of naively summing.
3. When all parties cooperate, MuSig2 produces a single aggregate key and one Schnorr signature, so a 2-of-2 spend is byte-for-byte identical to a normal single-key payment — no observer can tell it was multisig. It helps non-multisig users too because the “boring single payments” anonymity set now secretly contains channels, multisig vaults, and more, so everyone’s ordinary payments become less linkable.
4. MAST commits only to the Merkle root of all the spending conditions (each a leaf). When you spend you reveal only the one branch you actually use, plus a small Merkle proof that it was committed in the tree — the unused conditions stay secret forever.
5. The key path: if everyone cooperates, sign with the aggregated key P; the output looks like an ordinary single-sig payment and the script tree is never revealed — the common, happy case. The script path: if cooperation fails, reveal one MAST branch and satisfy it, proving it was committed in Q — used only on dispute.