Timechain Wiki

Taproot upgrade

17 min read

Taproot — activated as a soft fork on 14 November 2021 at block 709,632 — is the largest Bitcoin protocol upgrade since SegWit upgrade. It bundles three BIPs: BIP340 introduces Schnorr signatures (replacing ECDSA for v1 witness outputs), with linearity that enables key and signature aggregation across multi-party spends; BIP341 defines the Taproot output type — a script-tree commitment with cooperative key-path spending and fallback script-path spending — under which cooperative multisigs become indistinguishable from single-sig on-chain; BIP342 (Tapscript) defines a new script version with OP_CHECKSIGADD, OP_SUCCESSx upgrade hooks, and removed legacy size limits. Activation used the Speedy Trial BIP9 variant, a deliberate departure from the contested 2017 SegWit activation — three months of miner signaling with a single retarget cycle to lock in. Taproot is the contemporary foundation for advanced Lightning constructions, the Ark protocol family, and the Taproot-witness inscription pattern that produced the Ordinals consequence treated in The Ordinals, Inscriptions, and BIP-110 controversy.

Why this note matters

Taproot is the base-layer enabler that defines what current and near-future Bitcoin protocol development can build. Where SegWit upgrade made deployable Lightning possible by fixing transaction malleability and segregating witness data, Taproot extends the SegWit witness framework with a new signature primitive, a new output type, and a new script version — three orthogonal upgrades bundled into a single soft fork.

The load-bearing technical claim is signature linearity. Schnorr’s algebraic structure permits multiple signers to combine their keys and signatures off-chain into a single key and signature that verifies on-chain. The on-chain consequence is the cooperative-spend indistinguishability property: a 2-of-2 channel close, a 3-of-5 corporate-treasury cooperative spend, and a single-sig wallet spend all produce identical on-chain footprints when participants cooperate. This is a structural privacy and efficiency gain that no purely script-level upgrade could deliver.

Taproot is also the activation-mechanism precedent that contrasts with the contested 2017 SegWit deployment. The 2021 Speedy Trial mechanism compressed signaling into a single retargeting cycle with a clear fallback, and activation completed without acrimony. Subsequent contested upgrade conversations — OP_CAT and the covenants programmability debate, BIP-300 and the Drivechains debate — invoke Taproot’s activation as the post-Wars baseline.

What Taproot activated

Taproot bundles three BIPs activated together as a single soft fork on 14 November 2021 at block 709,632:

  • BIP340 — Schnorr Signatures for secp256k1 (Pieter Wuille, Jonas Nick, Tim Ruffing): defines the Schnorr signature scheme over secp256k1, the same elliptic curve Bitcoin already uses for ECDSA. Schnorr signatures are 64 bytes, deterministic by construction, provably secure under standard assumptions, and — critically — linear, which permits key and signature aggregation.
  • BIP341 — Taproot: SegWit version 1 spending rules (Pieter Wuille, Jonas Nick, Anthony Towns): defines the Pay-to-Taproot (P2TR) output type — a 32-byte tweaked public key that commits to both a cooperative-spend key path and an optional Merkelized script tree. P2TR addresses are encoded in bech32m (per BIP350) and begin with bc1p....
  • BIP342 — Validation of Taproot Scripts (Pieter Wuille, Jonas Nick, Anthony Towns): defines Tapscript — a new script version executed only when a P2TR output is spent via the script path. Tapscript reserves OP_SUCCESSx opcodes as forward-compatibility upgrade hooks, replaces OP_CHECKMULTISIG with OP_CHECKSIGADD, and removes several legacy script-size constraints.

Together these define a unified upgrade: Schnorr is the signature primitive Tapscript and the key-path spend use; the Taproot output is the structural container that holds both; Tapscript is the script version executed on script-path spends. The three pieces are designed to interlock.

Schnorr signatures (BIP340)

