Bitcoin BIP-110 turns into mandatory signal after low support among miners

Bitcoin Improvement Proposal (BIP) 110 has entered a mandatory signal window, but miners 'support signal strength is far from enough to push the network towards a new consensus mechanism. According to BIP-110 monitoring data, of the 2,016 blocks before block 961,632, only 51 blocks (approximately 2.53%) expressed support, well below the 55% threshold required for early activation.

Starting from blocks 961, 632, nodes executing BIP-110 have begun to reject blocks without version bit 4 set. However, ordinary Bitcoin nodes continue to accept signalized and non-signalized blocks. Although a smaller "BIP-110 branch" emerged, it quickly fell behind the main chain that most miners were expanding.

Key Points

Prior to block 961,632, miners 'support signal for BIP-110 was approximately 2.53%, well below the 55% early activation requirement. Starting from blocks 961, 632, execution nodes reject blocks that lack version bit 4, while non-execution nodes still accept these blocks. A minority executive branch has been formed, but has not yet gained enough motivation to become the dominant chain. BIP-110 is designed to impose temporary restrictions on transaction/script and data size to curb data proliferation on non-monetary chains, especially inscriptions.

Forces the signal to activate, but the signal is weak

The core mechanism of the current phase of BIP-110 relies on miners to pass the signal through version bit 4. During the mandatory signal window (blocks 961, 632 to 963, 647), nodes implementing the proposal apply a stricter rule: reject blocks that do not carry the expected signal. Monitoring data shows that in the previous 2,016 block cycles, the support rate was too low to form a chain of continuous competition.

Because the dominant chain is still expanding without broad signals, the long-term viability of any competing branch depends on whether miners significantly increase their participation. With limited support, the BIP-110 branch can only advance slowly at best and may stall if miners continue to expand blocks that are unacceptable to the execution node.

This is why this milestone goes beyond mere blocks: It tests whether a controversial consensus change can be advanced or significantly changed behavior without widespread support from miners. This dynamics also increases the risk of fragmentation: enforcement nodes may follow chains that enforce BIP-110 rules, while most chains continue to follow the default rule set.

Proposed restrictions on BIP-110 target data growth on the chain

BIP-110 was drafted by anonymous developer Dathon Ohman and aims to introduce additional consensus restrictions that last about a year. The proposal focuses on limiting the amount of data that can be carried in various parts of a transaction, including restrictions on output scripts and specific data-carrying elements.

Overall, it will: limit most new output scripts to 34 bytes; limit OP_RETURN output to 83 bytes; limit certain data push and witness elements to 256 bytes; and temporarily restrict multiple Taproot related features.

For users and wallet developers, output created before activation is not subject to new restrictions. BIP-110 supporters believe these restrictions will reduce incentives for inscriptions and other non-monetary data models that increase storage and bandwidth requirements for node operators.

Criticism focuses on network fragmentation and rule mismatch

Not everyone agrees that limiting data size is the right path. Critics-including Strategy Executive Chairman Michael Saylor and Blockstream CEO Adam Back-believe that BIP-110 could split Bitcoin and cause certain nodes to reject transactions allowed by existing rules of the network. Previous media reports highlighted their concerns.

Execution patterns during signal windows exacerbate this concern. Because enforcement nodes reject unsignaled blocks, the actual behavior of the network may have diverged before the proposed restrictions fully take effect. This raises a key question for participants: Will the execution boundary remain at the technical footnote level or become a source of continued disagreement over the use of block space.

Options for scheduling and discussion

The deployment schedule of BIP-110 defines several important nodes: blocks 963, 648 mark the beginning of the lockdown state; blocks 965, 664 are the time when transaction restrictions begin to take effect. The version bitching mechanism is also the core of the proposal's strategy. BIP-110 uses version bit 4 for miner signaling, and a forced signaling window is already in progress. Current levels of miner support-approximately 2.53% during the monitoring period-suggest that early activation is unlikely to occur unless there is a drastic change in miner behavior.

In addition, BIP-110 supporters discussed emergency plans. On August 1, Bitcoin developer Chris Guida released preliminary code based on proof-of-work changes, originally written by Bitcoin Knots maintainer Luke Dashjr. Guida later described the code as a contingency measure for miners to oppose BIP-110, although he did not set an activation date at the time.

While this alternative discussion does not change the current signaling reality, it highlights the current core contradiction: supporters want to find ways to restrict the behavior of certain data on the chain, while opponents worry about the consequences of enforcing controversial rules in a system that relies on miners 'consensus and network-wide consistency.

Looking forward, readers should pay attention to whether the miners signal rises significantly as the lock-in and effective windows approach. If the signal remains low, conflicts may be limited to a small number of execution nodes; if the signal rises, the timetable will accelerate a broader, more operational change that changes which blocks are accepted.