TLDR:
- BIP-110 fork trails Bitcoin by 21 blocks after enforcing nodes rejected block 961,632 early on August 9.
- Only 51 of 2,016 blocks signaled BIP-110 support in the prior period, equal to just 2.53% miner backing.
- BIP-110 requires version bit 4 signaling through block 963,647 before forced lock-in begins at 963,648.
- The minority fork lacks automatic replay protection, creating operational risks for BTC holders moving coins.
Bitcoin’s BIP-110 activation attempt has created a live minority fork after enforcing nodes rejected a non-signaling block at height 961,632. According to reports, most miners continued extending the existing network, quickly widening the gap between the two competing branches.
Source: X
By about 01:00 UTC on August 9, BIP110Monitor placed the main chain at block 961,654 and the enforcing branch at 961,633. That left the minority chain 21 blocks behind, while zero of the first 23 blocks in the new difficulty period signaled support.
BIP-110 Fork Falls Behind as Miner Signaling Stays at 2.53%
The split began at block 961,632, marking the start of the proposal’s mandatory-signaling window. AntPool mined a non-signaling block, while Roughnecks produced a competing compliant block through OCEAN.
As a result, nodes enforcing BIP-110 rejected AntPool’s block and followed the alternative branch. Meanwhile, the larger non-enforcing network continued extending Bitcoin under the existing consensus rules.
Support for the proposal had already remained limited before the split. During the previous 2,016-block period, only 51 blocks signaled support, representing just 2.53% of the total. Basically, BIP-110 uses a modified BIP9 activation process.
Under its early lock-in rules, 1,109 of 2,016 blocks, or 55%, needed to signal support, but miner participation remained far below that threshold. Because the early threshold was not reached, BIP-110 entered mandatory signaling at block 961,632.
From that point, enforcing nodes began rejecting blocks that failed to set version bit 4. The mandatory-signaling requirement remains in effect through block 963,647. Under the proposal’s rules, the minority branch would then force lock-in at block 963,648. However, the proposal’s transaction restrictions would not activate immediately.
Those rules are scheduled to take effect at block 965,664 and remain active for 52,416 blocks before expiring. Therefore, the current fork centers primarily on signaling requirements and chain selection. It does not yet involve transactions violating BIP-110’s proposed temporary data restrictions.
Replay Risk Grows as Minority Chain Continues Without Protection
Despite some social-media descriptions, BIP-110 is not a quantum-computing security upgrade. Instead, its official title is “Reduced Data Temporary Softfork,” reflecting its narrower purpose of temporarily restricting arbitrary data embedded in Bitcoin transactions.
The proposal introduces seven consensus rules covering scriptPubKeys, OP_RETURN data, witness payloads, and several Taproot-related structures. However, its “Complete” status in the BIPs repository does not mean Bitcoin has adopted the proposal.
Rather, the designation only indicates that the specification itself is considered finished. Actual adoption still depends on miners, users, exchanges, custodians, and other economic participants deciding which software and consensus rules they recognize.
Bitcoin Core has not adopted the BIP-110 implementation, while most hash power continues extending the non-enforcing chain. As a result, the main network has moved ahead considerably faster than the minority branch.
Because only limited hash power is supporting the enforcing fork, block production there can take much longer than Bitcoin’s standard target of roughly one block every 10 minutes. For BTC holders, therefore, the most immediate concern is operational rather than a failure of the dominant network.
The minority fork does not provide automatic replay protection before its later activation stage, creating additional risks when coins are moved. Consequently, a transaction made on one branch could potentially affect the same coins on the other branch. Developers have therefore cautioned holders against treating the split as a risk-free airdrop opportunity.
