BIP-110: Should Bitcoin Filter Data? Anatomy of a Consensus Battle

In October 2025, a single configuration line lit the fuse. With its version 30, Bitcoin Core — the most widely used node software — raised the data size allowed in an OP_RETURN output from 83 bytes to 100,000 bytes.¹ To its developers, that simply acknowledged reality: refusing to relay transactions that miners include anyway only pushes users toward side channels. To its opponents, it flung the door open to non-financial data “spam.”

BIP-110 is that camp’s counter-strike. Proposed in late 2025, it is a temporary soft fork that re-caps, at the consensus level, how much arbitrary data a transaction can carry. Behind the technical question — how many bytes, which scripts — lurks a far heavier one, the one that truly divides Bitcoin: who is allowed to change its rules?

This article takes no side. It explains what BIP-110 changes, how it activates, and why it triggers such a fight — both camps laid out, for you to make up your own mind.

Where the fight comes from

The problem: data that doesn’t belong there?

Bitcoin is first and foremost a way to move value. But its blockchain is also, technically, a storage space: you can slip in data that has nothing monetary about it. The debate isn’t new, but it changed scale in early 2023 with the Ordinals protocol and its “inscriptions,” which let people write images, text and BRC-20 “tokens” directly into the witness part of Taproot transactions.

The purists’ complaint: these uses clog the blockchain, push fees up for payments, and above all inflate the UTXO set — the memory that every node must keep to validate transactions. The larger that memory grows, the costlier it becomes to run a node, and the more decentralization — the ability for anyone to verify the network themselves — erodes.

The counter-argument, just as old: a transaction that pays the market’s fees has the right to exist. Filtering by content means subjectively deciding what counts as a “good” or “bad” use of Bitcoin — a slope many see as contrary to its permissionless nature.

The spark: Core lifts the limit

For years, Bitcoin Core capped an OP_RETURN’s data at roughly 80 bytes by default. That was never a consensus rule, only a relay policy — a convention about what the software agrees to propagate. In 2025, after a long debate, Core’s maintainers decided to lift it in v30, raising the default cap to 100,000 bytes.¹

That choice crystallized a rivalry that had been simmering between two node implementations:

• Bitcoin Core, the historical and majority implementation, which loosened its policy;
• Bitcoin Knots, the stricter fork maintained by Luke Dashjr, which filters non-financial data more aggressively.

BIP-110 was born in this context, and it is Knots that ships its support. The “Core versus Knots” war is the backdrop to the whole affair.

What BIP-110 changes technically

Officially, BIP-110 is called the “Reduced Data Temporary Softfork.” It was published on 3 December 2025 under the pseudonym Dathon Ohm, with Luke Dashjr credited for the drafting and advice.² Its exact authorship is, in fact, disputed within the community.

Its abstract is explicit: “temporarily limit the size of data fields at the consensus level, in order to correct distorted incentives […] and to refocus priorities on improving Bitcoin as money.”²

Concretely, it adds seven rules that make certain constructions invalid — on newly created outputs after activation:

1. An output whose script is larger than 34 bytes becomes invalid (except OP_RETURN, capped at 83 bytes). 34 bytes is exactly the size of common addresses (Taproot, SegWit): normal payments pass, “loaded” scripts don’t.
2. Data pushes (OP_PUSHDATA) and witness items larger than 256 bytes become invalid (down from 520), except a P2SH redeemScript.
3. Spending an as-yet-undefined witness or tapleaf version becomes invalid (creating one stays allowed).
4. Transactions using the Taproot annex (a field currently unused) are rejected.
5. A Taproot control block larger than 257 bytes becomes invalid — capping the script tree at 128 leaves.
6. Tapscripts containing an OP_SUCCESS opcode (reserved for future upgrades) become invalid.
7. Tapscripts executing OP_IF / OP_NOTIF (conditional branches) are rejected.

The last four rules mostly aim to constrain the elaborate Taproot scripts used to package large blobs of data. No need to memorize each line: the overall idea is to put a low cap back on what a transaction can carry as data, while leaving monetary uses untouched.

