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.

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.

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.

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.