Bitcoin splits at block 961632 as BIP-110 enforces rules despite 2.53% support

Bitcoin splits at block 961632 as BIP-110 enforces rules despite 2.53% support

N
News Editor
2026-08-11 03:21:18
Bitcoin split into two incompatible chains on Aug. 8 after BIP-110 nodes began rejecting blocks that did not signal bit 4 at block height 961632, even though the proposal had received support from just 51 blocks in the prior 2,016-block window, or 2.53%. The higher-work chain continued under the existing rules, while the BIP-110 branch fell behind, reaching block 961633 by 9:00 a.m. Beijing time on Aug. 9, 21 blocks behind the main chain at 961654. The proposal was put forward by pseudonymous developer Dathon Ohm, with Luke Dashjr involved in the early draft and technical suggestions. Its reference implementation is based on Bitcoin Knots rather than Bitcoin Core, and it did not secure majority miner support. Supporters are trying a user-activated soft fork, arguing that nodes, exchanges, wallets and payment services can define valid blocks even without strong miner signaling. For now, BIP-110 has not activated its data limits on Bitcoin mainnet. What exists is a low-hashrate execution chain. The main chain still follows the original rules, and the 21 million BTC cap, existing balances and everyday payments remain unchanged. Risks are concentrated among nodes, wallets and services using BIP-110 infrastructure because the split came without dedicated replay protection.

Bitcoin split into two incompatible chains on Aug. 8 after BIP-110 nodes started rejecting any block that did not signal bit 4 once the network reached block 961632, despite the proposal drawing support from only 51 blocks in the previous 2,016-block period, or 2.53%.

Most miners did not adopt the proposal and kept producing blocks under the existing rules. A smaller group of miners and nodes enforcing BIP-110 stayed on a separate branch. By 9:00 a.m. Beijing time on Aug. 9, the higher cumulative-work main chain had advanced to 961654, while the BIP-110 execution chain was stuck at 961633, trailing by 21 blocks. None of the first 23 blocks in the new period on the main chain signaled support for the proposal.

This is not an even hashpower contest. The main chain is moving forward normally, while the BIP-110 branch is producing blocks far more slowly because it has too little mining power behind it.

Who is behind BIP-110

BIP-110 was proposed by pseudonymous developer Dathon Ohm. Luke Dashjr took part in the early draft and provided technical suggestions. The reference implementation is built on Bitcoin Knots, which Luke maintains. It was not merged into Bitcoin Core and did not win support from a majority of miners.

That means the push is not coming through Bitcoin Core’s mainnet upgrade path. The actual drivers are some Knots node operators and a small number of miners. The effort is a UASF, or user-activated soft fork, in which nodes tighten the rules for what they will accept even if miner signaling fails to clear the desired threshold.

The dispute goes back to inscriptions and on-chain data

The fight around BIP-110 is rooted in the long-running debate over Ordinals, BRC-20 and Runes. Those uses write images, text and token-related data into Bitcoin blocks. Supporters of those applications argue that block space is a fee market and miners should be free to include whatever users are willing to pay for.

BIP-110 backers take the opposite view. They argue that Bitcoin should first serve as money and a payments network, and that large amounts of arbitrary data increase blockchain size and leave full nodes carrying long-term storage, bandwidth, validation and propagation costs. Publishers of that data pay a fee once, but after the data enters a block, nodes around the world must keep storing it. In their view, the transaction happens between the publisher and the miner, while the continuing cost is pushed onto the network. BIP-110 is meant to turn that conflict from a policy question about relay and mining into a consensus rule.

Under the proposal, the restrictions would run temporarily for about one year after activation. Most standard new output scripts would be capped at 34 bytes. OP_RETURN would be limited to 83 bytes. Data pushes and some witness elements would be capped at 256 bytes, and several Taproot constructions that could be used to carry data would be disabled. Old UTXOs would be exempt, and most ordinary payment transactions would remain unaffected.

Opponents are not only focused on whether inscriptions can still be published. They argue that BIP-110 moves some transaction uses out of the fee market and into hard valid-or-invalid consensus judgments, which could affect Miniscript, BitVM and future protocols built on Taproot. They also note that the proposal would not eliminate on-chain data entirely. Users could still split data apart or change encoding methods, though at a higher cost and with more operational complexity.

Why push ahead with such low support

BIP-110 supporters do not treat miner signaling as the final vote. In the UASF model, nodes decide which blocks are valid. If enough users, wallets, exchanges and payment services adopt the new rules, miners may follow in order to avoid producing blocks that the market will not accept.

BIP-110 set the miner lock-in threshold at 55%, below the 95% level commonly associated with BIP9. The more aggressive part comes later. Even if the proposal stayed below that threshold for a long period, it would still enter a mandatory signaling phase from 961632 through 963647. Nodes enforcing BIP-110 would mark any block without bit 4 signaling as invalid. Their chain would move into lock-in after 963648, then run for another 2,016-block period, with data limits scheduled to take effect at 965664.

The bet is that nodes and economic actors will choose sides first and hashpower will be forced to follow. So far, on-chain results show that this has not happened. Most miners are still extending the original chain, and BIP-110 nodes are left waiting for blocks on a low-hashrate branch.

What has happened so far is only a signaling-rule fork. The 34-byte, 83-byte and 256-byte limits have not taken effect on Bitcoin mainnet. The BIP-110 branch has not even reached the formal lock-in or enforcement stage yet.

Can it still succeed

That depends on what success means. As long as some miners keep producing blocks, the BIP-110 chain can continue to exist and eventually activate the rules on its own branch. But becoming the economically recognized Bitcoin main chain is a different matter. That would require sustained hashpower and broad recognition from exchanges, wallets, custodians, Lightning services and coin holders. Nodes can reject blocks from the main chain, but rejection alone does not make everyone else accept the alternative chain.

Time is another hard constraint. The BIP-110 chain inherited mainnet mining difficulty when it split. Bitcoin adjusts difficulty only once every 2,016 blocks, and any single adjustment can reduce difficulty by no more than 4x. Using the earlier 2.53% signaling rate as a rough proxy for the branch’s hashpower, the first 2,016-block period could take about 553 days. After a difficulty reduction, reaching formal activation could still take another roughly 138 days, bringing the total close to 690 days, or about 1.9 years.

That figure is not a fixed date. If new hashpower joins, the timeline could shrink sharply. Even so, the estimate shows that BIP-110 could face a very long slow period before activation, even if it does eventually enforce its rules on its own chain. The waiting period alone could end up lasting longer than the proposal’s planned one-year enforcement window.

What it means for holders right now

For ordinary BTC holders, this is not the same as saying Bitcoin’s rules have already changed. The chain with the highest cumulative work is still running under the original rules, and the 21 million BTC cap, existing balances and ordinary payments remain unchanged.

The main risk sits with nodes, wallets and service providers using BIP-110 backends. The two chains can show different confirmation states, and the fork did not include dedicated replay protection, meaning the same standard transaction may be valid on both sides.

For now, the outcome is straightforward: BIP-110 has not activated on Bitcoin mainnet. What it has produced so far is a separate execution chain with very low hashpower.

This article was originally published by Bit.Fan. For more cryptocurrency news and market insights, visit www.bit.fan.
580

Disclaimer:

The market information, project data, and third-party content displayed on this platform are for industry information sharing only and do not constitute any form of investment advice or return commitment.

Cryptocurrency trading carries high risks. Users should fully assess their risk tolerance and make independent decisions. All profits, losses, and legal responsibilities are borne by the users themselves.