BIP-110 has become one of the most debated proposals in Bitcoin's recent history. At its core, it attempts to address a bitter irony: two upgrades designed to scale Bitcoin --- Taproot and SegWit --- were co-opted in ways that achieved the exact opposite of their intended purpose. To understand why BIP-110 exists and what it actually does, we need to revisit Taproot's original design and what happened when it met the real world.
Before Taproot, spending a SegWit output was straightforward: you provided an ECDSA signature and a public key. Taproot introduced something far more sophisticated while actually using less data on-chain, thanks to Schnorr signatures.
A Taproot output gives you two spending paths. The key path is the common case --- similar to a traditional spend, it's compact and efficient. The script path is where things get interesting. Attached to the key is a binary tree of spending conditions called tap leaves, where each leaf represents an alternative way to redeem the funds. If you have a tree seven layers deep, that's 128 possible spending conditions.
The elegance of Taproot is that you only reveal the spending condition you actually use. Before Taproot, if you had a complex script with multiple OP_IF/OP_NOTIF branches, you had to reveal the entire script on-chain when you spent, even the branches you didn't execute. With Taproot, only the relevant leaf of the script tree gets exposed. Everything else stays hidden.
This is the essence of scaling Bitcoin: you accomplish the same financial activity with a smaller on-chain footprint. It also provides a privacy benefit, since observers can't see the spending conditions that weren't used. For use cases like multisig and Lightning Network channels, this was a significant improvement. That's why the community was excited about Taproot. That's what it was built for.
Taproot was never intended as a mechanism for arbitrary data storage. But that's exactly what it became.
The inscriptions craze exploited a combination of Taproot's script path and the SegWit witness discount to store data --- images, files, and other non-financial payloads --- on the Bitcoin blockchain at a subsidized cost. The mechanism works through two transactions: a commitment transaction that creates a Taproot output (which looks like any other Taproot address from the outside), and a reveal transaction that spends from it using the script path, exposing chunks of data wrapped in OP_FALSE OP_IF sequences.
This is a deliberate inversion of Taproot's design intent. Where legitimate monetary users spend via the key path and reveal minimal data, inscription creators specifically use the script path to maximize the data they put on-chain. They stuff non-contiguous chunks of JPEG or other file data between repeated OP_FALSE OP_IF opcodes, exploiting the witness discount to do so at reduced cost relative to the block space consumed.
The results have been stark: roughly 90% of Taproot outputs are dust, meaning they exist for data storage rather than monetary use. From 2023 onward, the UTXO set more than doubled. Node operators routinely report that initial block download proceeds normally until 2023, at which point synchronization time extends by weeks. Two technologies that were supposed to make Bitcoin leaner and more efficient as a monetary network had the opposite effect when combined.
BIP-110 is a proposed soft fork that introduces several targeted restrictions. It does not attempt to be an all-encompassing anti-spam measure. Its stated objective targets contiguous arbitrary data, but its taproot guardrails address the inscription mechanism directly. Here are the key components:
Within the Taproot script path, OP_IF and OP_NOTIF are disabled. This is the most consequential change and the one that directly breaks the inscription mechanism.
The reasoning is straightforward: OP_IF has no legitimate purpose inside tapscript. The entire point of Taproot's script tree is that alternative spending conditions go in separate tap leaves. Using OP_IF inside a tap leaf means you're putting conditional logic back into a single script instead of using the tree structure --- which is both inefficient and more expensive. You're paying more to accomplish less, and you're doing it in a way that defeats Taproot's design.
Legitimate wallets already design around this. Liana, for example, does not generate OP_IF opcodes in its tapscript. It doesn't use OP_SUCCESS, and it doesn't go deeper than seven layers. BIP-110 doesn't affect it at all, because it's actually using Taproot correctly.
The wallet compatibility concerns raised by some --- particularly around miniscript compilation potentially inserting OP_IF --- amount to a call for better wallet design, not a reason to abandon the proposal. If a wallet is generating OP_IF inside tapscript, it's using Taproot inefficiently regardless of whether BIP-110 activates.
OP_SUCCESS opcodes within tapscript are also disabled. These opcodes cause any script containing them to evaluate as valid unconditionally, similar to how pre-SegWit nodes treat SegWit spends. They exist as upgrade hooks for future opcode additions within Taproot.
Like OP_IF, OP_SUCCESS can be used to stash arbitrary data: you load the data into the script and include an OP_SUCCESS somewhere, and the entire thing is accepted as valid. Disabling it closes this vector.
Importantly, this does not conflict with CTV (OP_CHECKTEMPLATEVERIFY). Because CTV predates Taproot, it doesn't rely on OP_SUCCESS within tapscript. CTV can still be activated during BIP-110's enforcement period without issue.
BIP-110 caps the taproot control block at 256 bytes. The control block is witness data required for script path spending, and its size grows with the depth of the script tree. A 256-byte limit corresponds to a maximum tree depth of seven, which allows for 128 tap leaves.
This may sound limiting, but 128 distinct spending conditions is substantial for any realistic monetary use case. The restriction primarily targets pathologically deep trees that serve no practical financial purpose.
The proposal also sets a 34-byte consensus limit on scriptPubKeys and an 83-byte consensus limit on OP_RETURN outputs. The OP_RETURN limit is particularly significant. Previously kept in check by mempool relay filters, the effective cap on OP_RETURN was relaxed (to roughly 100 kilobytes) to accommodate projects like Citrea that needed unconstrained OP_RETURN to function. The removal of the old relay filters meant giving up node-level sovereignty over what gets relayed in the mempool. BIP-110 reestablishes a consensus-level limit.
Any UTXO created before BIP-110 activates remains fully spendable under the old rules, even if it contains OP_IF or other restricted opcodes. This addresses the concern about existing funds becoming unspendable.
BIP-110 also includes a 12-month enforcement window. After that period, the restrictions expire unless renewed. This means even in the unlikely scenario where someone creates a UTXO after activation that violates the new rules due to negligent wallet software, their funds would only be temporarily unspendable.
The most persistent technical objection involves a hypothetical: what if someone has a pre-signed inheritance transaction with timelocks that would create a UTXO after the activation date, and that UTXO happens to contain restricted opcodes? That UTXO would be unspendable for the duration of the 12-month window.
This scenario requires a remarkable combination: someone sophisticated enough to design a complex tapscript inheritance scheme with pre-signed transactions and timelocks, yet simultaneously careless enough to include OP_IF conditions inside tapscript (instead of using separate tap leaves), and also completely unaware of a soft fork activating on the network. The probability is vanishingly small.
More revealing is what critics don't argue. They don't claim that inscriptions are legitimate monetary use that BIP-110 would harm. The fact that the counterarguments have narrowed to edge-case inheritance scenarios is itself an acknowledgment that the inscription abuse is real and not worth defending.
BIP-110 has gone through meaningful peer review. Bugs have been found and fixed, including issues identified by Bitcoin Core contributors. One contributor, Lorinc, found and disclosed an issue professionally. Another researcher identified a separate bug, and the fix was implemented the same evening. This is how open-source development is supposed to work: adversarial review that strengthens the final product.
The fact that people are scrutinizing BIP-110 intensely --- including using AI tools to analyze the code --- is a feature, not a bug. If it were getting no scrutiny while thousands committed to running it, that would be cause for concern. Rigorous review builds justified confidence.
One important misunderstanding in the community debate concerns the role of hash rate. Some have withdrawn support for BIP-110 citing the expectation that it won't receive miner signaling. But this reflects a fundamental confusion about how soft forks work.
Mining is centralized. A handful of pools control the majority of hash rate. If miner signaling determined Bitcoin's rules, two or three entities could impose arbitrary consensus changes --- which is the definition of a 51% attack. The reason miners follow halvings and the 21-million-coin supply cap isn't that they choose to. It's that nodes enforce those rules, and miners who violate them produce blocks that the economic majority rejects.
Soft forks are ultimately about what rules the node-running community decides to enforce. Miner signaling can serve a coordination function, but it is not a source of legitimacy. Looking to hash rate for permission to change Bitcoin's rules gets the governance model exactly backward.
BIP-110 is not a radical proposal. It restricts opcodes within tapscript that have no legitimate monetary use case. It reinstates limits on OP_RETURN that were previously maintained by relay policy. It caps script tree depth at a level that accommodates any realistic spending scenario. And it grandfathers all existing UTXOs to prevent any loss of funds.
What it represents is something more significant: the first serious attempt to acknowledge that Taproot's deployment had unintended consequences and to do something about it. The UTXO set bloat, the inscription abuse, the inversion of scaling technology into an anti-scaling mechanism --- these are real problems that affect every node operator and every user paying transaction fees.
Whether BIP-110 activates or not, the conversation it has forced is valuable. Bitcoin's history shows that winning a debate doesn't mean every decision along the way was correct. Getting the reasoning right matters as much as reaching the right conclusion. BIP-110 makes a clear technical argument: Taproot should be used the way it was designed, and the mechanisms that enable its abuse can be restricted without harming legitimate monetary use. That argument deserves serious engagement on its merits.