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 was that camp’s counter-strike. Proposed in late 2025, it was a temporary soft fork meant to re-cap, at the consensus level, how much arbitrary data a transaction can carry. Behind the technical question — how many bytes, which scripts — lurked 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 changed, how it was meant to activate, why it triggered such a fight — and how that fight ended.

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 was meant to activate — and why that was the real issue

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

BIP-110 reused that mechanism, with three far-reaching departures:²

• A 55% threshold (1,109 blocks out of 2,016) for lock-in — well below the 95% required for historical soft-forks such as SegWit or Taproot.
• No timeout. A standard deployment that misses its threshold simply fails, and nothing changes. This one had no such exit: it was to activate by block 965,664 (early September 2026) at the latest, with or without the miners.
• A mandatory signaling period, from block 961,632 to block 963,647 (August 2026). During that window, BIP-110 nodes rejected any block that did not signal support.

That last point changes everything. If miners didn’t follow, BIP-110 could not “fail cleanly”: its nodes would refuse blocks from almost the entire network, and so end up alone on their own branch. That’s the UASF logic — the idea that users running a node, not miners, ultimately decide the rules. The founding precedent is BIP-148 in 2017, which unblocked SegWit’s activation by threatening to reject recalcitrant miners’ blocks. But BIP-148 was backed by a large share of the economy; the question was whether BIP-110 would be.

That’s where the technical debate becomes a debate about power: at what level of agreement is one entitled to change the rules everyone must follow — and what happens when a minority decides to enforce them alone?

What happened

A single pool signals

Signaling stayed marginal to the end. Over the last 2,016-block period before the mandatory window (blocks 959,616 to 961,631), 51 blocks signaled support, or 2.53% — against 55% required.⁴ And all 51 came from a single pool: OCEAN, co-founded by Luke Dashjr, the proposal’s driving force. You can check it on-chain: OCEAN mined 69 blocks over the period, 51 of which signaled the BIP-110 bit. Even at OCEAN, then, over a quarter of blocks did not signal — its miners pick their own block templates, and some declined.

On 8 August, the chain splits

On 8 August 2026 at 19:35 UTC, AntPool mines block 961,632, the first of the mandatory window, without signaling BIP-110.⁵ The rest of the network accepts it. BIP-110 nodes reject it. At that precise moment the chain splits in two: on one side Bitcoin, which carries on; on the other, a minority branch that only accepts signaling blocks.

On that branch, a group of miners called Roughnecks, working through OCEAN, mines a competing block 961,632, then a 961,633. Then nothing, or nearly. Eight hours later, the BIP-110 branch is still at two blocks; the main chain has added 48.⁵

Why did the branch stall so fast? For a purely mechanical reason, detailed in Bitcoin mining, in detail : difficulty. A branch that splits off inherits the whole chain’s difficulty, calibrated for colossal computing power, and can only readjust it after 2,016 blocks. Even if all the power that signaled (2.53%) had followed, the branch would have found a block every six and a half hours on average, and taken over a year and a half to reach its first adjustment. With even less power, it froze.

OCEAN backs down

The pool that carried the proposal had to manage the fallout. A configuration error had sent part of its hashrate to the BIP-110 branch for about 18 hours, including for miners who had not chosen it; OCEAN pledged to compensate them, to the tune of about 0.3 BTC.⁶ As early as 9 August, its website showed a banner announcing the return to “non-BIP110” work on its default endpoint, with a separate site for miners wishing to stay on the branch.⁶

On 29 August, OCEAN ended all support for the BIP-110 branch, announcing it would back no hard fork stemming from it. It specified that no reward mined on that branch had ever reached the 100 confirmations needed to become spendable.⁶

The fallout for the players

