Bitcoin has just gone through one of the more unusual moments in its recent history.
BIP-110, the proposed “Reduced Data Temporary Softfork,” has failed to gain the support required to activate on the Bitcoin network. The attempt nevertheless caused a temporary minority chain to emerge when nodes enforcing BIP-110 rejected blocks that did not follow its signaling rules.
For people who have followed Bitcoin for years, this may sound familiar: another Bitcoin fork. But for newcomers, the word “fork” can be confusing.
What actually happens when Bitcoin forks? And why did BIP-110 fail?
Table Of Content
First: What Is a Bitcoin Fork?
Think of Bitcoin as a shared rulebook.
Every Bitcoin full node independently checks transactions and blocks against that rulebook. If a block doesn’t follow the rules, the node rejects it.
A fork happens when different participants in the network follow different rules or temporarily disagree about which valid block should come next. This can result in two competing versions of the blockchain.
There are two important types of protocol changes: hard forks and soft forks.
A hard fork changes the rules in a way that makes some previously valid blocks invalid to upgraded nodes. If part of the network refuses to upgrade, the two groups can continue on separate chains. Bitcoin’s history has seen this happen, most famously with the 2017 Bitcoin Cash split.
A soft fork works differently. It makes the rules stricter. Blocks that comply with the new rules are still valid under the old rules, which is why a soft fork can normally be introduced without permanently splitting the network. Bitcoin’s SegWit and Taproot upgrades were soft forks. Bitcoin’s developer documentation explains the distinction in terms of which nodes reject which blocks.
This distinction is particularly important for understanding BIP-110.
What Was BIP-110 Trying to Do?
BIP-110 is formally called the Reduced Data Temporary Softfork.
Its objective was to temporarily restrict certain forms of arbitrary data storage in Bitcoin transactions. The proposal argues that Bitcoin should prioritize its role as money and that large-scale data storage can create negative externalities for node operators and distort incentives around block space.
The proposal would have introduced the restrictions for approximately one year.
Importantly, BIP-110 was not designed to make normal Bitcoin payments invalid. Its rules were aimed primarily at various ways of putting non-monetary data into Bitcoin transactions, including techniques associated with inscriptions and large data payloads.
The proposal also included grandfathering: UTXOs created before the activation height would remain spendable under the old rules.
This is where the controversy began.
Why Was BIP-110 So Controversial?
There are essentially two competing views.
Supporters argued that Bitcoin’s scarce block space should primarily serve monetary transactions. In their view, using Bitcoin’s blockchain as a general-purpose data-storage system can increase costs for node operators and compete with payments for scarce block space.
Opponents argued that Bitcoin is permissionless by design. If a transaction follows Bitcoin’s consensus rules and someone is willing to pay the required fee, restricting particular uses of block space at the consensus level represents an unnecessary form of censorship.
There was also disagreement over how BIP-110 should be activated.
And this is where the eventual failure became particularly interesting.
The 55% Threshold
Normal Bitcoin soft-fork activation mechanisms have historically sought very broad miner support.
BIP-110 deliberately used a much lower threshold.
The proposal specified a threshold of 1,109 out of 2,016 blocks — approximately 55% — rather than the 95% threshold historically associated with BIP9 deployments. The rationale was that BIP-110 was temporary and that limiting data storage was considered sufficiently urgent to justify the lower threshold.
But there was a problem.
The miners didn’t come close to 55%.
By late July, reported signaling was only around 2.6%, with the major mining pools largely not signaling support.
That was nowhere near enough to demonstrate broad miner consensus.
And eventually the deadline arrived.
August 2026: The Fork
The critical point was block 961,632.
According to the BIP-110 specification, this began a mandatory signaling period. During this period, BIP-110 nodes would reject blocks that did not signal support for the proposal.
This created a very unusual situation.
The majority of the Bitcoin mining network continued producing ordinary Bitcoin blocks.
BIP-110 nodes, however, considered non-signaling blocks invalid.
The result was a temporary divergence.
On August 8, the network split at height 961,632, with a small BIP-110-supporting branch mining only a handful of blocks while the main Bitcoin chain moved ahead. Multiple reports now describe the minority chain as effectively abandoned after the overwhelming majority of miners continued following the existing chain.
This is an important distinction:
BIP-110 did not successfully upgrade Bitcoin.
Instead, a minority group of nodes temporarily followed a different set of rules and therefore found itself on a minority chain.
Why Did BIP-110 Fail?
The simplest answer is:
There wasn’t enough consensus.
Bitcoin is not controlled by the person who writes a BIP.
It isn’t controlled by Bitcoin Core.
It isn’t controlled by Bitcoin Knots.
And it isn’t controlled by the miners alone.
A successful consensus change ultimately requires enough of the Bitcoin ecosystem to converge on the new rules.
That includes miners, node operators, developers, businesses, wallets, exchanges and, ultimately, the economic users of Bitcoin.
BIP-110 demonstrated what happens when that convergence doesn’t occur.
The proposal had supporters who were willing to run software enforcing the new rules. But the overwhelming majority of mining power did not follow them.
Once block 961,632 arrived, the difference became visible on the blockchain.
The Interesting Part: The Minority Chain
There is a subtle but important lesson here.
It would be misleading to say simply that “Bitcoin forked.”
Technically, a competing chain did appear.
But this was not a 50/50 split.
The BIP-110 chain was a minority chain with very little mining power behind it, while the existing Bitcoin chain continued to accumulate blocks much faster. Reports following the event showed the main chain pulling dozens of blocks ahead.
That matters because Bitcoin’s proof-of-work system makes it extremely difficult for a tiny minority of miners to maintain a competing chain indefinitely.
A chain with little hashpower simply struggles to produce blocks.
In other words, BIP-110 demonstrated the difference between being able to create alternative Bitcoin software and getting the Bitcoin network to adopt that software’s consensus rules.
So Who “Won”?
That depends on your perspective.
From the perspective of BIP-110 supporters, the proposal was designed to change Bitcoin’s treatment of arbitrary data, and that change did not achieve broad network adoption.
From the perspective of its opponents, the episode demonstrated that a minority cannot simply impose new consensus rules on Bitcoin.
The existing Bitcoin chain continued operating.
Normal Bitcoin users running standard software were not suddenly forced onto a new chain.
And that may be the most important lesson of the entire episode.
Bitcoin’s Real Governance System
Bitcoin has no CEO who can announce a protocol upgrade.
There is no central authority that can push a button and change the rules for everyone.
A BIP is a proposal.
Software is an implementation.
A miner signaling for a proposal is a vote of sorts, but it isn’t the same thing as final economic consensus.
Ultimately, Bitcoin works because independent participants choose which rules they are willing to accept.
The BIP repository itself makes this principle explicit: acceptance and adoption ultimately rest with Bitcoin users and the broader economic majority.
That makes contentious upgrades extremely difficult.
And that difficulty is intentional.
The BIP-110 Lesson
Regardless of where you stand on inscriptions, Ordinals, OP_RETURN or arbitrary data, BIP-110 has provided Bitcoin with a fascinating real-world demonstration of decentralized consensus.
Changing Bitcoin’s rules is hard.
Very hard.
You can write a proposal.
You can write the code.
You can convince miners to signal.
You can convince node operators to upgrade.
But unless enough of the ecosystem agrees to actually follow the new rules, the proposed change doesn’t become Bitcoin simply because someone wrote it into software.
BIP-110 attempted to demonstrate that principle in practice.
The proposal didn’t achieve the required miner support, and when its enforcement rules began rejecting the blocks produced by the majority of miners, the result was not a successful Bitcoin upgrade.
It was a small minority chain.
And the main Bitcoin network continued on.
Lessons we have learned from this
Perhaps the most important takeaway isn’t whether BIP-110 was technically right or wrong.
It is that Bitcoin’s consensus rules are extraordinarily difficult to change without broad agreement.
That may sometimes make Bitcoin frustratingly slow.
It may also be one of the reasons people trust it.
After all, if changing the rules were easy, Bitcoin wouldn’t be the same Bitcoin.
