BIP 110 specifies temporary consensus limits on output scripts, pushed data, witness and Taproot constructions. It was proposed as a defence of Bitcoin's monetary use and low node costs, but critics argued that data could be re-encoded, legitimate scripts would be constrained, and the activation design could split the network. Publication as a BIP documents a proposal; it does not show consensus or adoption.
During its planned one-year deployment, BIP 110 made seven additional checks: ordinary scriptPubKeys were limited to 34 bytes and OP_RETURN outputs to 83 bytes; OP_PUSHDATA payloads and script-argument witness items to 256 bytes, except a BIP16 redeemScript push; spending undefined witness or Tapleaf versions was invalid; Taproot annexes were forbidden; Taproot control blocks were capped at 257 bytes; OP_SUCCESS opcodes were forbidden in Tapscript; and executed OP_IF or OP_NOTIF was forbidden there. Inputs spending UTXOs created before activation were grandfathered, while the output rule still applied to new outputs.
The deployment used BIP9-style bit 4 signaling, a 55% threshold and a mandatory-signaling window beginning at height 961632. Supporters could activate early through the threshold; otherwise enforcing software would reject non-signaling blocks during the mandatory phase. The restrictions were designed to expire after 52,416 blocks, roughly one year. Signaling is part of this specific state machine, not a general opinion poll about Bitcoin governance.
The author argued that contiguous arbitrary data competes with payments for scarce block space, increases storage and validation burdens, can enlarge the UTXO set through large spendable outputs, and may expose node operators to unwanted content. The proposal sought to keep Bitcoin focused on permissionless money, restore older relay-policy-sized limits at consensus level, and make supported data carriers too small for simple image inscription. These are the proposal's stated aims, not independently proven outcomes.
Opponents showed that the text of the proposal itself could be encoded in a compliant transaction by splitting data across fields, so the limits could raise cost without preventing determined publication. They also objected that consensus restrictions would affect legitimate programmable-money constructions, consume upgrade hooks such as undefined witness versions and OP_SUCCESS, and turn a subjective judgment about spam into global validity rules. The mailing-list record contains further disputes about compatibility, legal framing, activation safety and who bears the risk of a chain split.
At height 961632 on 8 August 2026, Bitcoin's accumulated-work chain accepted a block that did not signal bit 4. BIP-110-enforcing nodes rejected it and followed a signaling OCEAN block, creating a distinct chain tip. That tip produced two blocks while the Bitcoin chain advanced by more than one hundred blocks and then stalled. A proposal to mark BIP 110 Closed was announced on the development list, but an objection was filed and BIP3 calls for a four-week process. As of 10 August 2026 the BIP file still said Complete; 'activated', 'failed', 'deployed' and 'closed' therefore require attribution and date.
For the clearest picture, read this entry together with Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction fees, UTXO. The reverse links also lead from OP_RETURN and null-data outputs.