BIP 110

Time to Look at BIP 110

When people go to war, almost no one thinks of themselves as the bad guy. A new ideological war has been unfolding in Bitcoin, and the problem is that both sides are right.

The controversy centers on BIP 110. If you have followed the online debate, you have likely encountered two irreconcilable narratives. One side describes an immune response: the network defending its purpose as money against parasitic acts. The other describes a coercive minority takeover that breaks legitimate use cases and risks a chain split. Having listened to both camps for the better part of a year, I believe this battle of ideals is much closer than people realize. However, one side edges out a victory in my book, and after sufficient due diligence, I want to share that perspective.

Before going further, I must acknowledge the intellectual heavyweights on both sides of the aisle, most of whom I deeply respect. Like any conflict, there are tragedies; I have lost respect for or drifted from people I once looked up to in this one. But a battle of ideas is about the ideas themselves, not the people presenting them. This is about securing the best future for Bitcoin, and regardless of the outcome, I believe Bitcoin will emerge stronger.

So, let us examine this properly.

What BIP 110 Actually Does

BIP 110 is a temporary consensus soft fork lasting 52,416 blocks, or roughly one year. During this window, enforcing nodes treat any block containing a rule-violating transaction as invalid. When the window closes, every restriction automatically lifts.

The proposal introduces seven specific constraints:

• Rule 1: Caps new transaction outputs. Any new output script larger than 34 bytes becomes invalid, excepting those beginning with OP_RETURN (up to 83 bytes). Since modern outputs are just short hashes committing to future spending conditions, 34 bytes accommodates all modern address types, including SegWit and Taproot. The 83-byte OP_RETURN exception restores a decade-old limit removed by Bitcoin Core version 30—the decision that ignited this entire war. This rule shuts down oversized data outputs and the older trick of stuffing data into fake addresses.
• Rule 2: Limits contiguous data pushes. Single data pushes or witness items larger than 256 bytes become invalid. Actual scripts defining spending conditions (e.g., redeemScripts, witness scripts, and Tapleaf scripts) are exempt because they are code, not payload. The 256-byte limit comfortably accommodates monetary transaction signatures while preventing compressed images from fitting in a single push.
• Rules 3 & 4: Secures undefined spaces. Spending from undefined witness versions and transactions carrying a Taproot annex become invalid. Because these areas are reserved for future upgrades, they currently accept unlimited data. BIP 110 temporarily boards them up, reasoning that no legitimate use currently exists and any actual upgrade would take longer than a year to coordinate.
• Rule 5: Caps Taproot control blocks. Control blocks—proofs that a script belongs to a Taproot output’s tree—are capped at 257 bytes, limiting script trees to a depth of seven (128 script leaves). While ample for nearly every wallet on earth, it creates a hard ceiling for frontier protocols like BitVM, forcing more thoughtful engineering.
• Rule 6: Invalidates OP_SUCCESS opcodes. Any Tapscript containing an OP_SUCCESS opcode—Taproot’s upgrade mechanism—is invalid, even if it never executes. Under current rules, any script containing one is automatically valid, making them useful for soft forks but a wide-open door for arbitrary data today.
• Rule 7: Invalidates OP_IF / OP_NOTIF executions. This rule directly targets the “inscription envelope” (OP_FALSE OP_IF <data> OP_ENDIF) exploited by Ordinals to shovel images into witness data wrapped in branches that never run. While conditional logic is technically redundant in Taproot, this rule collides hardest with existing tooling.

Two overarching design features frame these rules:

1. Grandfathering: Every UTXO confirmed before activation is permanently exempt, spending exactly as it always did regardless of its script.
2. Expiration: The ruleset expires on its own after one year unless the network affirmatively renews it.

Mechanically, BIP 110 activates via a modified deployment with a 55% miner signaling threshold, rather than the traditional 95%. If miners fail to reach this, a mandatory signaling window opens in early August 2026, during which enforcing nodes will reject non-signaling blocks. This guarantees activation from the perspective of enforcing nodes and sets a fascinating precedent for a User-Resisted Soft Fork (URSF). If a contentious and truly malevolent fork appears in the future, the network now knows the best way to respond to block it.

The Edge Case BIP 110 Breaks

There are known tradeoffs and issues of how BIP 110 moves forward and is worth understanding on a technical level.

