Bitcoin BIP-110 Moves to Mandatory Signaling After Low Miner Support

Bitcoin Improvement Proposal (BIP) 110 has entered its mandatory-signaling window, but miners are signaling support at a fraction of the level needed to credibly move the network to a new consensus regime. According to a BIP-110 monitor, support was present in just 51 of the 2,016 blocks preceding block 961,632—about 2.53%—far below the 55% threshold required for early activation.

As of block 961,632, nodes enforcing BIP-110 started rejecting blocks that do not set version bit 4. Ordinary Bitcoin nodes, however, continued to accept both signaling and non-signaling blocks. A smaller “BIP-110 branch” appears to have emerged, but it quickly fell behind the chain that most miners are extending.

Key takeaways

• Miners signaled BIP-110 support at about 2.53% in the run-up to block 961,632, well under the 55% early-activation requirement.
• Starting at block 961,632, enforcement nodes reject blocks missing version bit 4, while non-enforcing nodes still accept them.
• A minority enforcing branch formed but has not gained sufficient momentum to become the dominant chain.
• BIP-110 aims to impose temporary limits on transaction/script and data sizes to curb non-monetary on-chain bloat, especially inscriptions.

Mandatory signaling begins, but the signal is weak

The core mechanics of BIP-110’s current phase hinge on miner signaling through version bit 4. During the defined mandatory-signaling window—blocks 961,632 through 963,647—nodes enforcing the proposal apply stricter rules: they reject blocks that do not carry the expected signal. The monitor data indicates that support during the prior 2,016-block period was too low for a sustained competitive chain to plausibly form.

Because the dominant chain is still being extended without broad signaling, the long-term viability of any rival branch depends on whether miners materially increase their participation. With limited support, a BIP-110 branch would at best advance slowly and could stall if miners continue extending blocks that enforcement nodes will not accept.

This is why the milestone matters beyond the immediate block height: it tests whether a contentious consensus change can move forward—or meaningfully alter behavior—without broad miner backing. That dynamic also raises the risk of an operational split: enforcing nodes could follow a chain that enforces BIP-110 rules, while the majority chain continues to follow the default rule set.

BIP-110’s proposed restrictions target on-chain data growth

BIP-110 was drafted by pseudonymous developer Dathon Ohm and is designed to introduce additional consensus restrictions intended to last roughly one year. The proposal focuses on constraining how much data different parts of a transaction can carry, including limits on output scripts and specific data-bearing elements.

In broad terms, it 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.

Importantly for users and wallet developers, outputs created before activation would be exempt from the new restrictions. Supporters of BIP-110 argue that these constraints would reduce incentives for inscriptions and other non-monetary data patterns that increase storage and bandwidth demands on node operators.

Criticism centers on network division and rule mismatches

Not everyone agrees that limiting data sizes is the right path. Critics—including Strategy Executive Chairman Michael Saylor and Blockstream CEO Adam Back—have argued that BIP-110 could divide Bitcoin and lead to situations where some nodes reject transactions that are permitted under the network’s existing rules. Earlier coverage from Cointelegraph highlighted their concerns in an article titled “Bitcoin leaders Michael Saylor and Adam Back rebuff BIP-110 proposal.”

The enforcement model during the signaling window heightens that concern. With enforcing nodes refusing non-signaling blocks, the network’s practical behavior can diverge even before a proposal’s restrictions fully take effect. This raises a key question for participants: whether the enforcement boundary will remain a technical footnote or become a persistent source of disagreement over block space usage.

Timing details and a discussed fallback

BIP-110’s deployment schedule defines several important points:

• Block 963,648 marks the beginning of its locked-in state.
• Block 965,664 is when the transaction restrictions would begin to take effect.

The version-bit mechanism is also a centerpiece of the proposal’s strategy. BIP-110 uses version bit 4 for miner signaling, with the mandatory-signaling window already underway. The current miner support level—about 2.53% in the monitor’s measured period—suggests that early activation is not likely to happen without a sharp change in miner behavior.

Separately, BIP-110 proponents have discussed contingencies. 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 later described the code as a contingency if miners opposed BIP-110, though he did not set an activation date at the time.

While that fallback discussion does not change the current signaling reality, it underlines the central tension of the moment: supporters want a path to limit certain on-chain data behaviors, while opponents worry about the consequences of contentious rule enforcement in a system that relies on miner consensus and network-wide agreement.

Going forward, readers should watch whether miner signaling meaningfully climbs as the locked-in and effect windows approach. If signaling remains low, the conflict could stay confined to a small enforcing subset; if it rises, the schedule could accelerate a much broader—and more operationally significant—change in what blocks are accepted.