BIP-110's Mandatory Signaling Window Opens, Miners Reply "Hard Pass" 🪨

Bitcoin Improvement Proposal 110 crossed into its mandatory-signaling phase at block 961,632 on Saturday, with miner support registering at just 51 of the preceding 2,016 blocks, or 2.53%, far below the 55% threshold required for early activation, according to the BIP-110 monitor. Beginning at block 961,632, nodes enforcing BIP-110 started rejecting blocks that failed to set version bit 4, while ordinary Bitcoin nodes continued to accept both signaling and non-signaling blocks. A minority BIP-110 branch emerged shortly after but quickly fell behind the dominant chain. With such modest mining support, a sustained rival chain appears unlikely without significantly greater participation, and a BIP-110 branch could advance slowly or stop producing blocks altogether.

Authored by pseudonymous developer Dathon Ohm, BIP-110 proposes additional consensus restrictions lasting roughly one year. The proposal 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, and temporarily limit several Taproot features, while exempting unspent transaction outputs created before activation. Supporters contend the restrictions would discourage inscriptions and other non-monetary data that increase storage and bandwidth costs for node operators. Critics, including Strategy Executive Chairman Michael Saylor and Blockstream CEO Adam Back, have argued the proposal could divide Bitcoin and cause nodes to reject transactions permitted under the existing rules.

The proposal uses version bit 4 for miner signaling, with its deployment schedule designating blocks 961,632 through 963,647 as the mandatory-signaling window. The specification defines block 963,648 as the start of its locked-in state and block 965,664 as the activation point for its transaction restrictions. On Aug. 1, Bitcoin developer Chris Guida rebased preliminary code for a proof-of-work change originally written by Bitcoin Knots maintainer Luke Dashjr, describing the code at the time as a contingency if miners opposed BIP-110 and noting that no activation date had been set.