BIP 110 Marked EXPIRED: What It Means When Bitcoin Soft Fork Proposals Die | Bitcoin Index

On March 5, 2026, at 3:38 AM UTC, Bitcoin developer Luke Dashjr merged a small pull request into the Bitcoin BIPs repository. The commit updated BIP 110’s specification to add an “EXPIRED” terminal state to its deployment state machine. No fanfare. No announcement. Just a quiet housekeeping merge that brings documentation in line with what the code already does.

But this tiny update tells a much bigger story about how Bitcoin deals with controversial proposals, what happens when grassroots activism runs into the wall of social consensus, and why some soft forks succeed while others quietly fade into irrelevance.

Let’s talk about what BIP 110 actually is, why it’s effectively dead in the water, and what this teaches us about Bitcoin’s immune system.

First, let’s correct the record

The proposal description for this post said BIP 110 is about reducing coinbase maturity from 100 blocks to 50. That’s completely wrong. BIP 110 has nothing to do with block rewards or mining payouts.

BIP 110 is the “Reduced Data Temporary Softfork,” a controversial attempt to limit arbitrary data storage on Bitcoin’s blockchain. It’s a direct response to the explosion of Ordinals, inscriptions, and other protocols that use Bitcoin to store images, text, and other data.

The proposal includes seven consensus rule changes designed to restrict Bitcoin’s ability to carry arbitrary data for roughly one year, including ScriptPubKey size limits, OP_PUSHDATA payload caps, Taproot annex prohibitions, and restoring the old 83-byte OP_RETURN limit that Bitcoin Core v30 removed.

So when you see “BIP 110,” think “the anti-Ordinals proposal,” not anything about mining rewards.

What actually changed on March 5

The March 5 pull request didn’t declare BIP 110 dead. It updated the written specification to match what the reference implementation already does.

Here’s the technical detail: Before the update, BIP 110’s spec said the deployment would stay in ACTIVE state after its duration expired, but the rules would just stop being enforced. After the update, the spec now includes EXPIRED as an explicit terminal state that the deployment transitions to after the active duration ends.

The code already had this EXPIRED state. The documentation just needed to catch up.

This matters because temporary soft forks (like BIP 110) are a relatively new pattern in Bitcoin. Most soft forks are permanent. When SegWit activated, it stayed active forever. BIP 110 proposed something different: consensus rules that would automatically expire after 52,416 blocks (roughly one year).

The EXPIRED state is how the deployment formally ends. It’s distinct from FAILED, which means a deployment never activated in the first place.

But here’s the thing: BIP 110 isn’t going to reach EXPIRED because it’s almost certainly never going to activate at all.

Why BIP 110 is dead in the water

As of March 5, 2026, Bitcoin is at block height 939,442. BIP 110’s maximum activation height is 965,664, roughly 182 days away. For the proposal to activate, one of two things needs to happen:

Miner signaling: 55% of miners signal support over a retarget period (1,109 out of 2,016 blocks)
UASF lock-in: Overwhelming economic node support forces miners to comply at the mandatory signaling period (blocks 961,632 to 963,647)

Neither is happening. Miner support is effectively zero. Node adoption is minimal, mostly limited to Bitcoin Knots users and a small group of vocal anti-Ordinals activists. The release client that Dathon Ohm (BIP 110’s pseudonymous author) shipped in December 2025 had multiple failed tests, including tests designed to verify whether the UASF logic works correctly.

Developer Rob Hamilton documented the issues in detail: “It’s very possible [the client] could still have consensus bugs. It’s important to note that the tests [used] to verify [whether] the UASF logic was applied correctly were failing [and] were written by Dathon himself.”

When consensus-critical code ships with failing tests, credibility evaporates. Comparisons to the failed SegWit2x attempt in 2017 started immediately.

The UASF gambit

BIP 110’s activation mechanism is designed as a User-Activated Soft Fork (UASF), similar to BIP 148 that helped push SegWit over the finish line in 2017. The theory is that if enough economic nodes run BIP 110 clients, miners will be forced to follow the new rules or risk mining blocks that the economic majority rejects.

