On November 14, 2021, at block 709,632, Bitcoin activated Taproot — its first significant protocol upgrade since the 2017 SegWit activation that ended the block size war. Taproot wasn't controversial in the way SegWit was. Unlike SegWit, which triggered a chain split (Bitcoin Cash) when a faction of the community rejected it, Taproot achieved near-unanimous consensus among developers, miners, and node operators before activation. That consensus reflected broad agreement that Taproot's improvements — Schnorr signatures, MAST (Merkelised Alternative Script Trees), and updated scripting through Tapscript — were technically sound, non-controversial in their design goals, and long overdue. Understanding what Taproot actually changed requires going back to Bitcoin's original cryptographic choices and what they prevented.
Bitcoin launched with ECDSA (Elliptic Curve Digital Signature Algorithm) signatures — a solid choice in 2009 but not the ideal one. The alternative, Schnorr signatures, was under patent protection when Satoshi wrote the original Bitcoin code. The Schnorr patent expired years before Taproot's activation, opening the path to upgrade. The difference matters because of a property called linearity: Schnorr signatures can be mathematically combined. Two parties can produce a single aggregated signature over a combined public key that is indistinguishable from a simple single-party signature. ECDSA cannot do this cleanly — multisig transactions using ECDSA must reveal all public keys and all individual signatures, making them significantly larger and identifiably distinct from single-signature transactions.
The second limitation was script transparency. Bitcoin's scripting system allows programmable spending conditions — a transaction output might be spendable by Alice alone, or by 2-of-3 multisig, or after a time lock, or by a Lightning channel closure mechanism. Pre-Taproot, whenever a complex spending condition was used, the entire script (all branches, including unused ones) was published on-chain. A Lightning channel that can be closed cooperatively (with both parties' signatures) or unilaterally (with a time-locked reveal of commitment transactions) was revealing its entire structure every time it closed — even the unilateral close path that was never needed. This was a privacy leak and an inefficiency: fees were paid for data the network needed only in the non-cooperative case.
BIP340 introduced Schnorr signatures to Bitcoin as the new standard signature scheme for Taproot outputs. The immediate practical benefits flow from Schnorr's linearity property through the MuSig2 protocol — an interactive protocol allowing multiple parties to produce a single aggregated public key and signature. In practical terms: a company's treasury requiring approval from any 3 of its 5 signatories can hold Bitcoin in a Taproot output controlled by an aggregated key. When spending, the 3 approving signatories run MuSig2 to produce a single signature. On-chain, the transaction looks identical to a personal wallet transaction — single public key, single signature, 57.5 bytes. Pre-Taproot, the equivalent P2SH 3-of-5 multisig required publishing all five public keys (165 bytes) and three individual signatures (216 bytes) — 381 bytes versus 57.5 bytes. The cost reduction is substantial; the privacy improvement (multisig is indistinguishable from single-sig in the cooperative case) is arguably more significant.
Schnorr's non-malleability is an additional security property: unlike ECDSA, Schnorr signatures are provably non-malleable (a third party cannot modify a valid signature to produce a different valid signature for the same message without the private key). This closes subtle attack vectors in complex Bitcoin protocols that relied on transaction IDs being stable before confirmation.
BIP341 introduced MAST (Merkelised Alternative Script Trees) as the mechanism for hiding unused spending conditions. Rather than encoding all spending conditions in a single script exposed at spend time, Taproot structures them as a Merkle tree. Each leaf in the tree is an alternative spending condition. When spending via a specific condition, you reveal only that leaf's script plus a Merkle proof that it exists in the committed tree — all other leaves remain private. The Merkle root of the entire tree is committed to in the output's public key (tweaked into the key using a cryptographic construction). This means: a complex multi-party vault with 7 different spending conditions reveals only the one condition actually used. The other 6 conditions never appear on-chain, even after the output is spent.
The practical implication for Lightning Network: Lightning channels are multi-party contracts with several spending paths (cooperative close, unilateral close with revocation, time-locked HTLC outputs). Taproot Lightning (being deployed across major implementations including LND, CLN, and Eclair through 2024–2026) makes all Lightning channel outputs look like simple P2TR (Pay-to-Taproot) outputs when cooperatively closed — indistinguishable from any other Taproot transaction. This improves Lightning's on-chain privacy and reduces cooperative channel close transaction fees by approximately 30–40% compared to legacy P2WSH channel outputs.
Taproot's script path has an interesting characteristic: arbitrary data can be included in the "witness" (the script execution data revealed when spending via the script path) without being subject to the same size restrictions as the script itself. Casey Rodarmor's Ordinals protocol (launched January 2023) exploited this: by storing arbitrary data (images, text, code) in the Taproot script path witness during a carefully constructed transaction, and using the Ordinals theory (which assigns ordinal numbers to individual satoshis to track their provenance), a content creator can permanently inscribe data into the Bitcoin blockchain and associate it with specific satoshis. This created "Bitcoin NFTs" — digital artefacts inscribed into Bitcoin blocks, stored by all Bitcoin full nodes, theoretically as permanent and immutable as Bitcoin transactions themselves.
Ordinals became Bitcoin's most controversial use case since its inception. Supporters: Ordinals creates demand for Bitcoin block space from a new user category, demonstrates Bitcoin's extensibility without protocol changes, and creates a native NFT ecosystem on the most secure blockchain. Critics: arbitrary data storage is blockchain bloat, full nodes are burdened with storing unrelated data, and the cultural dissonance of JPEG images on a payments network undermines Bitcoin's identity. Neither side has definitively prevailed — Ordinals and Runes (a more efficient fungible token protocol built on Ordinals' infrastructure, launched at the April 2024 halving) continue generating significant Bitcoin transaction volume, and the debate over their place in Bitcoin's future is ongoing.
Taproot adoption has grown steadily from the first blocks post-activation. By 2026, approximately 60–65% of Bitcoin transaction outputs use P2TR (Pay-to-Taproot) format, driven by Lightning Network implementations (which defaulted to Taproot channels in LND 0.16+ and CLN's taproot-channel implementation) and exchange withdrawal addresses upgrading to more efficient output types. The remaining 35–40% are legacy output types (P2PKH, P2SH, P2WPKH) from wallets and services that haven't updated their address generation — these will gradually migrate as software updates propagate. Future Bitcoin development builds directly on Taproot's foundation. Proposals like OP_CAT (re-enabling a disabled opcode that would allow creating "covenants" — Bitcoin outputs that can restrict how their value is subsequently spent, enabling vaults and non-custodial DeFi), CHECKSIGFROMSTACK, and various soft fork proposals for Bitcoin-native smart contracts all require Taproot as a prerequisite. Whether these proposals achieve consensus for activation is the ongoing debate at Bitcoin's development frontier.
New guides, tool updates, and market analysis — straight to your inbox. No spam, unsubscribe anytime.
0 Comments
Leave a Comment
Your email won't be published. After submitting, you'll receive a quick verification email — click the link to publish your comment.