BIP-110 Fork Failure: Who Has the Right to Change Bitcoin?

Editor | Wu Says Blockchain

TL;DR：

· BIP-110 attempts to increase the cost of writing large continuous data like Ordinals inscriptions through temporary consensus restrictions.

· The proposal received only 51 blocks, or 2.53% support during the voluntary early lock-in phase, far below the 55% threshold.

· After entering the mandatory signaling period, the minority chain formed by supporters produced only two blocks before stagnating, and BIP-110 has effectively failed as a consensus upgrade across the network.

· The controversies surrounding on-chain data, protocol neutrality, and development governance will continue; due to the lack of replay protection on the forked chain, ordinary holders should avoid moving or trading related assets hastily.

At 00:00 UTC on August 9, Beijing time, Bitcoin reached block height 961,632, and BIP-110 entered the mandatory signaling period. Nodes running BIP-110 rules began to reject blocks that did not set version bit 4, separating from the main network. Subsequently, the BIP-110 branch produced only two blocks before stagnating, while the main network continued to produce blocks normally. During the previous difficulty adjustment cycle, only 51 blocks signaled support, accounting for 2.53%, far below the 55% voluntary early lock-in threshold set by the proposal. This indicates that BIP-110 did not gain widespread miner support, ultimately forming a minority chain with very low hash power.

What Does BIP-110 Aim to Solve

BIP-110, fully titled "Reduced Data Temporary Softfork," was submitted by the pseudonymous developer Dathon Ohm, with early draft suggestions from Luke Dashjr. The proposal plans to introduce seven consensus restrictions over approximately one year, including limiting ordinary new output scripts to 34 bytes, restricting new output scriptPubKey with OP_RETURN as the first opcode to 83 bytes, and limiting various data pushes and witness stack elements to 256 bytes, while also restricting certain Taproot functionalities.

Its goal is not to completely prohibit on-chain data — the proposal itself acknowledges that data can still be split or disguised — but to increase the cost and difficulty of writing large continuous data like Ordinals inscriptions. The original text of BIP-110 explicitly states that the proposal does not address "non-Bitcoin tokens," believing such issues are better resolved at the strategy layer. UTXOs created before activation can be spent according to the original rules, but the proposal also acknowledges that very few scenarios using pre-signed Taproot transactions or special Miniscript structures may be affected.

The immediate background of this controversy is the release of Bitcoin Core 30.0 in October 2025, which significantly increased the default -datacarriersize from 83 bytes to 100,000 bytes, greatly relaxing the default forwarding restrictions on OP_RETURN. It is important to note that Core 30 adjusts the node transaction forwarding and block template strategy but does not change Bitcoin consensus; BIP-110 attempts to elevate the restrictions to the consensus layer, making blocks containing related transactions invalid as determined by nodes executing the new rules.

Timeline from Proposal to Fork

· October 10, 2025: Bitcoin Core 30.0 released, relaxing OP_RETURN default forwarding policy.

· October 24, 2025: Initial draft of BIP-110 formed; officially numbered BIP-110 on December 3.

· January 28, 2026: Official activation client’s first formal production version v0.1 released, based on Bitcoin Knots. Prior to this, multiple candidate versions had been released.

· March 1, 2026: Barefoot Mining produces the first signaling block supporting BIP-110 via OCEAN.

· March 10, 2026: Official activation client v0.4.1 officially released on GitHub; Dathon Ohm publicly announced on X on March 13.

· March 31, 2026: Dathon Ohm published project updates on Delving Bitcoin and announced submission of two implementation PRs to Bitcoin Core; the related PRs were subsequently automatically closed and not merged into Core.

· June 25, 2026: BIP-110 status changed to Complete. This status only indicates that the author believes the specification is complete and recommends adoption, not that the Bitcoin network has accepted the proposal.

