What was BIP-110, and why did Bitcoin split?
14 November 2026 · UTXOHub · 9 min read
BIP-110 was a proposal to make Bitcoin reject, for about a year, transactions carrying large pieces of data that aren't payments, such as images. Miners didn't adopt it, so on 8 August 2026 the nodes enforcing it split off onto a chain that soon stalled, and the proposal was closed. It grew out of an argument between Bitcoin Core and Bitcoin Knots, the two main versions of Bitcoin's node software, over whether that data is spam.
Relay rules and consensus rules
Every Bitcoin nodeNodeA computer running Bitcoin software that checks every payment and block against the rules, and passes them on to others., a computer running Bitcoin's software, follows two kinds of rules. Consensus rules decide whether a block is valid. Every node has to agree on them, or the nodes stop sharing one chain. Relay rules, which developers call policyPolicy vs consensusConsensus rules decide whether a block is valid — breaking them splits the chain. Policy is what your own node relays, and each operator can change it., decide only which unconfirmed transactions a node keeps in its mempoolMempoolThe waiting room for Bitcoin transactions that have been sent but aren't in a block yet. and passes on. Each operator can set their own.
Most nodes run Bitcoin CoreBitcoin CoreThe most widely run Bitcoin software: a full node that checks every block and payment, with a wallet built in. It grew from Satoshi's first version.. Bitcoin KnotsBitcoin KnotsA version of Bitcoin Core, led by Luke Dashjr, that filters more kinds of data by default. Since September 2026 its new releases follow a separate chain., led by Luke Dashjr, is built from Core's code with changes of its own, and its default policy is stricter. Knots limits extra data to 83 bytes and applies that limit “to all known datacarrier methods”; it also refuses to relay or mine what its settings call “parasitic overlay protocols” and “transactions involving non-bitcoin tokens”. Bitcoin Core 30.0, released in October 2025, went the other way: it raised its limit on OP_RETURNOP_RETURNA payment output that stores data instead of paying someone. It can never be spent, so nodes don't track it as spendable. data to 100,000 bytes, which its release notes say “effectively uncaps the limit”.
The difference between the two kinds of rule is the heart of the story. A transaction that most nodes refuse to pass on can still be mined if it reaches a miner some other way, and every node will then accept the block. A relay filter can make data harder to get into a block. Only a consensus rule can make a block that contains it invalid.
Is it spam? The argument of 2025
Since 2023, people have argued over inscriptionsInscription (ordinals)Data, such as an image, written into a Taproot payment's witness and tied to one satoshi, so it lives on the blockchain.: images, text and other files written into the witness part of TaprootTaprootA 2021 upgrade that added Schnorr signatures and addresses starting bc1p, making complex payments cheaper and more private. transactions. In April 2025 Antoine Poinsot, a Bitcoin Core contributor, proposed dropping Core's 83-byte limit on OP_RETURN, the part of a transaction made for carrying a little data. The limit was meant “to mildly deter data storage”, he wrote, but “the nudge is ineffective”. Worse, it pushed developers into data tricks that cost nodes more, such as a bridge called Clementine storing data in Taproot outputs that can never be spent.
Dashjr called the idea “utter insanity”. “The bugs should be fixed, not the abuse embraced,” he wrote; “If attackers continue to bypass filters, we can go back to a full whitelist approach.” In a second reply he set out why a filter that leaks is still worth having: “It's sufficient to make spam unwelcome and costly. No spam filtration solution needs to be perfect.”
In June 2025, 31 Bitcoin Core contributors, including Pieter Wuille, signed a statement answering him. “Knowingly refusing to relay transactions that miners would include in blocks anyway forces users into alternate communication channels,” it says, and that weakens what relay is for: helping nodes predict the next block, and keeping small miners from falling behind large ones that take transactions privately. It added that getting round the filters of most nodes “is relatively easy”, and that “This is not endorsing or condoning non-financial data usage”.
Sjors Provoost, another Core contributor, had already named the next step in the same April thread, in words Dashjr quoted back to him: “Only consensus changes can work, but so far you haven't proposed those.” Dashjr replied that filters “were and continue to be very effective”. Core 30.0 shipped on 10 October 2025 with the limit raised. Two weeks later, on 24 October, the first draft of BIP-110 appeared.
What BIP-110 would have changed
BIP-110, the Reduced Data Temporary Softfork, lists Dathon Ohm as its author, and its credits read “Original draft and advice: Luke-Jr”, Dashjr's name on GitHub. Its code was built on Bitcoin Knots. For about a year, 52,416 blocks, it would have made blocks invalid if they created new outputs over 34 bytes (or OP_RETURN outputs over 83), or carried any single piece of data over 256 bytes, along with five narrower limits on Taproot. Coins created before it took effect would have stayed spendable exactly as before.
The proposal makes its case plainly. “Such data embedding must be resisted at all times in order to ensure it doesn't become load-bearing and start to produce negative externalities, especially for node operators,” it says. Data storage “competes unfairly with payments, making Bitcoin payments unnecessarily costly”. The 256-byte limit was chosen because “it is plausible to represent images in as few as 300-400 bytes”. It asked people storing data to use other places, “such as Nostr, IPFS, BitTorrent, cloud storage, etc”.
It was a soft forkSoft forkA change that tightens Bitcoin's rules, so nodes that haven't upgraded still accept the new blocks., a tightening of the rules that older nodes still accept, but an unusual one. The usual method, BIP-9, waits until 95% of blocks signal that miners are ready; BIP-110 asked for 55%, because, its author wrote, “rejecting data storage is a matter of urgency”. And from block 961,632, during the last two weeks before its deadline, nodes running it would reject every block that didn't signal support. If most miners didn't signal, those nodes would part company with them. Supporters of SegWit made a similar threat in 2017, as our article on trust describes.
The case against it
Gregory Maxwell, a longtime Bitcoin developer and a co-founder of Blockstream, argued in November 2025 that it could still trap people's money. Some coins are locked in transactions signed in advance and not yet broadcast, sometimes with a time lock. Under BIP-110 those “would appear to the network to be outputs created at a later time, although they really weren't”, so the exemption for older coins wouldn't protect them. “Essentially every aspect of the proposal has confiscation issues,” he wrote. He also asked whether it would “fail at its stated purpose”, since anyone determined to store data could switch to a method it didn't block.
Ohm answered the same day: “I think my proposal neither confiscates funds nor sets a bad precedent, as it takes pains to avoid causing problems for all known use cases. I don't think it is reasonable never to create problems for all unknown use cases, as this would necessarily imply permanent ossification.” Ossification means a protocol that can never change again.
The proposal is open about its costs. It says it “intentionally breaks user space, specifically the data storage user space”. Its own list of tradeoffs adds that BitVM, a way to build more complex contracts on Bitcoin, “may just need to wait until this softfork expires”, and that some wallet software would need changing.
On 7 August 2026, the day before mandatory signalling began, Peter Todd, a Bitcoin developer who reviewed its code, predicted what would happen: “Absent some kind of attack, given their current hash power they will most likely fork off into a separate coin with minority hash power (or even no hash power).”
8 August 2026: the split
At 19:35 UTC on 8 August 2026, the mining pool AntPool found block 961,632. Like most blocks then, it didn't signal for BIP-110, so nodes enforcing BIP-110 rejected it, and every block built on it. The rest of the network accepted it and carried on.
Mark “Murch” Erhardt, a Bitcoin Core contributor and one of the editors who look after the list of BIPs, counted the result the next evening. BIP-110 had “just shy of 2.5% of blocks signaling readiness in the latest signaling period”, and its nodes “relegated themselves to a chain that only found two blocks, while the Bitcoin blockchain grew by 134 blocks”. Bitcoin Magazine reported that the new chain “stalled after two blocks were mined by enthusiasts”.
When developer Jon Atack proposed marking the BIP closed, Greg Tonoski, a supporter, objected that it “has been activated” and that he would keep running such a node and “accepting payments”. The BIP was marked Closed anyway, “following a chain split with stalled mining”, in its version of 9 August.
Knots changes its proof of work
Knots answered with a hard forkHard forkA change that loosens Bitcoin's rules, so nodes running old software reject the new blocks. Without near-universal agreement it splits the chain., a change that older software rejects. Its version 29.4.1, released on 2 September 2026, replaced the proof of workProof of workA puzzle that takes a computer real effort to solve, so the answer proves the effort was spent. Bitcoin’s miners use it to add each block. that all of Bitcoin's miners use, so their machines can no longer add blocks to its chain. Its release notes say: “On August 8th, most former miners abandoned Bitcoin en masse and together with other bad actors have been falsely promoting a new altcoin as ‘Bitcoin’.” Fixing that “unfortunately requires a backward-incompatible protocol change”: a new algorithm called BLAKE2b, and a temporary limit of about 300 kB a block.
The project's own site dates the first BLAKE2b block, at height 961,640, to 30 August 2026, and says its limits on data last until 1 September 2027. The two accounts of the split are mirror images. Knots's notes call the chain most miners kept “a new altcoin”; Bitcoin Magazine called the BIP-110 chain “a new, out of consensus blockchain”.
Most Knots users haven't followed. Of the 19,286 nodes that accept connections, Bitnodes counted 1,872 running Knots at 12:10 UTC on 14 November 2026, and every one reported a block height on the chain Bitcoin Core follows; 1,232 ran a Knots release from May 2026, before the hard fork. That is also the chain UTXOHub reads, and payments on it were not affected by the split.
What would settle the argument
Miners settled one question: almost none signalled for BIP-110, so it never took effect on the chain they mine. They didn't settle whether they were right. Knots's release notes call their choice an attack; in Murch's account, BIP-110's own nodes “relegated themselves” to a chain that stopped.
The relay question is still open, and part of it can be measured. Core's contributors say filters are easy to get round and push transactions to miners privately; Dashjr says filters make data costly and still work. Evidence on how much of the data that filters refuse reaches blocks anyway, and by which route, would go a long way to deciding it.
The rest is a question of values: whether Bitcoin should refuse uses that many of its users dislike, and who decides. No measurement answers that. Core's statement says users “have ultimate freedom in choosing what software they use”, and Knots is one of the choices. Each node's operator still chooses its own relay policy.
References
- Bitcoin Knots on GitHub, “Relay defaults in src/policy/policy.h (29.5)”.
- Bitcoin Core, “Bitcoin Core 30.0 release notes”, 10 October 2025.
- Antoine Poinsot, Bitcoin Development Mailing List, “Relax OP_RETURN standardness restrictions”, 17 April 2025.
- Luke Dashjr, Bitcoin Development Mailing List, “Re: Relax OP_RETURN standardness restrictions”, 26 April 2025, 09:50 UTC.
- Luke Dashjr, Bitcoin Development Mailing List, “Re: Relax OP_RETURN standardness restrictions (reply to Sjors Provoost)”, 26 April 2025, 11:35 UTC.
- Bitcoin Core, “Bitcoin Core development and transaction relay policy”, 6 June 2025.
- Bitcoin Improvement Proposals, “BIP-110: Reduced Data Temporary Softfork”.
- Greg Maxwell, Bitcoin Development Mailing List, “Re: [BIP Proposal] Reduced Data Temporary Softfork”, 8 November 2025.
- Dathon Ohm, Bitcoin Development Mailing List, “Re: [BIP Proposal] Reduced Data Temporary Softfork”, 8 November 2025.
- Peter Todd, “BIP-110 Code Review”, 7 August 2026.
- Murch, Bitcoin Development Mailing List, “Re: BIP 110: update status to closed”, 9 August 2026.
- Bitcoin Magazine, “Luke Dashjr removed as Bitcoin BIP editor”, 11 August 2026.
- Bitcoin Development Mailing List, “BIP 110: update status to closed (thread)”, 9–10 August 2026.
- Bitcoin Knots on GitHub, “Bitcoin Knots v29.4.1.knots20260508”, 2 September 2026.
- bitcoin-blake2b.org (Bitcoin Knots), “Why this hardfork exists”.
- Bitnodes, “Reachable Bitcoin nodes”, 14 November 2026, 12:10 UTC.