BIP-110 enforcement nears as signaling hits 2.62%

Nodes enforcing BIP-110 will reject non-signaling blocks at height 961,632; miner signaling is 2.62% with 185 blocks remaining in the 2,016-block window.

Bitcoin nodes that enforce BIP-110 will begin rejecting blocks that do not signal support at block height 961,632. A public monitor recorded 48 signaling blocks out of 1,831 observed as of 14:41:49 UTC on Aug. 7, leaving 185 blocks in the current 2,016-block signaling window and a measured signaling rate of 2.62%.

BIP-110 requires 1,109 signaling blocks within a 2,016-block period to meet the 55% activation threshold. Even if every remaining block in the window signaled, the period would end with 233 signaling blocks out of 2,016, or about 11.56%, below the required level.

From block 961,632 onward, nodes configured to enforce BIP-110 will reject any block that does not set bit 4 in the version field. Nodes running existing Bitcoin rules may continue to accept those same blocks if they otherwise validate. Miner activity after the enforcement height will determine whether an enforcing branch accumulates sustained proof-of-work accepted by enforcing nodes.

Under the proposal’s schedule, mandatory signaling is set to run through block 963,647. Lock-in will not occur once the chain height reaches 963,648, and the reduced-data validation rules that BIP-110 specifies are scheduled to activate at block 965,664 for nodes that enforce the proposal. The proposal does not force adoption; its effect depends on miner signaling and on economic and node-level support.

A pull request to implement BIP-110 in the Bitcoin Core repository was closed without merging in March. A Core contributor wrote in a personal capacity on June 4 that Core does not enforce the proposal. An alternative node implementation, Bitcoin Knots, used an Aug. 7 release to warn that older non-enforcing software builds, including current Core releases, could fail to fully validate BIP-110 rules and leave local chainstate in an unsafe condition in some scenarios. Independent reproduction of the Core-specific warning on mainnet has not been reported.

A July 17 technical test on a local regtest network using enforcing and non-enforcing Knots builds reproduced a late-upgrade issue in which a node’s data directory could retain a block accepted under the old rules after the operator switched builds. The test found that normal startup did not reconnect and revalidate inherited history. Knots merged a safeguard that scans inherited headers for mandatory-signaling violations, invalidates offending blocks and performs a reorganization. The Knots team noted that transaction- or script-level violations not visible in headers still require reconnection validation and may force a full reindex.

Some miners and pools have announced intent to support BIP-110. One mining pool published separate signaling and non-signaling endpoints and said its default would switch on July 15; confirming that miners using the pool have enforced the proposal requires independent verification. The first blocks mined after height 961,631 will show whether miners increase signaling and whether blocks acceptable to enforcing nodes begin to accumulate work.

Measuring economic support for BIP-110 will require additional evidence such as exchange listings, explicit node-adoption data or observable behavior from holders and service providers. The current public monitor reading indicates the signaling period will close below the activation threshold, leaving the network response at the enforcement boundary as the next observable development.

Articles by this author