· July 2026: Controversy erupts. Michael Saylor, Adam Back, PlanB, and others publicly oppose; OCEAN becomes the main source of signaling, but overall miner support remains low. OCEAN also upgrades its backend, preparing to record and settle rewards for both chains separately after the fork occurs. Ordinals supporter Leonidas announces DOG Mode, proposing to relax node forwarding rules, contrary to BIP-110's direction.

· August 9, 2026 (UTC August 8): The mandatory signaling period begins at block 961,632. Unsignaled blocks produced by AntPool are accepted by the main network but rejected by BIP-110 nodes; miners using OCEAN produce alternative blocks on the minority chain. This branch stops progressing after producing block at height 961,633.

· August 9 to 10: Roughnecks, which mined two blocks on the minority chain, announce they will stop mining under that organization’s name and suggest miners using the existing PoW algorithm pause participation. Some supporters begin discussing changing the PoW algorithm for the branch chain, but this would be another rule change outside the original proposal. The Bitcoin BIPs repository also sees proposals to change BIP-110's status from Complete to Deployed, then to Closed. As of the time of writing, the related PR has not been merged, and the official BIP-110 page still shows Complete; regardless of how the repository labels are handled, it does not mean BIP-110 has been activated on the Bitcoin mainnet.

What Are the Parties Really Arguing About

Supporters argue that miners only collect transaction fees once, while all fully validating nodes need to download and verify related blocks; nodes that do not enable pruning must also store historical blocks long-term and may provide this data to other nodes. Large-scale non-financial data will also compete for block space with payment transactions, increasing costs for ordinary transfers. Dathon Ohm and Luke Dashjr thus advocate that users and nodes have the right to define the rules they accept through user-activated soft forks, and miner signaling is not the sole determining factor. OCEAN's preparations to settle rewards for both chains also reflect that it does not assume all participants will automatically choose the same set of rules.

Opponents argue that the focus is not on whether Ordinals are valuable, but whether consensus can be changed to restrict an unpopular use case that currently complies with consensus rules and pays transaction fees. Saylor's multiple statements can be summarized into three points: Bitcoin cannot judge the purpose of data; controversies should be handled by the fee market and the strategies of nodes and miners; changing consensus for short-term disputes may undermine transaction freedom and the long-term fee market, setting a precedent for excluding other legitimate uses. He compares consensus rules to a constitution, believing that BIP-110's "solution is more dangerous than the problem itself."

Adam Back describes BIP-110 as an attempt to "regulate others," believing this conflicts with Bitcoin's principles of decentralization and permissionlessness, and predicts that the minority chain will stagnate due to a lack of hash power. PlanB, drawing from the experiences of anonymous assets and historical lessons, believes supporters have not understood Bitcoin's attributes as a decentralized anonymous asset and have not learned from the Bitcoin Cash fork.

Leonidas's proposed DOG Mode represents the other end: it does not modify consensus but plans to relax node forwarding strategies, raising the standard transaction limit from 400,000 WU to 3,900,000 WU and lowering the dust limit to 1 sat. This plan aims to expand the propagation space for data transactions like Ordinals and Runes. Since it only involves the strategy layer, it theoretically does not require a unified upgrade across the network; however, at the time of the announcement, the project had not released a code repository or formal version for public review.

What Lies Ahead

From the current outcome, BIP-110 has effectively failed as a Bitcoin consensus upgrade across the network. The minority chain inherits the main network's mining difficulty of about 127.48 T but has very little hash power. Unless it suddenly gains widespread miner support or changes PoW rules, it is unlikely to complete the next difficulty adjustment of 2,016 blocks, let alone reach the originally intended lock-in and activation heights.

Saylor estimates that about 99.85% of Bitcoin's hash power remains on the main chain, and claims that based on the minority chain's approximately 0.15% hash power, completing the first difficulty adjustment could take about 25 years. This is Saylor's personal estimate based on hash power ratios, not an actual measurement; however, Roughnecks subsequently stopped mining, further weakening the possibility of the branch's continued operation.

