What Is BIP-110? A Plain-English Guide to Bitcoin’s Reduced-Data Proposal

What is BIP-110 and what did it propose?

BIP-110, titled Reduced Data Temporary Softfork, described a one-year set of additional Bitcoin consensus rules. The stated aim was to limit several methods of embedding large amounts of non-payment data in Bitcoin transactions. Its author argued that unrestricted data storage places continuing cost on node operators and competes with Bitcoin’s monetary use.

The proposal was publicly discussed on the Bitcoin Development mailing list in October 2025. The current official BIP-110 specification records an initial draft dated 24 October 2025, assignment on 3 December 2025 and closure on 9 August 2026.

A BIP is a technical proposal and record. Assignment of a number does not prove broad agreement, software adoption or mainnet activation. This distinction matters especially for BIP-110 because the proposal was contentious from its first public discussion.

Why BIP-110 was a soft fork, not a hard fork

A soft fork tightens the rules. Blocks valid under the new rules remain valid under the old rules, but some blocks accepted by old nodes are rejected by upgraded nodes. A hard fork normally expands or changes validity so that blocks accepted by upgraded nodes may be rejected by old nodes.

BIP-110 proposed extra restrictions. An enforcing node would reject certain transactions and blocks that an ordinary older node could accept. That makes its protocol classification a consensus soft fork.

The classification does not guarantee a smooth outcome. If part of the mining network enforces stricter rules while another part mines blocks that break them, the groups may build different chain tips. Users can then experience confirmation uncertainty, reorganisations or a minority chain that stops progressing. That practical disruption can resemble a hard-fork event even though the rule change itself is a soft fork.

What the proposal would restrict

The final BIP text lists seven additional checks for blocks during the temporary deployment. In simplified terms, they covered the following areas.

The specification included exceptions and definitions that matter to implementation. For example, scripts themselves were treated differently from script arguments, and certain defined witness programmes were listed by reference to SegWit, Taproot, Tapscript and P2A.

Why BIP-110 was proposed

The supporting argument began with node cost and Bitcoin’s intended scope. A miner receives the fee for including a transaction once, while every validating node may be required to download, verify and retain the resulting chain data. The BIP author argued that this difference creates distorted incentives for permanent arbitrary-data storage.

The proposal also argued that large output scripts can increase the UTXO set, which nodes need to access efficiently, and that some future-upgrade features were being used for data before they had a defined consensus purpose. Supporters therefore saw temporary restrictions as a way to preserve lower node-operating costs and keep block space focused on payments.

Opponents challenged both the technical effectiveness and the premise. The mailing-list discussion pointed out that determined users can split, transform or disguise data, and that neutral transaction rules avoid subjective judgements about permitted use. Other contributors questioned whether consensus rules were the right layer when relay policy, encoding or fee incentives could be changed without creating incompatible block validation.

This is why a balanced article should not reduce BIP-110 to “stopping spam”. It was a disagreement about consensus scope, node externalities, upgrade space, censorship resistance, activation safety and who gets to define supported use.

What BIP-110 meant for miners, nodes and users

Miners and pools

An enforcing pool would need block-template software that excludes transactions breaking the temporary rules. The BIP used the deployment name reduced_data and version bit 4. During its proposed mandatory-signalling window, that bit would also be required in GetBlockTemplate output. A miner using an incompatible pool, proxy or custom template path could therefore produce work for a chain that other enforcing participants rejected.

ASIC hardware itself does not decide Bitcoin consensus. The pool, node, template generator and any job-negotiation infrastructure determine which candidate block is built. Operators should separate a miner’s SHA-256 performance from the software and payout path directing its work. Our Stratum V2 guide explains why pool protocol and transaction selection are separate from the ASIC’s hashing function.

Node operators

A node that implemented BIP-110 would enforce the additional checks only during the intended active period. The proposal included grandfathering for UTXOs created before activation, designed to reduce the risk that existing coins became unspendable under the temporary rules. That protection did not remove every theoretical wallet or pre-signed-transaction risk.

Wallets and businesses

Ordinary payment users were not the proposal’s target, but businesses cannot treat a disputed chain as an abstract developer matter. Exchanges, merchants, custodians and mining operators need a defined confirmation policy, node software policy and incident plan when network participants may disagree about valid blocks.

BIP-110 timeline and status

• 24 October 2025: the official changelog records the initial draft.
• 26 October 2025: the proposal appeared publicly on the Bitcoin Development mailing list.
• 25 November 2025: the draft adopted modified BIP9 mechanics, a 55% threshold, a maximum activation height and a temporary active period.
• 3 December 2025: the proposal was assigned BIP number 110.
• 25 June 2026: its changelog advanced the document to Complete.
• 9 August 2026: the official record marked it Closed, stating that this followed a chain split with stalled mining.

The current status is therefore closed. BIP-110 should not be described as an active Bitcoin mainnet rule or a successfully deployed upgrade. Its value now is historical and technical: it provides a case study in contentious soft-fork design, miner signalling and the difference between a proposal’s classification and its network outcome.

Common BIP-110 misconceptions

• “It was a hard fork.” No. The proposed rules were stricter, so the technical mechanism was a soft fork. A chain split was a possible and ultimately recorded operational outcome.
• “A BIP number means Bitcoin adopted it.” No. A BIP number identifies a proposal. It does not demonstrate economic consensus or deployment.
• “It banned every token or inscription.” No. The proposal restricted several data-carrying mechanisms, but its own text acknowledged that arbitrary data cannot be eliminated completely.
• “Fifty-five per cent of hashrate guarantees consensus.” No. Hashrate signalling is not the same as acceptance by users, businesses, wallets, exchanges and node operators.
• “ASIC owners needed new chips.” No. Consensus enforcement and block-template construction happen in node and pool software. SHA-256 ASIC hardware would still calculate hashes.

BIP-110 questions

Did BIP-110 activate on Bitcoin?

The official BIP is now Closed and says the closure followed a chain split with stalled mining. It should not be presented as a normal active Bitcoin consensus rule.

Was BIP-110 aimed only at OP_RETURN?

No. OP_RETURN was one part. The rules also addressed output-script length, data pushes, witness items, undefined witness versions, the Taproot annex, control-block size, OP_SUCCESS and conditional Tapscript execution.

Would older nodes automatically reject BIP-110 blocks?

Blocks obeying the stricter rules would normally remain valid under older rules. The danger arises when non-enforcing miners produce blocks that enforcing nodes reject.

Why was the 55% threshold controversial?

It allowed lock-in with far less than the 95% threshold commonly associated with BIP9 deployments. A narrow signalling majority leaves substantial hashrate and economic participants potentially outside the enforcing set.

Does BIP-110 change mining profitability?

Not directly through ASIC efficiency or subsidy. A disputed activation could affect transaction selection, fees, stale work, confirmations, pool continuity and payout risk, all of which matter operationally.

Conclusion

What is BIP-110 in one sentence? It was a proposed temporary soft fork, not a conventional hard fork and not an adopted Bitcoin upgrade. It tried to restrict several forms of large arbitrary data by narrowing block-validity rules for one year. The proposal combined a broad technical rule set with an unusually low 55% signalling threshold and mandatory signalling, so chain-split risk was part of the design discussion from the start.

For miners, the lasting lesson is that consensus disputes live above the ASIC. Pool software, nodes, templates, version bits, confirmation policy and payout controls decide which chain an operator supports and whether its work is accepted. Read the current specification and status directly, distinguish proposal dates from activation claims, and never treat hashrate signalling alone as proof of network consensus.