BIP-110
BIP-110, formally titled "Bitcoin Improvement Proposal 110" was a proposed Bitcoin soft fork that would impose temporary consensus-level restrictions on the size of data fields in Bitcoin transactions. Authored under the pseudonym Dathon Ohm and assigned on 3 December 2025, the proposal sought to correct what its author described as distorted incentives created by the standardization of arbitrary data storage on the network, refocusing Bitcoin on its monetary function through a set of restrictions designed to lapse automatically after roughly one year.[1]
Overview
BIP-110 grew out of a long-running dispute in the Bitcoin community over the embedding of non-financial data in transactions. The proposal traced the origin of the problem to what it called the "inscription hack," first exploited in 2022, which began a trend of storing arbitrary content such as images, text, and token metadata inside transaction fields.[1] From 2023 onward, protocols including Ordinals, Runes, and the BRC-20 token standard used these fields to store non-payment content at scale.[2]
The author argued that embedding arbitrary data placed significant burdens on node operators, diverted development focus away from Bitcoin's monetary purpose, made transactions more costly, encouraged reliance on third-party payment processors, and increased censorship risk. The stated aim of the intervention was to reject the standardization of data storage at the consensus level by temporarily invalidating several methods of "data abuse" while leaving all known monetary use cases functional.[1]
The proposal ran directly counter to a change made in Bitcoin Core v30, released in October 2025, which raised a data limit from 83 bytes to 100,000 bytes. BIP-110 would have reversed that change and gone considerably further by imposing much smaller limits.[2] [4]
Specification
The seven rules were:
- New output scriptPubKeys exceeding 34 bytes would be invalid, unless the first opcode was OP_RETURN, in which case up to 83 bytes remained valid.
- OP_PUSHDATA payloads and script-argument witness items exceeding 256 bytes would be invalid, except for the redeemScript push in BIP16 scriptSigs.
- Spending undefined witness or Tapleaf versions would be invalid, though creating outputs with undefined witness versions remained valid.
- Witness stacks containing a Taproot annex would be invalid.
- Taproot control blocks larger than 257 bytes — corresponding to a merkle tree with 128 script leaves — would be invalid.
- Tapscripts including any OP_SUCCESS opcode, even unexecuted, would be invalid.
- Tapscripts executing OP_IF or OP_NOTIF, regardless of result, would be invalid.[1] [4]
Rationale for the Limits
The author justified the 34-byte scriptPubKey cap on the grounds that unspent scriptPubKeys must be stored indefinitely in the UTXO (unspent transaction output) set on fast media, usually RAM, and that large scriptPubKeys cause UTXO-set bloat and potential "poison blocks" that take a long time to validate. OP_RETURN outputs, which are provably unspendable and therefore not stored in the UTXO set, were historically tolerated up to 83 bytes and were preserved to avoid breaking legacy protocols.[1]
The 256-byte and 257-byte caps were defended by the argument that modern compression can represent images in 300–400 bytes, while 256 bytes (2,048 bits) is sufficient for reasonably large numbers used in legitimate cryptography; the limit was intended to deter image embedding and reduce abuse.[1]
The prohibition on OP_IF and OP_NOTIF rested on the claim that these opcodes are redundant with Taproot's off-chain script evaluation and that OP_IF is commonly abused to inject spam that is skipped during execution. The author argued that the temporary loss of these upgrade hooks was not a practical issue because soft forks typically take at least a year to coordinate.[1]
For rule 3, the specification enumerated the witness versions that would remain spendable: version 0 with a 20-byte program (P2WPKH) or a 32-byte program (P2WSH) under BIP 141; version 1 with a 32-byte program (Taproot/P2TR) under BIP 341, with the only defined Tapleaf version being 0xc0 (Tapscript) under BIP 342; and version 1 with the 2-byte program 0x4e73 (the ephemeral anchor output P2A defined in BIP 433), spendable only with an empty witness stack.[1] [4]
Deployment Mechanism
BIP-110 used a modified version of the BIP 9 miner-signaling mechanism, under the GetBlockTemplate deployment name "reduced_data" and signaling bit 4.[1]
The mechanism deviated from standard BIP 9 in several ways. It used a reduced activation threshold of 1,109 out of every 2,016 blocks (55%) rather than the customary 95%, justified on the basis that the soft fork was temporary and urgent. Instead of a conventional timeout, it relied on the maximum activation height, transitioning to a LOCKED_IN state at height 963,648 and then to ACTIVE at 965,664.[1]
The deployment also introduced a new terminal state, EXPIRED, entered once the block height reached the activation height plus the active duration, after which the rules ceased to be enforced automatically. The full state machine ran DEFINED → STARTED → LOCKED_IN → ACTIVE → EXPIRED, with the FAILED state never reached because the timeout was disabled, and miner signaling after expiry having no effect.[1][3]
Activation and Chain Split
The mandatory signaling window opened at block 961,632, dated by independent reporting to 7 August 2026 and by the proposal's own site to 8 August 2026 at 20:12 UTC.[2] From that height, BIP-110-enforcing nodes began rejecting any block that did not signal support, which caused those nodes to split off onto a minority chain.[2]
Miner support was far below the 55% requirement. In the difficulty period preceding the window, only 51 of 2,016 blocks — 2.53% — signaled support.[2] Barefoot Mining, operating through Ocean Pool, had mined the first BIP-110 signaling block on 1 March 2026 and was described as the only organized signaling effort; F2Pool publicly refused to signal, and as of July 2026 no other major pool had joined, leaving support below 1% of total hashrate.[2]
The proposal's own site, by contrast, reported the fork as having activated, stating that additional transaction rules became active at block 961,640 on 30 August 2026 alongside a hard fork named Blake2b, and that Bitcoin nodes such as Bitcoin Knots v29.4.1 continued running and mining new blocks. The BIP's status, however, was formally changed to "Closed" on 9 August 2026 following the chain split and stalled mining, after having been advanced to "Complete" as version 1.0.0 on 25 June 2026.[1] The rules, had they held, were scheduled to expire around 1 September 2027, when all restrictions would lift automatically.
Reception and Opposition
BIP-110's authorship was credited to the pseudonym Dathon Ohm, with the long-standing Bitcoin Core contributor Luke Dashjr credited for the original draft and technical input. Dashjr publicly defended the proposal and rejected calls for its withdrawal.[2][1]
Proponents argued that Bitcoin was designed as peer-to-peer electronic cash and that block space should serve that purpose, contending that Ordinals and Runes activity can spike fees — with peak periods driving average fees above $100 per transaction — and describing the one-year limit as a cooling-off pe riod to buy time for longer-term solutions.[2]
Opposition fell into several categories. On economic grounds, critics held that a fee-paying transaction is legitimate and that restricting access sets a dangerous precedent, a position associated in part with Michael Saylor, who described BIP-110 as Bitcoin's "biggest self-inflicted risk." On technical grounds, Adam Back and others identified what they considered fatal design flaws in the activation mechanism, byte limits, and workarounds, with Back describing multiple components as individually "fatal." On governance grounds, Bitcoin Core v30's opposite change was read as a signal of the absence of broad developer consensus, and Bitcoin Core maintainers did not endorse the proposal. On security grounds, opponents warned that reducing fee revenue from Ordinals and Runes could affect miner economics and long-term network security as block subsidies halve.[2]
