TL;DR: Taproot is a Bitcoin protocol upgrade activated in November 2021 that introduced Schnorr signatures, Merklized Alternative Script Trees (MAST), and an updated scripting language called Tapscript. Together, these changes make complex Bitcoin transactions smaller, cheaper, and more private by letting multisig and smart contract transactions look identical to simple singlesig payments on-chain when all parties cooperate.
Taproot is a soft fork upgrade to the Bitcoin protocol, defined across three Bitcoin Improvement Proposals (BIP 340, BIP 341, and BIP 342). It replaces Bitcoin's previous signature scheme with Schnorr signatures, introduces a new output type called Pay-to-Taproot (P2TR), and uses Merkle tree structures to hide unexecuted spending conditions. The result is improved privacy, efficiency, and programmability for Bitcoin transactions.Why Bitcoin Needed Taproot
Before Taproot, Bitcoin's transaction system had a privacy problem. Anyone examining the blockchain could distinguish between a simple single-key payment and a complex multisig or timelocked transaction. The spending script was fully visible on-chain once the funds were spent, exposing every condition the sender had set up, including the ones that were never used.
This mattered for two reasons. First, it leaked information about how users managed their bitcoin. A 2-of-3 multisig transaction looked different from a standard payment, revealing that the sender used a multi-party security setup. Second, complex scripts were expensive. Every spending condition had to be included in the transaction data, even conditions that were never triggered, inflating transaction size and fees.
Taproot addressed both problems simultaneously. By combining Schnorr signatures with Merkle tree structures, it created a system where the common case (all parties agree and sign cooperatively) produces a transaction indistinguishable from a simple singlesig payment. The complex fallback conditions exist but remain hidden unless they are actually needed.
The Three BIPs Behind Taproot
Taproot arrived as three interconnected BIPs (BIP 340 for Schnorr signatures, BIP 341 for the Taproot output construction, and BIP 342 for Tapscript), each handling a different layer of the upgrade.
| BIP | Name | What It Defines |
|---|---|---|
| BIP 340 | Schnorr Signatures | New signature scheme replacing ECDSA for Taproot outputs. Enables key aggregation, batch verification, and 64-byte signatures. |
| BIP 341 | Taproot | New P2TR output type with tweaked public keys. Defines key-path and script-path spending, MAST structure, and the TapTweak hash. |
| BIP 342 | Tapscript | Updated scripting rules for Taproot script-path spending. Replaces OP_CHECKMULTISIG with OP_CHECKSIGADD and adds OP_SUCCESS upgrade mechanism. |
BIP 340: Schnorr Signatures
BIP 340 introduced Schnorr signatures to Bitcoin, replacing ECDSA (Elliptic Curve Digital Signature Algorithm) as the signature scheme for Taproot outputs. Schnorr signatures were actually invented before ECDSA, but a patent (held by Claus Schnorr until 2008) prevented their use when Satoshi Nakamoto designed Bitcoin. ECDSA was the patent-free alternative available at the time.
Schnorr signatures have several mathematical properties that make them superior to ECDSA for Bitcoin's purposes:
- Linearity: Schnorr signatures are linear, meaning multiple signatures can be combined into a single aggregate signature. With ECDSA, each signer in a multisig transaction must provide a separate signature, and each one is verified independently. With Schnorr, a 3-of-3 multisig can produce one signature that is the same size as a single-key signature.
- Provable security: Schnorr signatures have a formal mathematical proof of security under the random oracle model. ECDSA lacks this clean proof, relying instead on ad hoc security assumptions.
- Non-malleability: Schnorr signatures are inherently non-malleable. A valid signature cannot be altered by a third party into a different valid signature for the same message, eliminating an entire class of potential attacks.
- Efficiency: Schnorr signatures are slightly smaller and faster to verify than ECDSA signatures. For a single signature, the difference is modest. At scale, across millions of transactions, it compounds.
Key Aggregation With MuSig22222
The linearity property enables key aggregation, which is the most consequential practical benefit of Schnorr for Bitcoin users. Multiple public keys can be combined into a single aggregated public key, and multiple signers can collaboratively produce a single signature that validates against that aggregated key.
Consider a 3-of-3 multisig setup. With ECDSA, the transaction requires three separate public keys and three separate signatures, all visible on-chain. With Schnorr and the MuSig2 protocol, the three parties combine their keys into one aggregated public key and produce one aggregated signature. On-chain, this looks exactly like a standard singlesig transaction. No observer can determine that three separate parties were involved.
Key aggregation also directly reduces transaction size. Fewer signatures and keys means fewer bytes of data, which means lower fees.
BIP 341: Taproot (MAST)
BIP 341 defines the Taproot construction itself, including the new Pay-to-Taproot (P2TR) output type and the Merklized Alternative Script Tree (MAST) structure.
A P2TR output encodes a single public key on-chain. But that key commits to two possible spending paths:
- Key path: The output can be spent with a single Schnorr signature corresponding to the public key. If all parties cooperate, this is the only thing that appears on-chain. It looks identical to any other singlesig payment.
- Script path: Hidden inside the public key (via a cryptographic tweak) is a Merkle root that commits to a tree of alternative spending scripts. If the key path cannot be used (e.g., one party is unresponsive, a timelock condition must be enforced), the spender reveals only the specific script branch being executed, plus a Merkle proof showing that branch was committed to in the tree.
How MAST Works
MAST uses a Merkle tree to organize multiple spending conditions. Each leaf of the tree contains a different script (a different set of conditions under which the bitcoin can be spent). The root of the tree is cryptographically committed to in the P2TR output's public key.
When spending via the script path, the user reveals only the leaf they are executing and provides the Merkle proof (the sibling hashes along the path from the leaf to the root). All other leaves remain hidden. An observer can verify that the revealed script was part of the committed tree, but they learn nothing about what the other scripts contained or how many alternatives existed.
This structure scales efficiently. A tree with 128 possible spending scripts requires a Merkle proof of only seven hashes (log2 of 128), regardless of which script is used. The unexecuted scripts never touch the blockchain.
BIP 342: Tapscript
BIP 342 introduced Tapscript, an updated version of Bitcoin's scripting language designed specifically for Taproot script-path spending. Tapscript makes several changes to Bitcoin Script:
- Schnorr-native opcodes: The signature-checking opcodes (OP_CHECKSIG, OP_CHECKSIGVERIFY) were updated to verify Schnorr signatures instead of ECDSA in the Tapscript context.
- OP_CHECKSIGADD: A new opcode that replaces OP_CHECKMULTISIG. The old multisig opcode was inefficient, requiring the verifier to try combinations of signatures against keys. OP_CHECKSIGADD works with Schnorr's batch verification properties for cleaner, faster k-of-n threshold validation.
- OP_SUCCESS opcodes: Tapscript repurposes several previously undefined opcodes as OP_SUCCESS, which makes any script containing them automatically valid. This is a forward-compatibility mechanism. Future soft forks can redefine these opcodes to add new functionality without breaking existing consensus rules. The upgrade path for new script capabilities is built in.
- Removed size limits on scripts: Tapscript removes the 10,000-byte script size limit that applied to legacy scripts, enabling more complex spending conditions.
Together, these Tapscript changes make Bitcoin's scripting system more expressive and easier to upgrade in the future, while maintaining backward compatibility with the existing consensus rules.
Privacy Improvements
Taproot's most significant contribution is to on-chain privacy through output uniformity. Every P2TR output looks the same: a single 32-byte public key. Whether the output is controlled by one person, a 5-of-7 multisig federation, or a complex contract with dozens of conditional branches, the on-chain representation is identical.
When spent via the key path (the cooperative case), the spending transaction reveals one public key and one signature. An on-chain observer cannot distinguish between:
- A single user sending bitcoin from a standard wallet
- Two parties closing a Lightning channel cooperatively
- A corporate treasury executing a 3-of-5 multisig spend
- An escrow contract where all parties agreed on the outcome
All of these produce the same on-chain fingerprint. This uniformity breaks chain analysis heuristics that previously relied on script structure to classify transaction types and cluster addresses.
Even when the script path is used (the non-cooperative fallback), privacy improves compared to pre-Taproot scripts. Only the specific branch being executed is revealed, and the number and content of unused branches remain hidden. Under the old P2SH system, the entire script was exposed on spending.
You can observe this directly on Blockstream Explorer. P2TR outputs display as a uniform output type, and key-path spends show a single signature regardless of the underlying complexity. Compare this to legacy P2SH outputs, where the redeem script revealed at spend time exposes distinct patterns for different configurations.
Taproot's privacy gains come with one exposure: P2TR outputs carry an x-only public key directly in the witness program. This means the public key is exposed on-chain as soon as the address is funded, not only when it is spent. In the context of future quantum-resistance planning, P2TR addresses are classified as quantum-exposed, alongside P2PK and legacy address reuse, rather than as "hidden until spend" formats like P2PKH/P2WPKH. BIP 360 or an equivalent quantum-safe spending path would need to activate before Taproot addresses can be classified as post-quantum-safe.
Efficiency Gains
Taproot reduces transaction weight (and therefore fees) for complex spending conditions through several mechanisms:
| Mechanism | How It Reduces Size |
|---|---|
| Key aggregation (Schnorr) | A k-of-k multisig produces one key + one signature instead of k keys + k signatures |
| Key-path spending | The cooperative case requires no script data at all, just a key and a signature |
| MAST (script path) | Only the executed branch is revealed. A 1-of-128 script path requires ~7 hashes instead of 128 full scripts |
| Batch verification | Multiple Schnorr signatures can be verified together faster than individually, reducing node CPU cost |
For simple singlesig transactions, the fee savings are modest. Taproot's efficiency gains scale with complexity. A contract with ten possible spending paths that resolves cooperatively (key path) saves nearly all the data that would have been required to encode those ten paths under the old system. The more complex the arrangement, the larger the savings when the common cooperative case is used.
The P2TR Output Type
P2TR is the output type introduced by Taproot, using SegWit version 1 (v1). It follows the earlier P2WPKH and P2WSH output types (SegWit version 0) and uses bech32m address encoding (addresses starting with bc1p).
A P2TR output commits to a 32-byte x-only public key (Schnorr uses x-only keys, saving one byte compared to compressed ECDSA keys). This key can be either:
- A plain public key (for simple singlesig)
- A tweaked public key that commits to a MAST root (for key-path + script-path combinations)
When a wallet creates a P2TR output with complex conditions, it constructs the Merkle tree of scripts, computes the root, tweaks the internal public key by that root, and publishes only the tweaked key. The output itself reveals nothing about the scripts inside.
Under the Hood: The Tweaked Public Key
The cryptographic core of Taproot is the key tweaking operation defined in BIP 341. Given an internal public key P and a Merkle root m of the script tree, the tweaked output key Q is computed as: Q = P + hash(P || m) * G, where G is the secp256k1 generator point and hash is a tagged SHA-256 hash (TapTweak). This single elliptic curve point addition binds the internal key and the entire script tree together into one 32-byte x-only public key.
For key-path spending, the signer proves knowledge of the private key corresponding to Q by producing a Schnorr signature. The private key for Q is simply the internal private key plus the tweak scalar, which any party holding the internal private key can compute. For script-path spending, the spender reveals the internal key P, the specific leaf script, and the Merkle proof connecting that leaf to the root. The verifier recomputes Q from P and the proven root, confirms it matches the output key, then executes the revealed script under Tapscript rules.
If no script tree is needed (a simple singlesig output), the tweak is computed with an empty Merkle root, producing an output key that commits to the key alone. This means every P2TR output uses the same structure whether it contains zero or a thousand script branches, which is what makes them indistinguishable on-chain.
Taproot and Smart Contracts on Bitcoin
Taproot expands what is practical to build on Bitcoin without changing what is theoretically possible. Bitcoin Script was already capable of expressing complex conditions. The problem was cost and privacy: every branch of logic had to be published on-chain, making complex scripts expensive and transparent.
With MAST, developers can construct contracts with hundreds of conditional branches while keeping the on-chain cost proportional only to the branch that executes. This makes several categories of contracts practical that were previously too expensive to deploy:
- Complex multisig policies: Corporate governance structures with different quorum requirements depending on the action (e.g., 2-of-3 for routine spending, 3-of-5 for large transfers, a time-delayed recovery key if all other keys are lost).
- Hash Time-Locked Contracts (HTLCs): The building blocks of Lightning payment routing become more efficient under Taproot, since the cooperative close (the common case) uses the key path and reveals nothing about the HTLC conditions.
- Discreet Log Contracts (DLCs): Oracle-based contracts that settle based on real-world outcomes. Taproot allows DLC structures with many possible outcomes to be encoded in a MAST tree without proportional on-chain cost.
- Vaults: Time-delayed spending structures that give users a window to cancel unauthorized transactions. Taproot vaults can encode the normal spending path (key path) and the emergency clawback path (script path) without revealing the vault structure unless a clawback is actually triggered.
The OP_SUCCESS upgrade mechanism in Tapscript also provides a clean path for future improvements. Proposals like OP_CHECKTEMPLATEVERIFY (CTV) and other covenant opcodes could be deployed as soft forks by redefining OP_SUCCESS opcodes, building on the foundation Taproot established. On the Liquid Network, Blockstream's Simplicity language already extends scripting capabilities beyond what Bitcoin Script and Tapscript can express, enabling formally verifiable smart contracts including covenants, vaults, and complex delegation schemes. Simplicity has been live on Liquid since July 2025.
Taproot and the Lightning Network
The Lightning Network benefits directly from Taproot in several ways.
Channel opens and cooperative closes become indistinguishable from regular on-chain payments. A Lightning channel is fundamentally a 2-of-2 multisig between two parties. With Schnorr key aggregation, the funding transaction and cooperative close transaction both appear as standard singlesig P2TR spends. Before Taproot, Lightning channels used P2WSH multisig outputs that were identifiable as such on-chain.
Force closes benefit from MAST. The complex scripts that enforce timelocks and penalty mechanisms during a non-cooperative close can be organized in a MAST tree, with only the relevant branch revealed. This reduces the on-chain data required for force closes and hides the full structure of the channel's enforcement logic.
Point Time-Locked Contracts (PTLCs) become possible with Schnorr. PTLCs are a Schnorr-native replacement for HTLCs that improve routing privacy by using different payment points at each hop instead of a single hash. This prevents a routing node from correlating payments across the path by looking for the same hash preimage. Core Lightning (CLN), the Lightning implementation maintained by Blockstream, supports Taproot address types, and Schnorr-based channel constructions such as simple Taproot channels and PTLCs are an active area of Lightning protocol development.
The Activation Process
Taproot's activation revealed as much about Bitcoin governance as it did about Bitcoin technology.
The upgrade was uncontroversial in principle. Virtually every participant in the Bitcoin ecosystem supported the technical changes. The debate centered on how to activate it: specifically, whether miners should have the ability to block or delay activation.
Speedy Trial
After extended debate across mailing lists, IRC channels, and community calls, the Bitcoin development community settled on a mechanism called Speedy Trial. This was a time-limited signaling period: miners had roughly 3-4 months, starting at block 681,408 (April 24, 2021), to signal support for Taproot by setting a specific bit in their block headers. If 90% of blocks within any difficulty adjustment period (2,016 blocks) signaled support, Taproot would lock in and activate after a delay.
Miners reached the 90% threshold in June 2021, locking in Taproot. The upgrade officially activated at block 709,632 on November 14, 2021.
What the Debate Revealed
The activation debate was significant because it forced the Bitcoin community to articulate who holds ultimate authority over protocol changes. Two camps emerged:
- BIP 8 (LOT=true) advocates argued that users running nodes define the protocol rules, and miners should not have veto power over an upgrade that users have chosen to adopt. Under this model, Taproot would activate after a fixed deadline regardless of miner signaling.
- Speedy Trial advocates favored a BIP 8 variant with LOT=false and a compressed signaling window. This approach used miner signaling as a coordination mechanism to reduce the risk of chain splits, while offering a faster, lower-risk activation path even though it gave miners a temporary ability to delay.
The fact that miners signaled quickly made the practical difference moot, but the underlying governance questions remain relevant for future upgrades. The debate established a precedent: Bitcoin protocol changes require broad ecosystem consensus, and the activation mechanism itself is subject to community deliberation.
Taproot Adoption and What Comes Next
Taproot adoption has grown steadily since activation but remains an ongoing process. Wallet software, exchanges, and services have added P2TR support incrementally. The privacy benefits of Taproot strengthen as more users and applications generate P2TR outputs, increasing the anonymity set.
Several developments build on Taproot's foundation:
- MuSig2: The key aggregation protocol for Schnorr has matured since Taproot's activation. MuSig2 enables practical multi-party key aggregation with only two rounds of communication, making it suitable for interactive multisig setups.
- FROST (Flexible Round-Optimized Schnorr Threshold): A threshold signature scheme that extends Schnorr key aggregation to k-of-n setups (e.g., 3-of-5), where only a subset of signers is needed. FROST produces a single signature indistinguishable from a singlesig spend.
- Taproot Assets (formerly Taro): A protocol for issuing assets on Bitcoin using Taproot's MAST structure to embed asset metadata in regular Bitcoin transactions.
- Covenant proposals: Opcodes like OP_CHECKTEMPLATEVERIFY (CTV), OP_VAULT, and OP_CAT could use Tapscript's OP_SUCCESS upgrade mechanism to add new spending condition types. These proposals are under active discussion and development.
- Improved Lightning channels: Taproot-native channel types reduce the on-chain footprint of Lightning and lay the groundwork for PTLCs, channel factories, and other scaling improvements.
Taproot rebuilt the transaction foundation in a way that makes Bitcoin's next generation of privacy, scalability, and programmability improvements possible. Each of the proposals above depends on the infrastructure Taproot put in place.
Frequently Asked Questions
Is Taproot a hard fork or a soft fork?
Taproot is a soft fork. Nodes that did not upgrade still accept Taproot transactions as valid (they see the new output type as "anyone can spend" under the old rules, but upgraded nodes enforce the Taproot spending rules). This backward compatibility means no chain split occurred at activation.
Do I need to do anything to use Taproot?
You need a wallet that supports P2TR addresses (starting with bc1p). Most major Bitcoin wallets have added Taproot support since 2021. When you send bitcoin to a P2TR address or generate one in your wallet, you are using Taproot. No manual configuration is required beyond using a compatible wallet.
Does Taproot make all Bitcoin transactions private?
Taproot improves privacy for complex transactions by making them look like simple ones on-chain, but it does not provide full transaction privacy. Amounts, addresses, and transaction graphs remain visible. Taproot's privacy benefit is structural: it removes the ability to distinguish transaction types based on script patterns. For amount and address privacy, protocols like Confidential Transactions (used on the Liquid Network) go further.
How can I identify Taproot transactions on-chain?
P2TR outputs are identifiable by their address format (bc1p...) and their SegWit version (v1). You can view Taproot transactions on any block explorer that supports the format. On Blockstream Explorer, P2TR outputs are labeled as such, and you can examine the witness data to see whether the key path or script path was used for spending.
When was Taproot activated on Bitcoin?
Taproot activated at block 709,632 on November 14, 2021. Miners reached the 90% signaling threshold in June 2021 using the Speedy Trial mechanism, which locked in the upgrade ahead of activation. The defining Bitcoin Improvement Proposals (BIP 340, BIP 341, and BIP 342) were published in January 2020, and the activation followed nearly two years of community deliberation over the signaling method.
What is the difference between Taproot and SegWit?
SegWit (Segregated Witness), activated in 2017, separated signature data from transaction data to fix transaction malleability and increase block capacity. Taproot builds on SegWit's foundation (P2TR is SegWit version 1) by adding Schnorr signatures, MAST, and Tapscript. SegWit changed how transaction data is structured. Taproot changed what Bitcoin can do with that structure.
Why did it take until 2021 to add Schnorr signatures if they are superior to ECDSA?
Schnorr signatures were patented by Claus Schnorr until 2008. When Satoshi Nakamoto designed Bitcoin in 2008-2009, ECDSA was the available patent-free alternative. After the patent expired, incorporating Schnorr into Bitcoin required years of research, specification, review, and the development of a safe activation mechanism. The Schnorr/Taproot proposal was formally published in January 2020 and activated in November 2021.