Taproot went live on Bitcoin in November 2021. It was the largest protocol upgrade since SegWit on August 24, 2017, and Taproot significantly improved how Bitcoin handles  transactions, privacy, and programmability at the base layer.

Four years later, Taproot remains at the center of one of Bitcoin's most heated debates, not because it failed, but because a new proposal called BIP-110 wants to restrict parts of it before the upgrade has been fully explored.

To understand why BIP-110 targets Taproot, it helps to understand what Taproot actually does.

What Problem Did Taproot Solve?

Before Taproot, Bitcoin's scripting system had a visibility problem. Every time someone used a complex spending condition, a multisignature wallet, a time-locked transaction, a conditional contract, the full details of the arrangement were exposed on the blockchain.

A 3-of-5 multisig transaction looked different from a standard payment. Anyone watching the chain could see the structure, the number of signers, and the conditions attached. Privacy suffered, and complex transactions cost more because all the script data had to be published on-chain regardless of whether the conditions were triggered.

Taproot upgrade | Source: @therationalroot

Bitcoin also lacked an efficient way to aggregate signatures. Each participant in a multisig arrangement had to provide a separate signature, bloating transaction size and slowing verification.

Taproot addressed both problems.

How Taproot Works

Taproot is built on three Bitcoin Improvement Proposals (BIPs), each handling a different piece of the upgrade.

• BIP-340: Schnorr Signatures: Bitcoin originally used a signature scheme called ECDSA. Schnorr signatures replaced it with a mathematically simpler system that allows multiple signatures to be combined into one. A 3-of-5 multisig no longer needs five separate signatures on-chain; through cooperative schemes like MuSig, participants can produce a single combined signature that looks identical to a regular payment. Transactions become smaller, cheaper, and faster to verify.

• BIP-341: Script Trees: Taproot introduced a structure called Merkelized Abstract Syntax Trees (MAST). In plain terms, if a transaction has multiple spending conditions (pay after 30 days, or with 3-of-5 signatures, or with a specific key), all of those conditions are organized into a tree. Only the condition actually used gets revealed on-chain. The rest stay hidden. A complex contract can look like a simple transfer unless someone triggers the fallback conditions.

• BIP-342: Tapscript: Tapscript updated Bitcoin's scripting language to work natively with Schnorr signatures and script trees. It also introduced reserved opcodes, including OP_SUCCESS, designed as placeholders for future upgrades. Developers left empty slots in the protocol so new functionality could be added later without requiring another major overhaul.

The overall result was that advanced contracts became indistinguishable from ordinary payments, transaction sizes decreased, verification became more efficient, and Bitcoin regained a clear path for future scripting upgrades.

How Bitcoin Agreed on Taproot

Getting a decentralized network to agree on a protocol change is slow by design. 

Taproot's activation used a process called "Speedy Trial," which opened a three-month window starting in May 2021 for miners to signal support.

Miners indicated readiness by setting a specific bit in the block header. The threshold was a 90% supermajority within a difficulty adjustment period. By mid-June 2021, signaling had crossed the line. Taproot locked in and activated at block 709,632 on November 14, 2021.

The process reflected broad alignment among developers, miners, exchanges, and wallet providers, a level of consensus that later proposals, including BIP-110, have struggled to replicate.

Where Taproot Stands Today

Taproot has been live for over four years, but adoption has been gradual and uneven.

By early 2026, most major wallets, including Sparrow, Ledger, and Trezor, support Taproot and allow users to generate bc1p addresses either by default or as an option. Major exchanges including Binance, Coinbase, and Kraken support Taproot deposits and withdrawals, though rollout timelines vary.

On-chain, recent estimates place Taproot transactions at roughly 15–25% of all Bitcoin transactions depending on network conditions and measurement methodology. The majority still use legacy or SegWit address formats.

Taproot spending transactions | Source mainnet-observer 

The gap between Taproot support and real-world usage stems from a mix of technical defaults, user behavior, and adoption timelines being:

• Wallet defaults: Many wallets still default to SegWit addresses, slowing organic migration to Taproot