• Pre-signed, Timelocked Transactions: Grandfathering protects existing UTXOs but cannot protect transaction chains signed in advance, such as an inheritance vault designed to remain unmodifiable until a future date. If such a transaction confirms during the enforcement year and violates a new rule (like the 34-byte rule or spending through a leaf below depth seven), the network will reject it. The keys to fix it may be lost or destroyed. While no production case has surfaced, pre-signed transactions are invisible until broadcast, making it impossible to prove the affected set is entirely empty.
• Miniscript Compilers: Today’s Miniscript compilers routinely emit Tapleaves containing OP_IF for complex custody policies (e.g., “two of three now, or a recovery key after a year”). Under Rule 7, these become unspendable for post-activation coins. While workarounds exist by decomposing branches into separate leaves, tooling must be rewritten first, imposing real transition costs on complex custody.
• Pay-to-PubKey (P2PK): A compressed key P2PK output is 35 bytes—one byte over the new cap. Though nothing modern uses P2PK and existing coins are grandfathered, it remains the original transaction type used by Satoshi. Bitcoin has never adopted a consensus rule that outright invalidates the creation of its original transaction style. I actually am not a fan of this limitation.
• Upgrade Hooks: Rules 3, 4, and 6 disable Bitcoin’s upgrade machinery (like OP_SUCCESS, designed to make future soft forks confiscation-safe) for a year. Ironically, a proposal defending Bitcoin’s integrity temporarily disables the very tools built to protect it, though proponents fairly argue that no real upgrade could successfully coordinate within a year anyway.

Standard transactions (P2PKH, P2SH, native SegWit, ordinary Taproot, and Lightning) comply fully and remain untouched. Furthermore, existing coins are exempt without any deadline, and the entire ruleset self-destructs after a year. This temporary measure is mostly a demonstration of what the network demands for Bitcoin.

The strongest technical argument against BIP 110 asserts that spam cannot be stopped. Technically competent actors can embed data regardless of these rules. And, this is true. Peter Todd demonstrated this by embedding the full text of BIP 110 into a compliant transaction, and Runes—the highest-volume token protocol on Bitcoin—already fits perfectly inside an 83-byte OP_RETURN and sails through untouched.

Squeezing data limits also risks a second-order effect: UTXO bloat. Determined spammers may not give up; instead, they spread payloads across thousands of dust-holding outputs. Unlike OP_RETURN data, which nodes can prune, unspent outputs live in the UTXO set—the network’s working memory that every node must keep fast and cannot discard. Even an address holding next to nothing must be tracked forever. This is exactly why OP_RETURN was created in 2014 as a designated “trash can” to lure data away from fake addresses. The technical crowd accurately argues that building an ideal trash can is preferable to encouraging UTXO bloat.

However, the purely technical argument misses the mark and falls short of the bigger picture.

The Value of Constraint

Stability is born from limits, and meaning is born from consequence. Counter-intuitively, freedom requires limits because a life without constraint dissolves into meaninglessness.

This matters deeply in shared systems. When everyone must play on the same board, fairness depends on stable rules; the moment the board tilts for one player, everyone else is affected. Large systems separate decision from consequence, hiding costs in complexity or delaying them into the future. Power hates constraint and often arrives speaking the language of care, arguing that old boundaries are too rigid or crises are too urgent. Eventually, the system forgets that rules were placed there to protect everyone from power.

Because money is the shared board beneath every other game, sound money is a tool for progress. If the measuring stick can be stretched by those closest to power, interactions become less honest. Constraint here becomes more than a political idea; it becomes a moral one. Rules that frustrate us and slow us down are the very same rules that protect the weak from the certain that wants to tilt the board.

Developers forgot this wisdom when they implemented Taproot. To enable complex smart contracts and simplify validation, they removed the strict 10,000-byte script size limit that SegWit had previously established. They assumed economic irrationality would prevent abuse, but they were wrong. The removed limit, combined with the SegWit witness discount, created an arbitrage opportunity. The inscription angle (OP_FALSE OP_IF trick) allowed anyone to stuff megabytes of data into a single Taproot transaction at a fraction of the normal fee rate.

This wasn’t a brilliant use case as the name Taproot Wizards would imply; it was an exploit of removed constraints that birthed the spam-as-a-service industry inside Bitcoin. Tens of millions of dollars in venture capital were raised to abstract away technical complexity so that the least competent and respectful users could do whatever they pleased, so long as they paid the tollmasters.

Enabling bad behavior is not a strategy for incentivizing good behavior. Trash can logic assumes spam demand is fixed, but demand responds to friction, cost, and signal. Reintroducing base-layer constraints naturally pushes data-heavy use cases to higher layers or other blockchains, substantially better locations than on base layer Bitcoin. Neutral systems can still recognize bad behavior; I will defend freedom of speech for everyone, but still know justice seeing someone being a jerk face consequences for their actions.

Historically, spamming Bitcoin required real technical competency, which acted as an unappreciated filter for decency. The best martial artists are usually the last to take action. They understand the damage they can impose. Just because they can doesn’t mean they should. Just because a competent user can spam doesn’t mean they should. The OP_RETURN expansion created a perverse incentive where companies built businesses entirely around abstracting that complexity away. Spam-as-a-service is not a business model Bitcoin should tolerate, and we should take any reasonable action to thwart it. Bitcoin deserves to be treated better.

A Battle of Ideals

