Taproot is a protocol upgrade to the Bitcoin blockchain, activated in November 2021 at block height 709,632. It is the most significant change to Bitcoin since the Segregated Witness (SegWit) update in 2017 and resulted from years of research and broad consensus among Bitcoin node operators. The upgrade was implemented as a soft fork, remaining backward-compatible with existing nodes and not splitting the network.
The upgrade is composed of three interconnected proposals: BIP-340 (Schnorr Signatures), BIP-341 (Taproot), and BIP-342 (Tapscript). Together, these improvements address longstanding limitations in Bitcoin's scalability, transaction privacy, and smart contract capabilities.
Prior to Taproot, Bitcoin's principal utility was widely understood as a peer-to-peer, censorship-resistant payment system and a store of value. While newer blockchains were built with native support for smart contracts and decentralized applications, Bitcoin's scripting language remained comparatively limited. This made it difficult to compete with more programmable networks as demand for complex on-chain contracts grew.
A related problem concerned scalability. Each spendable amount of Bitcoin carries a script defining the conditions under which those coins can be spent. When a transaction is broadcast and recorded on the blockchain, the full script becomes public. For multi-party contracts or complex spending conditions, a large volume of data was stored and broadcast, even when most of it was irrelevant to the transaction. This caused network congestion and reduced throughput.
Taproot was designed to address both issues by rethinking how scripts and signatures are encoded, verified, and stored on-chain.
A foundational component of Taproot is the adoption of Schnorr signatures, specified in BIP-340. Bitcoin previously relied on the Elliptic Curve Digital Signature Algorithm (ECDSA) to verify transactions. While ECDSA is secure, it lacks a property Schnorr signatures offer natively: signature aggregation.
With Schnorr signatures, multiple parties participating in a single transaction can combine their individual signatures into one. A 3-of-3 multi-signature transaction, for example, produces a single aggregated signature rather than three separate ones. This makes multi-signature transactions indistinguishable from standard single-key transactions when viewed on the blockchain, which has meaningful implications for both privacy and on-chain data efficiency.
Schnorr signatures also allow batch verification, letting a node validate many signatures simultaneously instead of one by one. This reduces the network's computational load and speeds up processing. Schnorr signatures were not used in Bitcoin's original design because they were covered by an active patent. That patent expired long before Taproot's development, allowing their inclusion.
The second core component, introduced through BIP-341, is the Merklized Alternative Script Tree, commonly abbreviated as MAST. The concept had been proposed as far back as 2013 but was never incorporated into the protocol until Taproot.
Before Taproot, Bitcoin held under a complex contract with multiple spending conditions required the entire script to be revealed on the blockchain when spent. If a contract had ten possible conditions but only one was exercised, all ten were exposed publicly. This wasted block space and user privacy.
MAST resolves this by using a Merkle tree to encode all possible spending conditions into a single short cryptographic hash. When a transaction is spent, only the used condition is revealed. The other branches stay hidden. This greatly shrinks the on-chain footprint of complex contracts and limits information visible to outside observers.
Pay-to-Taproot, defined in BIP-341 alongside MAST, is the new transaction type that brings Schnorr signatures and MAST together. It creates a unified output format that can be spent either through a straightforward key path, using a single Schnorr signature, or through a script path, using one of the conditions encoded in a MAST.
The key insight of P2TR is that the MAST is embedded inside the public key. This means a transaction using a simple key-path spend looks identical on the blockchain to one using a complex multi-party script, as long as the key path is taken. An external observer cannot tell if any scripts were encoded in the output. Only when a script path is used is the relevant MAST branch revealed.
This design substantially narrows the gap between simple payments and complex contracts in terms of both size and privacy.
BIP-342 introduced Tapscript, an updated version of Bitcoin's scripting language tailored for Taproot's script-path spending. Tapscript replaces ECDSA signature operations with Schnorr-compatible equivalents and makes it easier to add new opcodes in future upgrades. It is more extensible than the existing script system, reducing friction in adding new functionality to Bitcoin over time.
Taproot's activation had immediate and longer-term effects across the Bitcoin ecosystem. In the short term, users of multi-signature wallets and Lightning Network payment channels gained cheaper transactions and improved privacy, since their contracts could be settled on-chain without revealing unnecessary details.
Over the medium term, Taproot's expanded data capacity per block enabled new use cases previously impractical on Bitcoin. Bitcoin Ordinals, a protocol that inscribes arbitrary data onto individual satoshis, became possible partly because Taproot script-path witnesses carry larger payloads than prior transaction types. This enabled the emergence of BRC-20 tokens and other experimental token standards on Bitcoin. These developments were not part of Taproot's original design intent but resulted from the technical headroom the upgrade created.
Taproot's activation was coordinated through Speedy Trial, a modified version of BIP-9's miner signaling process. Miners signaled readiness within a series of difficulty periods, and the upgrade locked in after 90 percent of blocks in a single period signaled support. Speedy Trial was chosen partly to avoid the prolonged community conflict that accompanied SegWit's activation in 2017. The upgrade locked in on June 12, 2021, and the soft fork became active in November.
.webp)