Bitcoin entered BIP-110’s mandatory signaling phase at block height 961,632 in the early hours of Aug. 9 Beijing time. Nodes running the BIP-110 rules began rejecting blocks that did not set version bit 4 and split away from the main network. The branch enforcing BIP-110 then produced only two blocks before stalling, while Bitcoin’s main chain kept advancing.
During the previous difficulty adjustment period, only 51 blocks signaled support for the proposal, equal to 2.53% of the total. That was far below the 55% threshold BIP-110 had set for voluntary early lock-in, showing that the proposal never won broad miner backing and ended up on a low-hashrate minority chain.
What BIP-110 was trying to do
BIP-110, short for Reduced Data Temporary Softfork, was submitted by pseudonymous developer Dathon Ohm. Luke Dashjr provided input on the early draft. The proposal sought to add seven consensus restrictions over roughly one year, including limiting standard new output scripts to 34 bytes, capping a new output scriptPubKey that begins with OP_RETURN at 83 bytes, restricting several data pushes and witness stack elements to 256 bytes, and limiting parts of Taproot functionality.
The goal was not to eliminate on-chain data entirely. The proposal itself acknowledged that data could still be split up or disguised. Its stated purpose was to raise the cost and difficulty of writing large amounts of continuous data to Bitcoin, including Ordinals inscriptions. The text of BIP-110 also said it did not address “non-Bitcoin tokens,” arguing that such issues were better handled at the policy layer.
UTXOs created before activation would still be spendable under the old rules. At the same time, the proposal acknowledged that a very small number of setups involving presigned Taproot transactions or special Miniscript structures could be affected.
The immediate backdrop: Bitcoin Core 30.0 and OP_RETURN policy
The direct backdrop to the fight was Bitcoin Core 30.0, released in October 2025. That release raised the default -datacarriersize from 83 bytes to 100,000 bytes, sharply loosening the default relay policy for OP_RETURN.
The distinction matters. Core 30 changed transaction relay and block template policy at the node level. It did not change Bitcoin consensus. BIP-110 tried to move those restrictions into the consensus layer, meaning blocks that contained the targeted transactions would be judged invalid by nodes enforcing the new rules.
How the proposal moved from draft to failed fork
- Oct. 10, 2025: Bitcoin Core 30.0 was released, loosening the default OP_RETURN relay policy.
- Oct. 24, 2025: The first draft of BIP-110 was formed. It was formally assigned the BIP-110 number on Dec. 3.
- Jan. 28, 2026: The first formal production release of the activation client, v0.1, was published. The code was based on Bitcoin Knots. Several candidate versions had already appeared before that release.
- March 1, 2026: Barefoot Mining, through OCEAN, produced the first signaling block supporting BIP-110.
- March 10, 2026: The official activation client v0.4.1 was released on GitHub. Dathon Ohm announced it publicly on X on March 13.
- March 31, 2026: Dathon Ohm posted a project update on Delving Bitcoin and said two implementation PRs had been submitted to Bitcoin Core. Those PRs were later auto-closed and not merged into Core.
- June 25, 2026: BIP-110’s status was changed to Complete. That label only meant the author considered the specification finished and recommended for adoption. It did not mean the Bitcoin network had accepted the proposal.
- July 2026: The dispute escalated in public. Michael Saylor, Adam Back, and PlanB opposed the proposal. OCEAN became the main source of support signals, but miner support stayed low overall. OCEAN also upgraded its backend in preparation for recording and settling rewards on both chains if a fork happened. On the other side, Ordinals supporter Leonidas announced DOG Mode, a plan to loosen node relay rules rather than tighten them.
- Aug. 9, 2026 Beijing time / Aug. 8 UTC: The mandatory signaling phase began at block 961,632. A non-signaling block mined by AntPool was accepted by the main chain and rejected by BIP-110 nodes. Miners using OCEAN then produced a replacement block on the minority chain. That branch stopped advancing after producing the block at height 961,633.
- Aug. 9 to Aug. 10: Roughnecks, which mined the two minority-chain blocks, said it would stop mining under that name and advised miners still using the current PoW algorithm to pause participation. Some supporters began discussing a PoW change for the branch chain, which would amount to another rules change outside the original proposal. At the same time, the Bitcoin BIPs repository saw proposals to change BIP-110’s status from Complete to Deployed and then to Closed. As of publication, those PRs had not been merged and the official BIP-110 page still showed Complete. Regardless of repository labels, that did not mean BIP-110 had activated on Bitcoin mainnet.
What the two sides are actually fighting over
Supporters argued that miners collect a fee once, while every fully validating node has to download and verify the relevant blocks. Nodes that do not use pruning must also store historical blocks over the long term and may serve that data to other nodes. In their view, large amounts of non-financial data also compete with payment transactions for block space and raise the cost of ordinary transfers.
From that starting point, Dathon Ohm and Luke Dashjr argued that users and nodes have the right to define which rules they accept through a user-activated soft fork, and that miner signaling is not the only deciding factor. OCEAN’s preparation to settle rewards separately on the two chains also showed it was not assuming that every participant would automatically choose the same rule set.
Critics focused on a different question. Their argument was not mainly about whether Ordinals have value. It was about whether Bitcoin consensus should be changed to limit a use case that may be unpopular to some participants but is still valid under the current rules and pays transaction fees.
Michael Saylor’s public comments were framed around three ideas: Bitcoin cannot determine the purpose of data; disputes of this kind should be handled through the fee market and through node and miner policy; and changing consensus for a short-term controversy could weaken transaction freedom and the long-term fee market while setting a precedent for excluding other legitimate uses. He compared consensus rules to a constitution and said BIP-110’s solution was more dangerous than the problem it was trying to address.
Adam Back described BIP-110 as an attempt to “regulate other people,” saying it conflicted with Bitcoin’s decentralized and permissionless nature. He also predicted in advance that a minority chain without enough hashpower would stall. PlanB argued from the perspective of Bitcoin as a decentralized bearer asset and from the history of past splits, saying supporters had not understood that property of Bitcoin and had failed to learn from the Bitcoin Cash fork.
Leonidas’s DOG Mode represented the opposite direction. It would not alter consensus. Instead, it proposed loosening relay policy by raising the standard transaction limit from 400,000 WU to 3,900,000 WU and lowering the dust threshold to 1 sat. The aim was to widen the propagation window for data-heavy transactions tied to Ordinals and Runes. Because it would operate at the policy layer, it would not in theory require a synchronized network-wide upgrade. But at the time of the announcement, no publicly reviewable code repository or formal release had been published.
The minority chain’s path looks bleak
Based on the current outcome, BIP-110 has effectively failed as a network-wide Bitcoin consensus upgrade. The minority chain inherited a mining difficulty of about 127.48 T from the main network, yet it had only a tiny fraction of the hashpower. Unless it somehow gains major miner support or changes its PoW rules, it is unlikely to complete the next 2,016-block difficulty adjustment, let alone reach the originally planned lock-in and activation heights.
Michael Saylor estimated that about 99.85% of Bitcoin hashpower remained on the main chain. Using a minority-chain share of about 0.15%, he said the first difficulty adjustment could take roughly 25 years. The article noted that this was Saylor’s personal estimate based on hashpower ratios, not a measured result. Even so, Roughnecks later stopped mining, cutting further into the branch’s chances of continuing operation.
That said, the failure of BIP-110 does not mean the argument is over. A more likely next phase is that opponents of on-chain data return to narrower proposals focused on node relay policy, miner block templates, and other limited technical changes, while the Ordinals camp continues to push looser relay approaches such as DOG Mode. If anyone tries again at the consensus layer, the proposal would need to show not only node support but broad economic coordination among miners, exchanges, wallets, custodians, and users.
Short-term risk for ordinary holders: replay protection is missing
The immediate risk for ordinary holders comes from the minority chain’s lack of built-in replay protection. Bitcoin developer Kevin Loaec and hardware wallet maker Ledger both warned that while both chains still accept the same signed transactions, a sale or transfer of forked coins could be replayed on Bitcoin mainnet, sending the corresponding BTC as well.
For users who are not familiar with coin-splitting procedures, the article said the safer approach is not to move or trade assets on the branch chain for now.
The dispute has spilled into development governance
The controversy has also spread into governance around Bitcoin development. F2Pool co-founder Wang Chun sharply criticized Luke Dashjr. Former Kraken head of markets Dan Held said BIP-110 had flaws in both technical design and game theory, and he criticized supporters for pushing the proposal with emotion and moral pressure.
BIP editor Murch also proposed removing Luke Dashjr from his role as a BIP editor. He alleged that Luke had tried to assign a BIP number publicly before the proposal had been discussed on the mailing list and had merged an update PR within minutes of its creation, which in Murch’s view did not match established process.
Luke responded that those allegations were false and said he had followed the BIP process consistently for years. The PR seeking his removal remained open and had not been merged at the time of writing.
A governance stress test more than a successful upgrade
In the end, BIP-110 looked more like a governance stress test than a viable Bitcoin upgrade. Nodes can choose to enforce their own rules, but whether a UASF can change Bitcoin depends on whether it gains broad enough economic backing. Without that coordination, mandatory signaling does not create consensus by itself. It leaves supporters on an isolated chain.
The episode also brought an old question back into focus: who actually has the power to change Bitcoin? The answer presented here is that no single actor really does. Anyone can write a BIP, ship a client, and say that from a certain block onward they will only recognize blocks that follow a new ruleset. That declaration alone does not mean Bitcoin has changed.
A BIP number is not enough. Published code is not enough. Even support from a group of developers is not enough. What matters is whether other participants choose to follow: miners, nodes, exchanges, wallets, custodians, and users.
BIP-110 illustrated that in a very direct way. Its supporters began rejecting blocks that did not meet the proposal’s rules once the scheduled height arrived. Most miners ignored that and kept mining under the old rules, so Bitcoin mainnet kept moving. BIP-110 supporters could refuse to recognize the main chain’s blocks, but everyone else could refuse to recognize the minority chain. The result was that most hashpower, exchanges, wallets, and users stayed with the original Bitcoin network, while the supporters ended up on a branch that was barely mined and effectively stopped after two blocks.
That does not mean miners alone decide the outcome either. If, at some point, a large enough group of users, exchanges, wallets, and custodians were to recognize only BTC under a new ruleset, miners could be pushed to follow because their incentives still come back to revenue. In that sense, Bitcoin’s rules are not settled by a formal vote or by a committee. They are settled by how many participants are willing to coordinate around the same system.
Seen that way, BIP-110 offered a clear picture of how Bitcoin governance works: anyone can propose a rules change, anyone can reject someone else’s rules, but nobody can order the whole network to accept a particular version. Without broad consensus, “changing Bitcoin” can turn into nothing more than creating another chain that few people use.
The original article also noted that it was an information roundup and event review only, not investment, trading, or technical advice. Assets on a fork chain may involve replay attacks, low liquidity, and other technical or market risks, and readers should verify information independently and assess those risks carefully before taking action.