Schnorr signatures replace ECDSA for v1 witness spends. The signature is 64 bytes — about 10% smaller than a typical 72-byte ECDSA signature — and is deterministic, batch-verifiable, and free of the encoding-malleability quirks that complicated ECDSA in early Bitcoin.

The load-bearing property is linearity. Schnorr’s verification equation is linear in the signature and the public key, which means two participants holding private keys x1 and x2 with public keys P1 = x1·G and P2 = x2·G can construct an aggregate key P_agg = P1 + P2 and an aggregate signature that verifies under P_agg. The on-chain spend reveals only P_agg and the aggregated signature; no observer learns that two parties were involved.

In practice, naive key addition is insecure against rogue-key attacks — a malicious participant can choose its public key to cancel another participant’s contribution. The deployable construction is MuSig2 (Nick, Ruffing, Seurin, 2020), a two-round multi-party signing protocol that is secure under standard assumptions and produces aggregated signatures indistinguishable from single-signer Schnorr signatures. MuSig2 is what makes Schnorr’s cooperative-spend privacy property practical.

The cryptographic detail — the underlying secp256k1 group, the precise signing and verification equations, the security proofs, and the comparison to ECDSA — lives in Signature schemes in Bitcoin. This note treats Schnorr only as the BIP340 component of the Taproot upgrade.

MAST and the Taproot output (BIP341)

A Taproot output is a 32-byte tweaked public key — written as the SegWit v1 witness program — that commits simultaneously to two spending paths: a single Schnorr key (the key path) and an optional Merkle tree of alternative scripts (the script path).

The construction. The output key Q = P + t·G, where P is an internal Schnorr key controlled by the cooperative participants, t = H(P || merkle_root) is a deterministic tweak derived by hashing P together with the root of a Merkle tree of alternative scripts, and G is the secp256k1 generator. The tweak commits to the script tree without revealing it on-chain at output creation time.

Key-path spend. Participants cooperate to produce a single Schnorr signature for the tweaked key Q. The spend reveals only the signature and the tweaked public key. No script is revealed; no Merkle proof is provided; the output is indistinguishable from a single-signer spend. Cooperative participants always have an incentive to take this path because it is smaller, cheaper, and more private than the script-path alternative.

Script-path spend. When cooperation fails or a non-cooperative condition triggers, any participant can reveal one leaf of the script tree, the Merkle proof linking that leaf to the committed root, the internal key P, and a satisfying witness for the revealed script. Only the executed branch is revealed; unused branches remain hidden. This is the MAST (Merkelized Abstract Syntax Tree) property — script logic is committed to up front but only the spent branch is published.

The cooperative-spend indistinguishability property is the structural privacy gain. A 2-of-2 Lightning channel close, a corporate-treasury 3-of-5 cooperative spend, a vault unlock by the primary keyholder, and a single-sig wallet spend all produce the same on-chain witness: one Schnorr signature against one tweaked public key. The blockchain observer cannot distinguish them. The script-path fallback exists for the cases where cooperation is unavailable, but cooperative-path usage is the privacy-load-bearing case.

Tapscript (BIP342)

Tapscript is a new script version — selected by the leaf version byte in a Taproot script-path spend — that replaces and extends legacy Script. The changes are conservative; the goal was a stable substrate for script-path spends and a forward-compatibility mechanism for future opcode additions.

OP_CHECKSIGADD replaces OP_CHECKMULTISIG. Legacy Script’s OP_CHECKMULTISIG had a quadratic verification cost and a stack-handling quirk that complicated signature aggregation. Tapscript removes OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY and introduces OP_CHECKSIGADD, which checks a single signature and increments a running counter — explicit M-of-N multisig is constructed by chaining N OP_CHECKSIGADD calls and comparing the final counter to M. The new construction is linear in N and composes cleanly with batch verification.

OP_SUCCESSx as upgrade hooks. Sixteen previously-undefined opcodes (OP_SUCCESS80, OP_SUCCESS98, and others) are reserved in Tapscript. Encountering one immediately succeeds the script — a Tapscript that uses one of these opcodes is valid for everyone now and remains valid after any future soft fork that assigns the opcode a new meaning. This is the explicit forward-compatibility mechanism for future opcode additions; it is the substrate any covenant proposal would use to deploy without further script-version-bit changes.