The safeguard: grandfathering

One point reassures everyone, opponents included: nothing is frozen. Every rule exempts inputs that spend coins created before the activation date. In other words, no existing UTXO suddenly becomes unspendable, whatever form it was created in.² The transition happens without breaking what already exists.

And because the soft-fork is temporary, its restrictions expire automatically about a year after they take effect. Luke Dashjr himself frames it as a patch: “This isn’t intended to be an ideal solution, only good enough and super simple to buy time to design a long term solution.”³

How it activates — and why that’s the real issue

A consensus change can’t be imposed from above. Traditionally, you use miner signaling: miners indicate in blocks that they’re ready to enforce the new rule, and beyond a threshold it locks in and then activates.

The controversy is buried in BIP-110’s activation parameters:²

• A 55% threshold (1,109 of 2,016 blocks) for early lock-in — well below the 95% demanded by historical soft-forks like SegWit or Taproot.
• Signaling starts on 1 December 2025, with a maximum activation height at block 965,664 (around September 2026).
• An active duration of 52,416 blocks, roughly a year, after which the rules expire.

That lowered threshold isn’t a detail. It moves BIP-110 closer to the UASF logic — the idea that it’s the users running a node, not the miners, who ultimately decide the rules. The founding precedent is BIP-148, in 2017, which unblocked SegWit’s activation by threatening to reject the blocks of resisting miners.

This is exactly where the technical debate becomes a debate about power: from what level of agreement does anyone have the right to change the rules everyone must follow?

Stakes and risks: both camps

For BIP-110

• Preserve Bitcoin as money. Refocus block space on payments rather than on arbitrary data that drives fees up.
• Protect decentralization. Contain the growth of the UTXO set and the cost of a node, so that verifying the network stays within reach of the many.
• A minimal, reversible intervention. A temporary soft-fork, with grandfathering: nothing is frozen, nothing is broken, and it turns itself off.

Luke Dashjr frames the urgency in stark terms: in his view, without this safeguard, “if BIP110 fails, Bitcoin fails with it,” the network risking, as he sees it, becoming indistinguishable from a central bank digital currency.⁴

Against BIP-110

• A dangerous precedent. Filtering by the content of a transaction means subjectively deciding what a legitimate use is — a slide toward the censorship Bitcoin is supposed to make impossible.
• Invalidating fee-paying transactions. Michael Saylor sums up the objection: the proposal “turns a spam dispute into a consensus change that would invalidate some currently valid, fee-paying transactions.”⁵
• The risk of a split. Activating a contested change without broad agreement raises the threat of a chain split — two chains, two coins — as during the block-size wars of 2017. Both Michael Saylor and Adam Back are among the notable opponents.⁵

What the outcome already tells us

As these lines are written, the verdict clearly tilts one way: miner signaling is near zero, far from the required 55%, and the deadline is approaching.⁶ Whatever the outcome, the episode will have shown one thing: on Bitcoin, no minority, however motivated, can impose a rule change without winning broad buy-in — miners, nodes, businesses, users. It’s slow, it’s frustrating for those who want to act fast, but it’s precisely what makes Bitcoin’s rules hard to change… by anyone.

Key takeaways

• BIP-110 is a temporary soft-fork that re-caps arbitrary data in Bitcoin transactions: outputs ≤ 34 bytes, OP_RETURN ≤ 83 bytes, pushes ≤ 256 bytes, plus several restrictions on Taproot scripts.
• It was born as a pushback against Bitcoin Core v30 (October 2025), which had raised OP_RETURN’s limit from 83 to 100,000 bytes — at the heart of the “Core versus Knots” rivalry.
• Grandfathering protects the existing set: no coin created before activation becomes unspendable, and the rules expire after ~1 year.
• Its 55% activation threshold (versus the usual 95%) shifts the debate onto governance ground: who decides Bitcoin’s rules?
• By mid-2026, activation is failing for lack of miner support — illustrating, whatever your view on the substance, the very high level of consensus required to change Bitcoin.