Chapter 29

Taproot Architecture

Schnorr, MAST, and Bitcoin's Privacy Upgrade

Taproot, activated in November 2021, composes three primitives—Schnorr signatures, Merkleized Alternative Script Trees (MAST), and cryptographic key tweaking—so that complex spending conditions are indistinguishable from simple payments, improving both privacy and efficiency. Within this volume, Taproot is the second soft-fork case study: a technically uncontested change whose activation mechanism was nonetheless disputed (the LOT debate, Section 33.7.2), demonstrating that Chapter 33's governance questions arise even when no one objects to the change itself. This chapter dissects Taproot's architecture, from BIP-340 Schnorr signatures through BIP-341 output construction to BIP-342 Tapscript execution.

29.1 Schnorr Signatures (BIP-340)

Taproot's signature scheme is the BIP-340 Schnorr scheme constructed and analyzed in Chapter 8; this section recalls it rather than re-deriving it. A signature on message m under private key d (public key P = d·G) is the 64-byte pair (x(R), s), where R = k·G for a nonce k, e = HBIP340/challenge(x(R) || x(P) || m) is the challenge, and s = k + e·d (mod n); verification checks s·G = R + e·P. The complete signing and verification procedures, including deterministic nonce generation, are Algorithms 8.1 and 8.2, and correctness is Theorem 8.1. The property everything in this chapter builds on is linearity (Theorem 8.2): partial signatures computed against a shared challenge sum to a valid signature under the summed public key, which is what makes key aggregation (Section 29.5) and adaptor signatures (Section 29.6) possible.

ECDSA • 72-byte signatures (DER) • Non-linear equation • No native batch verify • Complex key aggregation • Adaptor signatures: complex (non-linear) Schnorr (BIP-340) • 64-byte signatures • Linear: s·G = R + e·P • Efficient batch verify • Simple MuSig • Adaptor signatures: native Upgrade
Figure 29.1: ECDSA vs Schnorr signature comparison.

29.1.1 X-Only Keys, Even Y, and Tagged Hashes

Three BIP-340 conventions from Chapter 8 do real work in Taproot and are worth restating:

Remark 29.1 (X-Only Savings)

X-only keys save 1 byte per public key. For a Taproot output:

  • scriptPubKey: OP_1 <32 bytes> = 34 bytes
  • vs P2WPKH: OP_0 <20 bytes> = 22 bytes (but less flexible)

29.1.2 Batch Verification

Linearity also gives batch verification (Theorem 8.3): n signatures can be checked at once with a single random linear combination, (Σ ai·si)·G = Σ ai·Ri + Σ ai·ei·Pi for random weights ai, at the cost of one multi-scalar multiplication instead of n full verifications. BIP-340 was designed so that all of a block's signatures are batchable; ECDSA's verification equation, which is non-linear in s, admits no analogous check.

Remark 29.2 (Batch Verification Speedup)

Batch verification is approximately 2–3× faster than individual verification for typical block sizes. It would reduce worst-case block validation cost if deployed; as of mid-2026, Bitcoin Core validates signatures individually.

29.2 Key Tweaking and Taproot Outputs

Taproot's central mechanism is key tweaking: encoding spending conditions into the public key itself.

Definition 29.1 (Tweak)

A tweaked public key Q is computed from internal key P and tweak t:

Q = P + t·G

The corresponding tweaked private key (if P = d·G):

q = d + t (mod n)

Definition 29.2 (Taproot Tweak)

For Taproot, the tweak encodes the script tree:

t = HTapTweak(P || script_root)

If no scripts: t = HTapTweak(P)

Internal Key P Script Tree (optional) t = H(P || root) TapTweak Output Key Q = P + t·G OP_1 <Q>
Figure 29.2: Taproot key tweaking combines internal key and script tree into output key.

Proposition 29.1 (Taproot Spending Paths)

Per BIP-341, a Taproot output (OP_1 <Q>) can be spent in exactly two ways:

  1. Key path: Provide signature for Q (single 64-byte witness)
  2. Script path: Reveal script, provide Merkle proof, satisfy script

29.3 Script Trees (MAST)