Removed legacy limits. Several script-size constraints that legacy Script enforced — the 520-byte stack-element limit on push operations, the 201-opcode-per-script limit — are relaxed or removed in Tapscript. Signature verification is also redefined to commit to the entire transaction including all input amounts (the BIP341 sighash), which fixes a class of cross-input signature-reuse attacks that affected SegWit v0.

The script-version mechanism is the structurally important piece. Legacy Script has no version number; every change requires either a soft fork that reinterprets existing opcodes or a witness-version bump. Tapscript introduces a leaf-version field that allows future script versions to deploy alongside Tapscript without disturbing it. See Bitcoin Script and opcodes for the broader script-system treatment.

Activation — Speedy Trial and the post-Wars upgrade mechanism

Taproot’s activation used Speedy Trial, a variant of BIP9 designed in 2021 to avoid the prolonged contested signaling that characterized SegWit activation in 2016-2017. The mechanism:

  • A signaling window of approximately three months (the first retarget period in which 90% of blocks signal version_bit 2 triggers lock-in)
  • A lock-in period after the threshold is crossed, then activation at a deterministic future block height
  • If the signaling threshold is not met during the window, the deployment fails cleanly and a follow-up proposal can be considered without leaving long-running signaling infrastructure in place

Mining-pool signaling crossed the 90% threshold on 12 June 2021 during the first retarget cycle. Lock-in was at block 687,285; activation at block 709,632 on 14 November 2021. The activation completed without a single significant protocol incident.

The deliberate contrast to 2017 is the load-bearing point. SegWit activation under BIP9 stalled for over a year near but below the 95% miner-signaling threshold, prompting the BIP148 UASF coordinated economic-node response that ultimately triggered miner signaling (see Block Size Wars - History). Taproot’s enthusiastic technical reception meant that pool-coordination disputes did not recur; Speedy Trial’s shorter window and clean fallback structure incorporated lessons from the SegWit experience.

The broader theory of how Bitcoin soft forks activate — BIP8 and BIP9 variants, miner-activated vs user-activated signaling, the political-economic constraints on contested upgrades — lives in Soft-fork activation mechanisms and How upgrades happen. The legal upgrade categorization (soft fork vs hard fork) lives in Soft forks and hard forks.

Adoption and deployment state

Taproot adoption was initially slow despite the upgrade’s broad technical reception. Major wallets and exchanges took 12-24 months after activation to add native P2TR send-and-receive support; some held out longer. Through 2026, adoption has progressed meaningfully but not completed.

Approximate output-type distribution observed across mempools and recent blocks (2026 sample windows):

  • Legacy P2PKH / P2SH outputs: low-single-digit percentage of new outputs and inputs, primarily older wallets and entities with backward-compatibility constraints
  • Native SegWit v0 (P2WPKH / P2WSH) outputs: the substantial plurality of new outputs and inputs, reflecting widespread bech32 wallet defaults established 2018-2022
  • Taproot (P2TR) outputs: a growing share — roughly 15-25% of new outputs depending on the sample, with the rate driven by exchange-side Taproot defaults, Lightning channel funding, and the inscription protocols that use Taproot witnesses

The Taproot-witness inscription pattern (Ordinals, Runes, BRC-20) has been a substantial driver of P2TR adoption in absolute terms, though this consequence is distinct from the cooperative-spend-privacy adoption that the upgrade was designed to enable. See The Ordinals, Inscriptions, and BIP-110 controversy for the substantive engagement.

Cooperative-spend usage — the privacy-load-bearing case — is harder to measure precisely because the on-chain footprint is indistinguishable from single-sig usage. Lightning channel closes increasingly use Taproot constructions; advanced multisig configurations using MuSig2 are deployed in production but at lower volume than the foundational use cases.

