Bitcoin BIP-110 Turns Mandatory Signaling as Miners Stay Under 3%

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.

Why the current phase tests a contentious consensus change

Mandatory-signaling windows are designed to show whether miners are willing to align their blocks with a new ruleset. In this case, the numbers are stark: 2.53% signaling in the monitored window preceding block 961,632 implies that miners are not broadly coordinating around BIP-110.

The result is a practical dilemma for supporters: without a substantially higher share of miner participation, an enforcing chain may struggle to grow. The source notes that a minority branch did appear but quickly fell behind the dominant chain, underscoring how difficult it is to maintain a separate chain when the majority of block production does not follow the same rule signals.

This is also where the proposal’s broader network implications come into focus. If enforcing nodes reject transactions or blocks that non-enforcing nodes accept, a consensus disagreement can emerge—not necessarily as a permanent fork, but as a period in which participants experience different validity rules.

The milestone is therefore less about whether BIP-110 is “right” in principle and more about whether supporters can make a contentious consensus change real without broad miner backing. If that coordination fails, the episode may still be valuable as a signal of how powerfully miner alignment is required for soft-fork style proposals that rely on version-bit signaling and enforcement behavior.

Pushback from major voices and a possible fallback path

The proposal has faced strong criticism from prominent figures in the Bitcoin ecosystem. The article notes that Strategy Executive Chairman Michael Saylor and Blockstream CEO Adam Back argued that BIP-110 could divide Bitcoin and lead nodes to reject transactions that the network’s existing rules would otherwise permit. Earlier coverage on Cointelegraph also highlighted the ongoing dispute around spam and data-heavy usage of block space.

On the technical timeline, BIP-110’s deployment schedule uses version bit 4 and assigns block numbers to key states. The mandatory-signaling window runs from blocks 961,632 through 963,647, during which enforcing nodes reject blocks that do not include the signal. The specification then defines block 963,648 as the beginning of its “locked-in” state and block 965,664 as the point when its transaction restrictions take effect.

The source also points to discussions of a wider contingency. On Aug. 1, Bitcoin developer Chris Guida rebased preliminary code for a proof-of-work change originally written by Bitcoin Knots maintainer Luke Dashjr. Guida described the code as a contingency if miners opposed BIP-110, while stating that no activation date had been set. The details underscore that supporters and builders have considered alternatives if the signaling track does not achieve the needed coordination.

For now, however, the immediate reality is that the signaling signal is weak, and the cost of running enforcement rules without matching miner behavior is that compliant blocks may not keep pace with the chain produced by the majority.

Going forward, investors, traders, and node operators should watch how miner signaling evolves across subsequent windows, whether the enforcing chain continues to lag or disappears entirely, and whether developers continue to refine any contingency approaches if consensus support remains fragmented.