BIP-110: The 'Temporary' Soft Fork That Could Block Future Bitcoin Upgrades | Bitcoin Index

A one-year soft fork to clean up “spam” on Bitcoin. Sounds reasonable, right?

Not according to the developers who built Taproot. BIP-110, officially titled “Reduced Data Temporary Softfork,” has sparked one of Bitcoin’s sharpest technical debates in years. The proposal aims to restrict data storage in transactions, but critics warn it would also disable key upgrade mechanisms that Taproot deliberately preserved for future protocol improvements.

Zero miners are signaling support. Developers are calling it reckless. And the proposal’s own author admits it won’t even stop the data storage it claims to target.

Here’s what’s actually going on.

What BIP-110 wants to change

BIP-110 introduces seven new consensus rules that would temporarily restrict:

ScriptPubKey sizes to 34 bytes (except OP_RETURN, capped at 83 bytes)
OP_PUSHDATA payloads and witness stack items to 256 bytes
Spending of undefined witness versions (anything beyond v0 SegWit and v1 Taproot)
Taproot annex usage entirely
Taproot control blocks to 257 bytes, limiting Merkle trees to 128 script leaves
OP_SUCCESS opcodes in Tapscript, even if unexecuted
OP_IF/OP_NOTIF execution in Tapscript

These restrictions would exempt UTXOs created before activation and would automatically expire after one year (roughly 52,416 blocks).

The motivation? From the BIP itself:

“Starting with the ‘inscription’ hack first exploited in 2022, a trend has emerged around embedding arbitrary data into Bitcoin transactions, creating significant unnecessary burdens on node operators and diverting development focus and incentives away from Bitcoin’s fundamental purpose of being sound, permissionless, borderless money.”

Translation: the proposal targets Ordinals inscriptions and similar techniques that embed images, text files, and NFT-like tokens into Bitcoin transactions.

But there’s a problem. A big one.

The upgrade paths Taproot deliberately left open

When Taproot activated in November 2021, it introduced something clever: OP_SUCCESS opcodes.

These are special opcodes in Tapscript that make any script containing them unconditionally valid. Why would you want that? Because it makes future soft forks dramatically easier.

If Bitcoin wants to add new functionality later (say, a covenant opcode like OP_CTV), developers can simply redefine an OP_SUCCESS opcode to enforce new rules. This works as a soft fork (tightening consensus) without breaking existing transactions, because nothing valid today actually uses OP_SUCCESS yet.

As Bitcoin Optech explains:

“[OP_SUCCESS opcodes] unconditionally render the entire script valid to simplify soft fork upgrades.”

Similarly, undefined witness versions (anything beyond witness v0/SegWit and v1/Taproot) and the Taproot annex were left as flexible upgrade hooks for future protocol changes.

BIP-110 disables all of these upgrade mechanisms for one year.

Proponents argue this is fine because “any future upgrade would need more than a year of coordination anyway.” Critics see a dangerous precedent: if “temporary” restrictions become the norm, Bitcoin’s ability to evolve could be permanently constrained.

The BitVM problem

One of the sharpest technical criticisms focuses on the 257-byte limit on Taproot control blocks, which caps Merkle tree depth at 128 script leaves.

For most wallets, that’s plenty. But for BitVM and similar Layer 2 constructions, it’s a deal-breaker.

BitVM is a trust-minimized bridge and computation verification protocol that relies on massive Taproot trees with thousands of scripts. According to a GitHub issue in rust-bitcoin:

“In the BitVM, script sizes are up to 300-400 kilobytes each, and TapTree can consist of thousands of such scripts.”

The BIP acknowledges this tradeoff:

“Limiting Taproot control blocks to 257 bytes directly constrains the size of the on-chain, consensus-enforced script tree. This could complicate or possibly even impede advanced smart contracting like BitVM, which relies on a large number of executable scripts. In the worst case scenario, these use cases may just need to wait until this softfork expires.”

Developers working on BitVM, Ark, and other experimental Bitcoin L2s view this as a red flag: a proposal framed as “temporary cleanup” that restricts cutting-edge research without clear technical necessity.

Zero miner support and chain split risk

BIP-110 uses a modified BIP9 deployment with a 55% miner signaling threshold instead of the standard 95%. It also includes User-Activated Soft Fork (UASF) mechanics: blocks that don’t signal will be rejected as invalid once mandatory signaling begins in August 2026.

The problem? As of late March 2026, zero miners are signaling support for BIP-110. Not a single block.

Jameson Lopp notes in his analysis:

“BIP-110’s activation relies on a low 55% miner signaling threshold for a User-Activated Soft Fork (UASF). This greatly increases the chances of a ‘chain split’ in which there are 2 competing chains vying to be ‘the real Bitcoin.’”

F2Pool, controlling roughly 10% of hashrate, has publicly stated: “No way we’ll signal BIP-110.”

Why would miners oppose it? Simple economics: restricting data transactions means restricting fee revenue. Miners have no financial incentive to voluntarily reduce their income.

The lack of economic support is also telling. Unlike the 2017 SegWit2X fork, where exchanges offered futures markets, no major exchange has done so for BIP-110. The only available market is a small Lightning-based prediction platform, Predyx, where as of Lopp’s writing, BIP-110 had a 98% chance of failing to become the chain with the most cumulative proof-of-work.