Taproot implements Merkleized Alternative Script Trees, allowing multiple spending conditions with compact proofs.

Definition 29.3 (TapTree)

A TapTree is a Merkle tree of scripts:

  • Leaves: HTapLeaf(leaf_version || script)
  • Branches: HTapBranch(left || right) where left ≤ right lexicographically
  • Root: becomes part of the tweak
root H₁ H₂ Script A 2-of-3 multisig Script B Timelock + key Script C Recovery key Script D Hashlock To spend via Script C: Reveal C, prove with H(D) and H₁
Figure 29.3: TapTree with four scripts; spending Script C requires proving inclusion.

Definition 29.4 (Control Block)

To spend via script path, the witness includes a control block: 

control_block = leaf_version | parity_bit || internal_pubkey || merkle_path

where:
  leaf_version: 0xc0 (Tapscript v0)
  parity_bit:   output key Y parity (0 or 1)
  merkle_path:  sibling hashes for Merkle proof

Theorem 29.1 (MAST Privacy)

When spending via script path:

  • Only the executed script is revealed
  • Other scripts remain hidden (only hashes in proof)
  • The exact number of alternative scripts is hidden, though the Merkle path length reveals the revealed leaf's depth (a lower bound on tree size)

When spending via key path:

  • No scripts are revealed
  • Indistinguishable from simple single-key spend
  • Observer cannot tell if scripts even exist

Example 29.1 (Lightning Channel Close)

A Lightning channel with Taproot might have:

  • Key path: Aggregated key of both parties (cooperative close)
  • Script A: Alice after timelock (force close by Alice)
  • Script B: Bob after timelock (force close by Bob)

Cooperative closes (the common case in published channel statistics) look like single-sig payments on-chain.

29.4 Tapscript (BIP-342)

Tapscript is the script system for Taproot script path spends, with significant improvements over legacy Script.

Definition 29.5 (Tapscript Changes)

Tapscript modifies Script semantics:

  • OP_CHECKSIG(VERIFY): Uses Schnorr instead of ECDSA
  • OP_CHECKMULTISIG(VERIFY): Disabled (use CHECKSIGADD)
  • OP_CHECKSIGADD: New opcode for efficient multisig
  • Signature validation: Empty sig = OP_FALSE (no exception)
  • OP_SUCCESSx: Reserved for future upgrades

Definition 29.6 (OP_CHECKSIGADD)

OP_CHECKSIGADD enables efficient threshold signatures: 

Stack before (top → bottom): [pubkey] [n] [signature]
Operation:    valid signature        → push n + 1
              empty signature        → push n
              invalid (non-empty)    → script fails immediately

2-of-3 Tapscript (non-signers provide an empty signature):
  <sig_C> <sig_B> <sig_A>
  <pk_A> OP_CHECKSIG
  <pk_B> OP_CHECKSIGADD
  <pk_C> OP_CHECKSIGADD
  2 OP_NUMEQUAL

Remark 29.3 (Tapscript Multisig Efficiency)

CHECKSIGADD is more efficient than OP_CHECKMULTISIG:

Scheme k-of-n Script Size Witness Size
OP_CHECKMULTISIG O(n) pubkeys k sigs + dummy
CHECKSIGADD O(n) pubkeys n sigs (empty for non-signers)
MuSig + key path 0 (in tweak) 1 aggregated sig

Remark 29.4 (OP_SUCCESS for Upgrades)

OP_SUCCESSx opcodes (87 of them) make scripts immediately succeed. Future soft forks can redefine them to have new meaning:

  • Old nodes: script succeeds (anyone can spend)
  • New nodes: interpret new semantics
  • Same soft fork pattern as SegWit

29.5 Key Aggregation: MuSig2

Schnorr's linearity (Theorem 8.2) enables multi-party signatures in which the aggregate key and signature are indistinguishable from those of a single party. Chapter 8 introduced MuSig key aggregation and the rogue-key attack it defeats (Definitions 8.5 and 8.6); MuSig2 is the production two-round protocol.

Definition 29.7 (MuSig2 Key Aggregation)