• User awareness: Most users don’t actively choose address types and may not understand Taproot’s advantages

• Institutional caution: Exchanges and custodians often move slowly when adopting new protocol features

• Developer-focused benefits: Core Taproot innovations include script trees, Schnorr aggregation, and Tapscript extensibility primarily benefit infrastructure builders rather than everyday transactors.

What Is Being Built on Taproot

Several active projects depend directly on Taproot's capabilities.

• Lightning Network: Predates Taproot and operates independently of it. However, Taproot improves Lightning by making channel opens and closes look like ordinary transactions on-chain, reducing costs and improving privacy. Lightning Labs and ACINQ have integrated Taproot support into their implementations.

• BitVM: BitVM is an experimental framework that allows two parties to execute complex computations off-chain while using Taproot’s script trees to let Bitcoin act as a dispute referee, settling verification on-chain only if a challenge arises. Still early in development, it represents the most ambitious attempt to expand Bitcoin’s programmability since Taproot itself.

• Vaults and covenants: These are proposed transaction structures that add spending restrictions to Bitcoin outputs and rely on Taproot's extensible scripting system and the reserved opcodes (like OP_SUCCESS) that Tapscript introduced for exactly such future use cases.

Why BIP-110 Targets Taproot

BIP-110 proposes a one-year soft fork that would impose strict limits on several transaction features and many of those limits fall directly on Taproot.

The proposal would cap the Taproot control block at 257 bytes, limiting script trees to 128 leaves. It would disable OP_SUCCESS opcodes, the reserved upgrade slots Tapscript was specifically designed to provide. BIP-110 would also invalidate the Taproot annex, a data field reserved for future use and it would disable certain OP_IF/OP_NOTIF tapscripts.

The motivation centers on Ordinals and inscriptions, which use Taproot's witness space to embed arbitrary data, images, text, tokens, directly into Bitcoin transactions. 

How BIP-110 intends to work | Source: BIP-110 Proposal

Critics of inscriptions argue the data bloats the blockchain and raises node operating costs. BIP-110 aims to restrict the mechanisms that make large data embedding possible.

Should Bitcoin Restrict Taproot? Inside the BIP-110 Debate

The concern has substance. 

The debate ultimately centers on long-term decentralization and how much strain the base layer can sustainably absorb.

• Full validation requirement: Running a Bitcoin node means downloading and verifying every byte of every block, indefinitely.

• Centralization risk: If block sizes grow faster than storage and bandwidth costs decline, validation may concentrate among larger operators, potentially weakening decentralization.

• Cyclical network pressure: Periods of congestion and data-heavy usage have historically been cyclical rather than permanent structural shifts.

• Node growth trend: Despite rising block weights and expanded witness usage, the number of reachable Bitcoin nodes has generally increased over time.

For operators who view base layer block space as scarce public infrastructure, keeping Layer 1 minimal is a long-term priority but critics argue that imposing permanent protocol constraints in response to temporary or fluctuating conditions risks overcorrecting.

Bitcoin Node Economics and the BIP-110 Debate

The tension, then, is real on both sides: Taproot was designed with built-in room to grow. BIP-110 would close off parts of that room before its upgrade surface has been fully explored. Projects like BitVM, vault proposals, and future covenant designs depend on the very features BIP-110 would restrict. 

BIP-110's supporters argue that protecting the base layer's accessibility matters more than preserving upgrade paths that remain speculative. As of early 2026, BIP-110 has roughly 6–7% of reachable node support, almost entirely through Bitcoin Knots. No mining pools have signaled consensus-level support.

For a full analysis of BIP-110's mechanics, risks, and governance implications, read our companion piece.

Conclusion

Taproot gave Bitcoin privacy, efficiency, and a programmable foundation built to evolve. Four years in, adoption is still catching up to the technology. The upgrade paths Taproot created, OP_SUCCESS, script tree versioning, the annex remain largely untapped, reserved for innovations that are only now entering development.

Restricting an upgrade before its full capabilities have been tested raises a question worth sitting with: if Bitcoin's most forward-looking feature is capped before it matures, what gets lost in the process?