If activation proceeds without majority hashrate, the result would be a chain split. At roughly 1% hashrate (if only Ocean Mining signals), the minority chain would produce 1–2 blocks per day, taking nearly three years to reach the next difficulty adjustment.

”It won’t even work”

Perhaps the most damning criticism is that BIP-110 won’t stop data embedding.

Developer Peter Todd demonstrated this by embedding the entire text of BIP-110 into a BIP-110-compliant transaction (transaction ID: 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c).

His method: split the data across 31 small inputs, then consolidate into a zero-length OP_RETURN. Visually, it looks like a normal consolidation transaction. The data is non-contiguous but easily reassembled by third-party software.

Lopp puts it bluntly:

“This BIP just kicks off a never-ending game of cat and mouse and was immediately proven ineffective.”

Even BIP-110’s author concedes the point. When asked if the proposal stops data storage, Dathon Ohm replied:

“This proposal’s goal is not to block all methods of arbitrary data insertion, just the most commonly abused ones.”

The confiscation risk

Although BIP-110 exempts UTXOs created before activation, it does not exempt pre-signed transactions confirmed during the restriction period.

Bitcoin Core developer Greg Maxwell raised this concern:

“There likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren’t.”

This affects:

Lightning Network HTLCs and other time-locked contracts
Vault protocols with pre-signed emergency exits
Experimental covenant constructions using Miniscript with OP_IF
Any multisig or DLC setup with pre-signed fallback paths

The BIP argues the risk is low because funds can usually be spent via other paths (keypath or alternate Tapleaves). But developers point out that Lightning-like protocols using n-of-n multisig to simulate covenants could see funds confiscated even with the UTXO height whitelist.

Nothing more permanent than a temporary solution

BIP-110 is marketed as temporary to sidestep objections about breaking functionality. The logic: “Even if this causes problems, they only last a year.”

But after one year, the community will need to either extend the restrictions, activate “something more permanent and less blunt,” or let them expire. This creates two rule sets that wallets, libraries, and contracts must reason about (during vs. after), adding complexity and uncertainty.

Lopp suspects the “temporary” framing is tactical:

“No one I’ve spoken with believes that the puritanical fanatics behind the BIP-110 proposal would be content to simply let it expire after a year.”

Who’s really behind this?

The proposal is attributed to Dathon Ohm, a pseudonymous account created in late 2025. However, Greg Maxwell disclosed that he received meeting minutes indicating Ocean Mining was the true author and planned to present it under a false identity.

Ocean Mining is a pool co-founded by Luke Dashjr, the maintainer of Bitcoin Knots (a fork of Bitcoin Core with stricter relay policies). Ocean has publicly advocated for filtering “spam” transactions and peaked at roughly 2% network hashrate in early 2025 before dropping to around 1%.

When confronted, Dathon Ohm replied:

“Though I am in direct communication with some Ocean employees (and the BIP was originally drafted by one of them), I am not affiliated with Ocean in any way. I am just a Bitcoin dev who is concerned about the implications of Core 30 having been released and gaining adoption.”

Developer reaction

The proposal has drawn near-universal opposition from Bitcoin Core contributors and prominent developers:

Jameson Lopp: “BIP-110 is a reckless gamble that prioritizes short-term ‘purity’ over Bitcoin’s long-term resilience.”
Greg Maxwell: “I think your proposal continues to have no serious prospect of activation, and should it activate in any form it will just be forked against.”
Peter Todd: “Clearly, this approach is ineffective.”

Even the reference implementation has been criticized for quality. Bitcoin Core developer Michael Ford (fanquake) tweeted that functional tests were failing, fuzz tests were failing, tests were stubbed out with early returns, and release binaries were being uploaded before Guix signatures were ready.

What happens next

As of March 2026, BIP-110 remains in “Draft” status with zero miner support, no economic backing, widespread developer opposition, and a mandatory activation deadline at block 965,664 (roughly September 2026).

Lopp’s prediction:

“BIP-110 will NOT reach the 55% activation threshold and thus nothing of consequence will occur until block 961,632 in early August. At that point, anyone running BIP-110 code will find their node forked off the Bitcoin network.”

The deeper question: what is “spam”?

Underneath the technical arguments is a fundamental philosophical split:

One camp believes Bitcoin’s purpose is purely monetary, that arbitrary data is “spam” that harms the network, and that protocol rules should actively discourage non-monetary use.

The other camp believes Bitcoin is programmable money (which is what makes it valuable), that “spam” is subjective and impossible to define precisely, and that censorship resistance requires neutrality toward transaction content.

Developer Chris Riley summarized the problem:

“From what I have read so far there is not a clear, quantifiable, agreed-upon set of criteria defining what constitutes ‘spam.’ […] The inability to create a precise, objective definition makes such rules essentially impossible to specify or enforce consistently, leading to endless whack-a-mole changes.”

This isn’t just about BIP-110. It’s about whether Bitcoin’s governance model can handle ideologically-driven factions pushing consensus changes without technical or economic consensus.

The proposal’s likely failure isn’t a bug. It’s the system working as designed.

Sources

Data as of March 23, 2026.