Bitcoin Improvement Proposal 110 (BIP-110) has entered its mandatory-signaling phase, but miners have sent the required signal in only a small fraction of recent blocks—raising doubts about whether the contentious ruleset can gain enough support to sustain a rival chain.
According to a BIP-110 monitor, at block 961,632 on Saturday miners signaled support in just 51 of the preceding 2,016 blocks, equivalent to 2.53%. That falls well below the 55% threshold the mechanism expects for early activation. While nodes enforcing BIP-110 began rejecting blocks that did not set version bit 4, standard Bitcoin nodes continued accepting both signaling and non-signaling blocks—creating a potential split between enforcing and non-enforcing participants.
Key takeaways
- BIP-110 moved into a mandatory-signaling enforcement window at block 961,632, with enforcing nodes rejecting blocks lacking version bit 4.
- Miners signaled only 2.53% of the time in the preceding 2,016 blocks—far under the 55% level referenced for early activation.
- A BIP-110-compliant minority chain briefly emerged but quickly lagged behind the dominant chain.
- The proposal aims to temporarily restrict on-chain data to reduce storage and bandwidth pressure, but critics warn it could force rule-divergent behavior across the network.
Mandatory signaling begins, but miner participation stays low
The immediate consequence of BIP-110’s start is procedural and practical: once block 961,632 was reached, nodes enforcing the proposal began applying stricter block acceptance criteria. Specifically, they reject blocks that do not set version bit 4 in their block version field.
By contrast, ordinary Bitcoin nodes continued following the existing consensus rules, accepting blocks regardless of whether version bit 4 was set. That difference matters because it turns a signaling experiment into an enforcement stress test—one where participants can end up on different views of “valid” blocks depending on which rules they choose to enforce.
The BIP-110 monitor data also suggests the enforcement did not immediately attract sufficient miner support to sustain momentum. With only 51 signaling blocks out of 2,016 before the window began, proponents would need a significant change in miner behavior to avoid a situation where a BIP-110 branch advances slowly—or stops producing blocks—while the non-enforcing majority chain continues.
What BIP-110 is trying to change on-chain
Written by pseudonymous developer Dathon Ohm, BIP-110 proposes additional consensus restrictions that are intended to last for roughly one year. The proposal is designed to target the way Bitcoin scripts carry data, particularly where large payloads increase the workload for network participants.
In broad terms, BIP-110 would:
- Limit most new output scripts to 34 bytes.
- Cap OP_RETURN outputs at 83 bytes.
- Restrict certain data pushes and witness elements to 256 bytes.
- Temporarily limit several Taproot-related features.
The proposal also includes an exception for legacy outputs: unspent transaction outputs created before activation would not be affected. That detail is important because it reduces the risk of instantly “breaking” already-existing UTXOs, shifting the impact toward new transaction construction after the proposal takes effect.
Supporters have argued that these limits would discourage practices they view as non-monetary—such as inscriptions and other uses that can increase storage and bandwidth costs for node operators. The proposal’s framing is that congestion and resource pressure should be addressed at the consensus level, rather than relying on voluntary policy restrictions.