Downstream consequences

Taproot’s deployment unlocked or enabled several downstream developments:

Lightning. The The Lightning Network roadmap incorporates Taproot in several directions. Point-Time-Locked Contracts (PTLCs) replace HTLCs with a Schnorr-based construction that is more private (no shared payment hash across routing nodes) and more flexible (supports advanced multi-hop patterns). Taproot-based channel funding makes cooperative channel closes indistinguishable from single-sig spends on-chain. The Eltoo channel-update construction (originally proposed by Christian Decker and Olaoluwa Osuntokun) requires SIGHASH_ANYPREVOUT, a sighash-flag soft fork that has not yet activated but is structurally cleaner under Taproot. See Lightning channels and Lightning routing for the protocol detail.

Ark and statechain-family Layer 2. The Ark protocol family — virtual-UTXO constructions that batch off-chain payments through a coordinator — uses Taproot’s cooperative-spend properties to keep on-chain footprint minimal even when the underlying logic is multi-party. Taproot is the substrate that makes covenant-light off-chain protocols practical without waiting for a covenant soft fork.

Inscriptions and the Ordinals consequence. The Ordinals protocol (Casey Rodarmor, January 2023) used the Taproot witness’s relaxed size constraints to inscribe arbitrary data — images, text, JSON, video — onto individual satoshis. Subsequent inscription protocols (BRC-20, Runes) extended the pattern. The blockspace pressure and fee-revenue consequences are the principal contemporary Bitcoin protocol controversy; substantive engagement lives in The Ordinals, Inscriptions, and BIP-110 controversy.

MuSig2 in production. Multi-party Schnorr signing using MuSig2 is deployed in production wallets and Lightning implementations. Advanced cooperative-spend constructions — corporate treasury multisigs that look like single-sig on-chain, vault designs that publish only the cooperative path — are practical post-Taproot in a way they were not pre-Taproot.

Tradeoffs and design choices

No covenant opcodes. Taproot deliberately did not introduce covenant primitives — the ability for a script to constrain how its output’s child outputs can be spent. Covenant proposals (CTV, APO, OP_VAULT, OP_CAT recursive constructions) were under active discussion during Taproot’s design but were excluded from the bundle to keep the soft fork’s scope minimal and its activation tractable. The decision was strategically sound — Taproot activated cleanly — but it left covenant-dependent constructions (advanced vaults, certain Layer-2 designs, some Eltoo variants) waiting on subsequent soft forks that have not activated. See Proposed scaling soft forks for the post-Taproot proposal landscape and OP_CAT and the covenants programmability debate for the controversy around one specific covenant approach.

OP_SUCCESSx as forward-compatibility hook with reputational risk. Reserving sixteen opcodes as future-soft-fork hooks is a clean engineering decision — future opcode additions can deploy without further script-version-bit changes — but it also means Tapscripts that use OP_SUCCESSx today are valid-but-meaningless, and the same script becomes meaningful after a future soft fork. A Tapscript author who relies on OP_SUCCESSx-current-behavior would be broken by any future activation; the assumption is that no one will rely on the no-op behavior, but the assumption is structural rather than enforced.

Privacy-via-key-aggregation as theoretical-vs-practical gap. The cooperative-spend indistinguishability property delivers strong on-chain privacy only when cooperative-spend usage is the common case. If most Taproot outputs are spent via the key path and only a few via the script path, the script-path spends are conspicuous. If most Taproot outputs are spent via the script path (e.g., because cooperation regularly fails or because the script-path use case dominates a given application), the privacy gain is degraded. The 2022-2026 deployment record has been mixed — cooperative usage is significant but script-path usage (driven especially by inscription protocols) has been more visible than the designers anticipated.

Soft-fork backward-compatibility constraint. Like SegWit, Taproot was designed as a soft fork. Non-upgraded nodes see P2TR outputs as anyone-can-spend; upgraded nodes enforce the actual validation. The design complexity is the cost of soft-fork deployability; the cost was worth paying.