Judged purely through a technical lens as a spam filter, BIP 110 is somewhat weak. No solution is perfect. But judged as a representation of displeasure against the spam-as-a-service industry, it is aimed exactly right. The threat was never the competent individual; it is the VC-funded companies and NFT marketplace raising absurd figures on the premise that Bitcoin’s node operators will store their content forever, for free, without permission. BIP 110’s real victory is the demonstration that a tragedy of the commons will not be tolerated so easily here.

The other side is defending a vital principle, too: that your use of Bitcoin should not be subject to a vote, and that money for enemies means defending usage you find distasteful. Both sides are defending the same value—credible neutrality—but disagreeing about what threatens it more. One side sees neutrality dying by capture through spam and developer drift; the other sees it dying by precedent of censorship. Almost no one in this war thinks they are the bad guys, and genuinely, almost no one is—though a few suspicious actors have emerged that are worthy of future pause.

For me, the philosophical argument carries more weight. The edge cases BIP 110 breaks are narrow, disclosed, and temporary. The incentive structure it confronts is broad, compounding, and permanent if left alone. A Bitcoin that cannot express displeasure to spam-as-a-service is a Bitcoin whose priorities will eventually be set by the businesses monetizing goodwill against itself.

Part of what makes Bitcoin uniquely beautiful is that true consensus gives everyone a real voice. I don’t pretend to know which future arrives, but my node will be signaling for BIP 110 with clear eyes about what that means for me. I know I will be in the minority on this one, but standing up for what I believe is right in the face of the many is exactly where Bitcoin began for me. I’m in familiar territory.

The terrain of this emerging battle of ideals is unfolding. Bitcoin has survived many civil wars that looked existential from the inside, but every battle left the network more resilient. Whichever side prevails in August, the fact that a decentralized network of node runners is still willing to go to war over what they believe Bitcoin should be is actually a really beautiful thing. Even if BIP 110 only ends up being a small group expressing discontent, the fact that people are looking is important. BIP 110 is an important social voice demanding better for Bitcoin. BIP 110 is a reduction, and thoughtful constraint. There is wisdom in constraint.

That is why I am running BIP 110.

BIP 110: The Network Answered Editorial Follow-up

June 12th 2026·Block 962,200·$64,048.58

When I wrote about BIP 110 a few weeks ago, I said something that I still believe: the fact that Bitcoiners were willing to fight over the purpose of their money was a beautiful thing.

I also said I would signal my node for BIP 110. I knew I would be in the minority. I did not expect the outcome to remain ambiguous for long. I thought a small but meaningful group of people might show up, make their displeasure known, and then we would see where the network wanted to go.

For a brief moment, that is exactly what happened.

When the mandatory-signaling period began at block 961,632, the first non-signaling block from AntPool continued on the dominant chain. An enforcing BIP 110 block appeared on the other side. Then came the strange few blocks where you could watch both paths form in real time. F2Pool extended the dominant chain. OCEAN produced another block on the non-BIP 110 side.

For a minute, it was honestly fun to watch. It felt like a living demonstration of what Bitcoin is supposed to be: people choosing which rules they are willing to accept.

I want to give OCEAN credit. Pooled mining has a way of obscuring who is really making a choice. A pool signals, the block says a pool’s name, and the rest of the world can forget that a large amount of individual hashpower sits behind that label. OCEAN made the BIP 110 question more visible to miners and gave people a clearer path to express where they stood. I think the industry should keep moving in that direction. Miners should have meaningful representation when pools take positions on controversial changes.

BIP 110 did not achieve the coordination required to become Bitcoin’s shared rule set. The enforcing branch quickly lost ground and stalled while the main chain kept producing blocks normally.

The market spoke.

A group can be right to express displeasure without having earned the ability to impose a new consensus rule on everyone else. That is the lesson I take from BIP 110.

A real group of people showed up to say that they do not like spam on Bitcoin. The spam-as-a-service industry should understand that there are people on this network who see its business model as parasitic. They are willing to do work, run software, take social heat, and bear real cost to say so. That is not nothing. In fact, I think it may be the most enduring part of this entire episode.

But a social message is different from consensus.

I will no longer run my node against the chain that the overwhelming network has chosen. Bitcoin is the most-work chain under the rules that people broadly coordinate around. That principle matters even when the outcome disappoints me. Bitcoin has to remain a representation of consensus. That is what makes it special.

For me, continuing to follow a fork after the network has given its answer would undermine the most important part of what Bitcoin is.

The original BIP 110 essay argued that there is wisdom in constraint. I still believe that. We should not be so quick to expand capability on the base chain. Taproot has shown how quickly an unintended consequence can become an industry.

But this episode also reinforced another kind of restraint: once the network has given a clear answer, we have to have the discipline to accept it.

BIP 110 did not become consensus. The social signal remains. Both matter.