UASF worked in 2017 because:

SegWit had broad technical consensus among developers
Economic support was overwhelming (exchanges, businesses, users)
Miners faced existential risk by not complying

BIP 110 has none of these conditions. Without overwhelming economic support, UASF becomes a game of chicken that risks catastrophic chain splits. Bitcoin Core maintainers haven’t endorsed it. Major exchanges aren’t running it. The broader community is deeply divided, not rallied behind a common cause.

This is Bitcoin’s governance in action. There’s no formal voting mechanism, no committee that declares proposals valid or invalid. Social consensus is the gatekeeper, and BIP 110 doesn’t have it.

The ideological battle underneath

BIP 110 isn’t just a technical proposal. It’s a referendum on what Bitcoin is for.

The pro-BIP-110 argument: Bitcoin is money, not data storage. Protocols like Ordinals and Stamps are parasitic uses that burden Bitcoin’s monetary function with unnecessary costs. If Bitcoin officially supports unlimited data storage (via Core v30’s removal of the OP_RETURN cap), node operators could face legal liability for storing and distributing hazardous content. Data storage creates permanent UTXO set bloat, increasing hardware requirements and reducing decentralization.

The anti-BIP-110 argument: Bitcoin should remain neutral about how data is interpreted or used, as long as it follows the rules and pays fees. Content-based restrictions violate censorship resistance and set a dangerous precedent. Developer Peter Todd demonstrated that BIP 110’s restrictions can be easily evaded by encoding data across multiple outputs. The proposal’s rushed timeline (February 2026 activation, giving only three months for coordination) violated the careful, deliberate approach Bitcoin normally takes with consensus changes.

I keep coming back to Greg Maxwell’s warning about pre-signed transactions. If BIP 110 restricted features that existing smart contracts rely on, some Bitcoin could become unspendable. That’s confiscation by another name, and it cuts against everything Bitcoin stands for.

But I also understand the frustration of node operators who see their bandwidth and storage costs balloon because people want to store JPEGs on the blockchain. This isn’t a simple good-vs-evil story. It’s a genuine tension between competing values.

Lessons for future soft forks

BIP 110’s trajectory (or lack thereof) teaches several lessons:

Code quality is non-negotiable. A buggy activation client doomed BIP 110’s credibility before it started. In consensus-critical software, failed tests are disqualifying.

UASF is a high-risk governance tool. It worked once, in 2017, under very specific conditions. Treating it as a general-purpose activation mechanism is dangerous.

Emergency framing can backfire. BIP 110 framed Ordinals as an existential crisis requiring rushed action. This precedent is dangerous. Future groups could weaponize “emergency” framing to bypass normal review processes.

Temporary soft forks have unique challenges. BIP 110’s one-year duration was meant to limit downside risk, but it also complicated things. What happens to smart contracts designed around features that might disappear in a year? BitVM developers worried about Taptree depth limits affecting their work.

Social consensus still matters most. Bitcoin’s governance has no formal mechanisms, but informal agreement remains the real gatekeeper. Any sufficiently motivated group can get a BIP number, write code, and attempt activation. Actually achieving consensus is the hard part.

What this means for Bitcoin

The March 5 EXPIRED update is a footnote, but the BIP 110 story is a chapter in Bitcoin’s ongoing evolution. It’s a case study in how Bitcoin’s immune system responds to controversial changes.

Bitcoin didn’t need a formal rejection process. No committee voted BIP 110 down. No authority declared it invalid. It just failed to gather the overwhelming support needed for activation. That’s the system working as designed.

The Ordinals debate isn’t over. The question of whether Bitcoin is purely money or whether it supports arbitrary data uses will come back in future proposals. But BIP 110’s failure sends a signal: rushed, divisive changes without broad technical consensus don’t fly, even when they’re dressed up as urgent responses to perceived threats.

Bitcoin remains hard to change. That’s a feature, not a bug.

Sources

Published March 5, 2026