Counter-arguments and tensions

Substantive engagement with critics lives in the dedicated Criticisms and Controversies notes; the H2 here flags the contested ground and refers out.

The Ordinals consequence is the principal post-Taproot tension. The Taproot-witness inscription pattern enabled by BIP341’s relaxed size constraints has driven a substantial blockspace-allocation dispute. Some critics argue that Taproot’s designers should have anticipated and constrained the inscription use case; others argue that anticipating every consequence of a flexible substrate is structurally impossible and that the dispute belongs to the application layer rather than the protocol layer. The substantive engagement on what Taproot’s inscription consequence means and what should be done about it lives in The Ordinals, Inscriptions, and BIP-110 controversy; the broader structural-throughput critique lives in Network capacity and fee-market critiques.

The covenants-not-included critique. Some developers — particularly those working on advanced vault designs, recursive sidechain constructions, and certain Lightning variants — argue that Taproot’s exclusion of covenant opcodes left valuable construction space inaccessible and that subsequent soft-fork inertia has compounded the cost. Defenders argue that scope minimization was a deliberate and sound engineering decision and that covenant proposals deserve their own scrutiny on their own merits. See OP_CAT and the covenants programmability debate for the principal contemporary covenant-debate engagement.

Activation-precedent concerns. Speedy Trial’s miner-signaling-driven design has been criticized as overweighting mining pools’ role in upgrade activation relative to economic-node and user consensus. The defense is that Taproot’s broad technical reception made the contested-activation question moot; the methodological concern remains live for future contested upgrades. See Protocol-evolution constraints for the broader engagement.

Open questions for further development

  • What is the long-run trajectory of cooperative-spend usage as a fraction of Taproot spends? The privacy-load-bearing property depends on cooperative-path usage being the common case; the 2022-2026 record is mixed.
  • Will any covenant soft fork activate, and if so, which? The post-Taproot soft-fork conversation has been active but not productive of consensus on any specific proposal; the question is structurally open through 2026-2028.
  • How does the Ordinals/Runes inscription consequence interact with the long-term security budget? Inscription-driven fee revenue is substantial during peak periods; whether it is structurally durable or fashion-driven is empirically uncertain.
  • What is the right framework for evaluating script-version proposals beyond Tapscript? Tapscript’s leaf-version mechanism permits additional script versions to deploy alongside it, but no specific Tapscript-successor proposal has reached substantive consideration.
  • Will Eltoo channels or other SIGHASH_ANYPREVOUT-dependent constructions reach activation? The structural Lightning improvements that depend on a sighash-flag soft fork are technically clean but await activation.

Canonical sources for this note

Specifications

  • BIP340 — Schnorr Signatures for secp256k1, Pieter Wuille / Jonas Nick / Tim Ruffing (2020): github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
  • BIP341 — Taproot: SegWit version 1 spending rules, Pieter Wuille / Jonas Nick / Anthony Towns (2020): github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
  • BIP342 — Validation of Taproot Scripts, Pieter Wuille / Jonas Nick / Anthony Towns (2020): github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
  • BIP350 — Bech32m format for v1+ witness addresses, Pieter Wuille (2020): github.com/bitcoin/bips/blob/master/bip-0350.mediawiki

Technical references

  • Mastering Bitcoin - Andreas Antonopoulos (3rd ed. 2023) — chapter on Taproot, Schnorr signatures, and Tapscript
  • Mastering the Lightning Network — engages the Taproot-Lightning interaction and PTLC roadmap
  • MuSig2 paper (Nick, Ruffing, Seurin, 2020) — the deployable two-round multi-party Schnorr signing protocol
  • AJ Towns and Pieter Wuille technical writings on bitcoin-dev mailing list — the principal contemporaneous explanatory record

Activation-history references

  • Speedy Trial deployment threads on bitcoin-dev mailing list (2021)
  • Bitcoin Optech newsletter coverage of Taproot activation (2021)

Graph View

Backlinks