• The BIP is closed. On 10 August, BIP-110 moves to Closed status in the official proposals repository, with the note: “following a chain split with stalled mining”.⁷
• Luke Dashjr loses his editor role. The same day, on a motion filed by developer Mark Erhardt citing a conflict of interest, he is removed as a BIP editor, a role he had held for years. He calls it “an abuse of power”.⁸
• Luke Dashjr leaves OCEAN. After a sabbatical announced in mid-August, he leaves the pool at the end of August by mutual agreement; the parent company buys back his stake, and he announces a new mining venture, Convoy.⁹

The Knots camp switches chains

BIP-110’s supporters didn’t give up. Seeing that existing miners wouldn’t follow them, they chose to do without them: change their branch’s proof-of-work algorithm, so that the Bitcoin network’s SHA-256 machines could no longer mine it.

On 30 August 2026, the branch produces its first BLAKE2b block, at height 961,640.¹⁰ Bitcoin Knots ships the change in version 29.4.1, released on 2 September, which also activates BIP-110’s rules.¹¹ This is no longer a soft fork: it’s a hard-fork, and the branch is now a chain of its own, with its own algorithm, its own miners and its own rules. Its promoters present it as Bitcoin’s legitimate continuation; for the rest of the network, it’s a new chain that merely shares the history from before 8 August.

The bet of “firing the miners” quickly hit a limit. Machines specialised in BLAKE2b already existed — built for other cryptocurrencies — and their operators started mining the new chain without sharing its project. Knots’ following release notes call them attackers and tighten the rules accordingly: in September, newly mined bitcoins become unspendable for 45 days; in late October, for 180 days, until BIP-110’s rules are due to expire in September 2027.¹¹

Stakes and risks: both camps

For BIP-110

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

Luke Dashjr framed the urgency in blunt terms: in his view, “if BIP-110 fails, Bitcoin fails with it,” the network risking becoming indistinguishable from a central bank digital currency.¹²

Against BIP-110

• A dangerous precedent. Filtering by a transaction’s content means subjectively deciding what counts as legitimate use — a slide toward the censorship Bitcoin is meant to make impossible.
• Invalidating paying transactions. Michael Saylor summed up the objection: the proposal “turns a spam dispute into a consensus change that would invalidate certain 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 2017 block-size wars. Michael Saylor and Adam Back were among the notable opponents.¹³

What the outcome tells us

The risk of a split materialised, but not as its opponents feared. There were no two rival chains neck and neck: the minority branch stalled within a few blocks, and the network carried on with no visible disruption for the vast majority of users. Yet the two readings of the episode remain irreconcilable. For most players, it was a UASF that failed for lack of support. For the Knots camp, it was miners refusing a rule wanted by nodes, and BLAKE2b is the answer.

One thing stands out, whatever your view on the substance: on Bitcoin, no minority, however motivated, can impose a rule change without winning broad support — miners, nodes, businesses, users. It can, however, leave with its own rules. It’s slow, it’s brutal, but it’s precisely what makes Bitcoin’s rules hard to change… by anyone.

The underlying question, though, isn’t settled: the place of non-financial data in blocks is still debated. The next consensus change under discussion, BIP-54 (Consensus Cleanup), is of a different nature entirely — targeted technical fixes, unrelated to data.

Key takeaways

• BIP-110 was a temporary soft-fork meant to re-cap arbitrary data in Bitcoin transactions: outputs ≤ 34 bytes, OP_RETURN ≤ 83 bytes, pushes ≤ 256 bytes, and several restrictions on Taproot scripts.
• It was born as a counter-strike to Bitcoin Core v30 (October 2025), which had raised the OP_RETURN limit from 83 to 100,000 bytes — at the heart of the “Core vs Knots” rivalry.
• Its activation could not fail cleanly: a 55% threshold, no timeout, and mandatory signaling from block 961,632.
• Only OCEAN signaled (2.53% of blocks). On 8 August 2026, BIP-110 nodes split from the network; their branch stalled within a few blocks, and the BIP was closed.
• In late August, the Knots camp restarted its branch with a BLAKE2b proof of work: it is now a chain distinct from Bitcoin, which Bitcoin Knots has followed since version 29.4.1.