The milestone tests whether supporters can advance a contentious consensus change without broad miner backing, potentially separating enforcing nodes from the dominant chain and escalating a dispute over how Bitcoin’s block space should be used.
BIP-110 seeks temporary limits on Bitcoin data
Written by pseudonymous developer Dathon Ohm, BIP-110 proposes additional consensus restrictions lasting roughly one year.
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, and temporarily limit several Taproot features. Unspent transaction outputs created before activation would be exempt.
Supporters said the restrictions would discourage inscriptions and other non-monetary data that increase storage and bandwidth costs for node operators.
The proposal’s critics, including Strategy Executive Chairman Michael Saylor and Blockstream CEO Adam Back, have argued that the proposal could divide Bitcoin and cause nodes to reject transactions permitted under the network’s existing rules.
The proposal uses version bit 4 for miner signaling. Its deployment schedule sets blocks 961,632 through 963,647 as a mandatory-signaling window, during which nodes enforcing BIP-110 reject blocks that do not carry the signal.
The specification 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.
BIP-110 proponents have also discussed a more extensive fallback. 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 at the time as a contingency if miners opposed BIP-110, but said no activation date had been set.