Taproot is a coordinated set of three Bitcoin Improvement Proposals — BIP 340 (Schnorr Signatures), BIP 341 (Taproot), and BIP 342 (Tapscript) — authored primarily by Pieter Wuille, Jonas Nick, Tim Ruffing, and Anthony Towns. The proposals were finalized in 2020 and activated on the Bitcoin mainnet at block 709,632 on November 12, 2021, through the Speedy Trial activation mechanism after 90%+ miner signaling within a difficulty period.

Taproot is Bitcoin’s most significant upgrade since the 2017 SegWit activation. It introduces three interlocking improvements:

1. Schnorr signatures — more efficient, aggregatable, and privacy-enhancing than ECDSA
2. MAST (Merkelized Alternative Script Tree) — spend conditions hidden until execution, enabling complex scripts with the on-chain footprint of a simple payment
3. Tapscript — updated Bitcoin scripting for Taproot spends with forward-upgrade provisions

> BIP 340 (Schnorr): github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

> BIP 341 (Taproot): github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

> BIP 342 (Tapscript): github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

---

Publication and Context

Pieter Wuille (Blockstream co-founder, author of Bitcoin’s libsecp256k1 library) had been working on Schnorr signatures and MAST ideas since at least 2017. A Schnorr signature BIP draft circulated in 2018. The three BIPs were formally composed in 2020 as a combined package, recognizing that Schnorr, Taproot, and Tapscript are interdependent: Schnorr enables key aggregation that Taproot relies on; MAST requires Tapscript’s new hashing; Tapscript only makes sense within Taproot spends.

The upgrade required no hard fork — it was implemented as a SegWit version 1 output type, backward-compatible with pre-Taproot nodes that see it as any-can-spend (but softfork rules prevent non-Taproot nodes from relaying invalid spends).

Activation used the Speedy Trial mechanism: miners signal support within 3-month windows; if 90% signal within a retarget period, the soft fork locks in. Speedy Trial reached the 90% threshold in June 2021, with activation at block 709,632 five months later.

---

BIP 340 — Schnorr Signatures

Schnorr signatures replace Bitcoin’s existing ECDSA (Elliptic Curve Digital Signature Algorithm) for Taproot inputs, offering three key properties ECDSA lacks:

Linear Homomorphism — Key Aggregation

• If Alice has key A and Bob has key B, they can cooperate to produce a single combined key A+B and a single signature that verifies under A+B without revealing A or B individually
• A multi-party multisig under Schnorr is indistinguishable on-chain from a single-key spend (when combined via MuSig2)
• This is the mechanism enabling Taproot key-path spends to represent arbitrarily complex cooperative agreements as a single public key

Batch Verification

Provable Security

32-Byte Keys

---

BIP 341 — Taproot and MAST

Taproot combines Schnorr aggregation with Merkelized Alternative Script Tree (MAST) to enable Bitcoin’s most powerful privacy and scripting upgrade.

The Core Idea

1. A key-path spend: a single aggregated public key P = Q + t·G where Q is the “internal key” (could be an n-of-n Schnorr multi-sig) and t is a hash commitment to the script tree
2. A script-path spend: a Merkle tree of alternative spending conditions (scripts)

Taproot output key P = Q + hash(Q, script_tree_root) · G

Key-path spend (cooperative case):

• If all parties agree, they produce a Schnorr signature under the aggregated key P
• The spend looks identical to a single-key P2WPKH spend — no scripts are revealed, no multisig structure is visible on-chain
• Maximum privacy: a 2-of-3 Lightning channel close, a DLC oracle settlement, and a regular payment are all indistinguishable

Script-path spend (uncooperative/fallback case):

• The spender reveals the specific script branch being used, the leaf’s hash, and the Merkle inclusion proof (sibling hashes up to the root)
• Only the executed script branch is revealed; all other branch conditions remain hidden forever
• A 7-condition timelock script might have 7 branches; using branch 3 reveals only branch 3

Privacy impact:

• Before Taproot, multisig outputs revealed the multisig structure to the world permanently
• With Taproot, cooperative closes reveal nothing about the underlying conditions
• This benefits Lightning Network (channel closes look like regular payments), DLCs, CoinJoins, and complex vaults

---

BIP 342 — Tapscript

Tapscript updates Bitcoin’s scripting language for use within Taproot script-path spends:

Key Changes

• Schnorr signature verification in scripts: All signature opcodes use Schnorr instead of ECDSA in Tapscript context
• OP_SUCCESS opcodes: A class of previously invalid opcodes that Tapscript treats as “success if reached” — allowing future soft forks to add new opcodes by redefining OP_SUCCESS codes without requiring a new Tapscript version
• Resource limits lifted: Tapscript removes the 201 opcode limit and 10,000 byte script limit that constrained Bitcoin script before

Forward Compatibility

---

Taproot Adoption

Taproot adoption has been gradual:

Year	% of outputs spending via Taproot
2022	~1–2%
2023	~10–15%
2024	~25–30%+ (boosted by Ordinals and BRC-20 activity)

Lightning Network wallet software (Phoenix, Zeus, LND) has adopted Taproot channels, improving Lightning privacy. Bitcoin Ordinals and BRC-20 tokens — which embed data in Tapscript witnesses — drove a significant increase in Taproot output creation in 2023–2024, even if unintentionally.

---

Reality Check

Taproot is a genuine and well-executed technical upgrade. Its privacy benefits are real but require ecosystem adoption to manifest: if only 30% of transactions use Taproot, clustering heuristics can still identify Taproot outputs as likely multisig or Lightning. Privacy improves as adoption increases.

Limitations:

• Key aggregation requires an interactive signing protocol (MuSig2); wallets must coordinate pre-nonce exchange round, which complicates hardware wallet and threshold signing implementations
• Taproot does not enable recursive covenants, merge mining, sidechains, or Layer 2 scaling by itself — these require separate proposals (OP_CTV, BIP-300, etc.)
• The privacy benefit only applies to cooperative closes; any dispute path revealing a script branch is still visible on-chain

---

Legacy

Taproot is widely considered Bitcoin’s most technically rigorous upgrade. The soft fork process was careful, inclusive, and well-reviewed — the BIPs spent years in public discussion before activation. Tapscript’s OP_SUCCESS mechanism is now the standard template for proposing future Bitcoin script extensions. Several follow-on proposals (OP_CHECKTEMPLATEVERIFY, OP_VAULT, MATT) rely on Taproot as a prerequisite.

---

Related Terms

• SegWit
• Bitcoin Script and Taproot
• Multi-Signature (Multisig)
• Lightning Network
• Bitcoin Ordinals
• MuSig2 Whitepaper
• Bitcoin Whitepaper

---

Research

• Wuille, P., Nick, J., & Ruffing, T. (2020). BIP 340: Schnorr Signatures for Secp256k1. Bitcoin Improvement Proposals. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

— Specifies 32-byte x-only Schnorr signatures for Bitcoin, including security proof, batch verification algorithm, and test vectors.

• Wuille, P., Nick, J., & Towns, A. (2020). BIP 341: Taproot: SegWit Version 1 Spending Rules. Bitcoin Improvement Proposals. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

— Specifies the Taproot output format, key-path and script-path spending rules, and MAST inclusion proof verification.

• Nick, J., Ruffing, T., & Seurin, Y. (2021). MuSig2: Simple Two-Round Schnorr Multi-Signatures. CRYPTO 2021, LNCS 12825, pp. 189–221. https://eprint.iacr.org/2020/1261

— The cryptographic foundation for Taproot key aggregation; defines the MuSig2 interactive signing protocol used in Taproot multi-party key-path spends.