However, the failure of BIP-110 does not mean the controversy is over. A more likely follow-up is that the opposition to on-chain data will turn back to node forwarding strategies, miner block templates, and narrower technical proposals, while the Ordinals camp continues to push for more lenient forwarding schemes like DOG Mode. If there is another attempt at changing consensus in the future, the proposers will need to demonstrate not only the number of nodes but also the broad economic coordination formed by miners, exchanges, wallets, custodians, and users.

For ordinary holders, the short-term risk mainly comes from the minority chain lacking built-in replay protection. Bitcoin developer Kevin Loaec and hardware wallet manufacturer Ledger both warn that during the phase when both chains accept the same signed transactions, selling or transferring forked coins may result in those transactions being replicated on the Bitcoin mainnet, leading to corresponding BTC being transferred out. For users unfamiliar with forked coin operations, the safest approach remains not to move or trade those branch assets.

The controversy has also spilled over into development governance. F2Pool co-founder Wang Chun sharply criticized Luke Dashjr; former Kraken market head Dan Held believes BIP-110 has flaws in technical design and game mechanics, and criticizes its supporters for pushing the proposal with emotional and moral pressure.

BIP editor Murch has also proposed to remove Luke Dashjr from his BIP editing position. He accuses Luke of attempting to publicly assign a BIP number before the proposal had been discussed on the mailing list and merging it just minutes after creating an update PR, believing that Luke's use of editing privileges does not comply with existing processes. Luke responded that the above accusations are untrue and stated that he has consistently followed the BIP process over the years. Currently, the PR to remove his editing position remains open and has not been merged.

Ultimately, BIP-110 resembles a governance pressure test: nodes can certainly choose to execute their own rules, but whether UASF can change Bitcoin depends on whether it can gain sufficiently broad economic support. In the absence of such coordination, mandatory signaling will not automatically create consensus; it will only lead supporters to an isolated chain.

Reflection

The most interesting question in this matter is: who really has the authority to modify Bitcoin?

The answer is, no one truly has that power. Anyone can write a BIP, create their own client, and then announce: "From a certain block onward, I will only recognize blocks that comply with this new set of rules." But making such an announcement does not mean Bitcoin has actually changed. Having a BIP numbered does not count, writing the code does not count, and even a group of developers supporting it does not count; the key is whether others will follow you.

For example, this is exactly what happened with BIP-110. Supporters began to reject blocks that did not comply with BIP-110 rules after reaching the agreed block height. However, the vast majority of miners ignored them and continued to mine according to the original rules, and the Bitcoin mainnet continued to run normally. Of course, BIP-110 supporters can also say: "I do not recognize the blocks you mined." The problem is, others can also choose not to recognize you. The result is that the vast majority of hash power, exchanges, wallets, and users continue to stay on the original Bitcoin, while you have moved to a chain that hardly anyone is mining, producing only two blocks before essentially stopping. You have not successfully modified Bitcoin; you have merely forked yourself out.

Of course, this does not mean miners have the final say. If one day a large number of users, exchanges, wallets, and custodians say: "We only recognize BTC under the new rules," even if miners are initially unwilling, they may be forced to follow along, because miners ultimately mine for profit. What truly determines Bitcoin's rules is not a single formal vote or a committee, but how many people are willing to follow you in the end.

Thus, the BIP-110 incident intuitively demonstrates how Bitcoin is governed: anyone can propose rule changes, anyone can reject others' rules, but no one can command the entire network to accept their rules. Whether you can truly change Bitcoin ultimately depends not on whether you have written a BIP, but on whether miners, nodes, exchanges, wallets, and users can form a sufficiently broad consensus. Without this consensus, your so-called "modification of Bitcoin" is likely to create another chain that no one uses.

Note: This article is for information compilation and event review only and does not constitute any investment, trading, or technical operation advice. Forked chain assets may be subject to replay attacks, liquidity issues, and other technical and market risks. Readers should verify information and carefully assess risks before engaging in any related operations.