Given n public keys P1, ..., Pn:

  1. Compute key aggregation coefficient: ai = Hagg(L || Pi)
  2. where L = H(P1 || ... || Pn)
  3. Aggregate key: P = Σ ai·Pi

Definition 29.8 (MuSig2 Signing)

Two-round signing protocol:

Round 1:

  1. Each signer generates two nonces: Ri,1, Ri,2
  2. Broadcast nonces

Round 2:

  1. Compute R = Σ Ri,1 + b·Σ Ri,2 where b = H(agg_nonces || agg_key || msg)
  2. Each signer computes partial: si = ki,1 + b·ki,2 + e·ai·di, where e = H(R || P || m) is the BIP-340 challenge recalled in Section 29.1
  3. Aggregate: s = Σ si
  4. Final signature: (R, s)
Alice PA, dA Bob PB, dB Carol PC, dC Aggregate P = Σ aiPi On-chain: bc1p... indistinguishable from a single-key output
Figure 29.4: MuSig2 aggregates n keys into one indistinguishable key.

Theorem 29.2 (MuSig2 Privacy; Nick, Ruffing, Seurin 2021)

A MuSig2 aggregate key and signature are computationally indistinguishable from a single-party key and signature. An observer cannot determine:

  • How many parties participated
  • Which parties signed
  • The threshold (if any)

29.6 Adaptor Signatures

Schnorr enables a powerful primitive for atomic protocols: adaptor signatures.

Definition 29.9 (Adaptor Signature)

An adaptor signature σ' is a "partial" signature that becomes valid when combined with a secret scalar t:

  • Adaptor point: T = t·G (public)
  • Adaptor signature: σ' = (R + T, s')
  • When t is revealed: σ = (R + T, s' + t) is valid

Theorem 29.3 (Adaptor Atomicity)

Adaptor signatures enable atomic swaps without hash preimages:

  1. Alice gives Bob adaptor σ' (valid when combined with secret t)
  2. Bob broadcasts transaction with σ = (R + T, s' + t)
  3. Alice learns t from the broadcast signature: t = s − s'
  4. Alice uses t to complete her side of the swap

Given timeout branches that enable refunds after a deadline, either both transactions complete or neither does: neither party can complete their side while denying the other the secret.

Remark 29.5 (Adaptor vs HTLC)

Adaptor signatures vs hash time-locked contracts:

Property HTLC Adaptor
On-chain footprint Script visible Just a signature
Linkability Same hash links txs No linkable data
Script complexity Moderate None (key path)

29.7 Taproot Adoption and Use Cases

Example 29.2 (Adoption Metrics)

Date P2TR Outputs % Primary Drivers
Nov 2021 <1% Activation, testing
2022 ~1-2% Early adopters
Early 2023 ~3-5% Ordinals/Inscriptions
Late 2023 ~15-30% Wallet adoption
2024 ~30-40% Broad adoption

Remark 29.6 (Taproot Use Cases)

Taproot enables or improves:

  • Lightning: Cooperative closes are indistinguishable
  • Multisig: MuSig makes n-of-n look like 1-of-1
  • DLCs: Discreet log contracts with privacy
  • Vaults: Complex custody with fallback options
  • Inscriptions: Data embedding via witness
  • Atomic Swaps: Adaptor signature swaps

Exercises

Exercise 29.1

Prove that Schnorr batch verification is sound: if the batch check passes but one signature is invalid, derive a contradiction (with high probability over random ai).

Exercise 29.2

Construct a TapTree for a 2-of-3 multisig with the following policy: Any 2 of {Alice, Bob, Carol} can spend immediately, OR Carol alone can spend after 1 year. Optimize tree depth for the expected common case.

Exercise 29.3

Explain why MuSig requires two rounds (or pre-committed nonces). What attack does the original one-round MuSig1 suffer from?

Exercise 29.4

Design an adaptor-signature-based atomic swap between Bitcoin (Taproot) and a hypothetical chain with Schnorr support. Write out the protocol steps.

Exercise 29.5

Calculate the vbytes savings of a 3-of-5 multisig using MuSig + key path vs legacy P2SH multisig vs Tapscript with CHECKSIGADD.