BIP-110 and OP_RETURN: What Is Bitcoin Really Arguing About?

BIP-110 is a proposed temporary Bitcoin soft fork that would restrict certain ways people can put large amounts of non-payment data into Bitcoin transactions. The fight around it is really a fight over Bitcoin’s purpose: should Bitcoin block space be treated mostly as money settlement space, or should valid fee-paying transactions be accepted even when they carry data that many Bitcoiners dislike?

This is one of those topics where people can talk past each other very quickly. One side hears “spam” and thinks Bitcoin is being slowly turned into a file-storage system. The other side hears “soft fork to stop spam” and worries that Bitcoin is being asked to judge which transactions are morally or socially acceptable.

Both concerns are serious. The problem is deciding which concern should be handled by relay policy, mining policy, wallet choice, social pressure, or a consensus rule.

What is BIP-110?

BIP-110, formally called the Reduced Data Temporary Softfork, is a Bitcoin Improvement Proposal written by Dathon Ohm. Its goal is to temporarily limit the size of certain data fields at the consensus level for one year.

In plain English, it tries to make it much harder to use Bitcoin transactions as a place to store larger chunks of arbitrary data.

The proposal includes several restrictions. The easiest one to understand is the OP_RETURN rule: new output scriptPubKeys larger than 34 bytes would be invalid unless they begin with OP_RETURN, and OP_RETURN outputs would be valid only up to 83 bytes. It also limits certain OP_PUSHDATA payloads and witness items to 256 bytes, restricts some Taproot-related structures, and temporarily disables some upgrade or script paths that supporters believe can be abused for data embedding.

That is a lot of technical language, so reduce it to the basic idea: BIP-110 tries to close several doors that people use, or might use, to put non-money data into Bitcoin.

It is also important that BIP-110 is proposed as temporary. The current BIP text says the restrictions would last for a one-year deployment, with pre-activation UTXOs grandfathered so existing coins are not supposed to be frozen by the new rules.

BIP-110 was first opened in the Bitcoin BIPs repository as pull request #2017 on October 24, 2025. It was assigned as BIP-110 on December 3, 2025. The BIP-110 website also describes it as RDTS and says it was also referred to as BIP-444 before becoming BIP-110.

What is OP_RETURN?

OP_RETURN is a Bitcoin Script opcode that marks an output as provably unspendable. Because that output can never be spent, full nodes do not need to keep it forever in the UTXO set.

That sounds small, but it matters.

Before OP_RETURN became the accepted way to attach small data commitments to transactions, some schemes placed arbitrary data inside outputs that looked unspendable in practice but were not provably prunable in the same clean way. That bloated the UTXO database, which is the set of unspent outputs every full node must track.

Bitcoin Core 0.9.0, released on March 19, 2014, made OP_RETURN data outputs a standard transaction type for relay. The release notes were careful about the reason. They said this was not an endorsement of storing data in the blockchain. The point was to create a provably prunable output so people would stop storing data in more harmful forever-unspendable transaction outputs.

So OP_RETURN was not originally marketed as “Bitcoin should become a database.” It was more like a small trash bin placed in a public park because people were already throwing trash in worse places.

That does not mean everyone liked it. Even then, Bitcoin developers knew data-in-the-chain was controversial. The 0.9.0 release notes said storing arbitrary data in the blockchain was still a bad idea and that non-currency data should be stored elsewhere.

Why did BIP-110 suddenly look necessary to some people?

The support for BIP-110 did not come out of nowhere. It came from years of frustration over inscriptions, Ordinals, token experiments, and other uses that put non-payment data into Bitcoin transactions.

The more immediate trigger was Bitcoin Core 30.0.

Bitcoin Core 30.0 increased the default -datacarriersize setting to 100,000 bytes, which the release notes describe as effectively uncapping the OP_RETURN data size limit because the maximum transaction size would be hit first. It also allowed multiple OP_RETURN outputs in a transaction for relay and mining, with the size limit applying across the aggregate scriptPubKeys.

To supporters of that policy change, this was relay policy. It did not change Bitcoin’s consensus rules. A miner could already include consensus-valid data-heavy transactions if it wanted to. A node operator could still configure stricter relay policy. In that view, Bitcoin Core 30.0 was making default relay behavior more consistent with what consensus already allowed.

To BIP-110 supporters, the same change looked very different. They saw Bitcoin Core 30.0 as standardizing support for arbitrary data and inviting more non-financial use of block space. In their view, once widely used software treats larger OP_RETURN data as normal relay traffic, the network is giving a green light to behavior that should have stayed discouraged.

This is where the disagreement becomes philosophical as much as technical.

If you believe Bitcoin should be hostile to non-money data at every layer, then a consensus rule may look like a defensive wall. If you believe Bitcoin consensus should stay neutral toward any valid fee-paying transaction, then BIP-110 may look like using a sledgehammer because people dislike what some users are doing with their own block space.

That is why this debate became heated so quickly. The two sides are not only arguing about 83 bytes or 100,000 bytes. They are arguing about who gets to decide what Bitcoin is for.

Is BIP-110 only about OP_RETURN?

BIP-110 is connected to OP_RETURN, but it is broader than OP_RETURN.

That point matters because some critics say the proposal bundles too many restrictions together. If the problem is the Bitcoin Core 30.0 OP_RETURN relay policy, they ask why the proposal also touches Taproot annexes, OP_SUCCESS opcodes, undefined witness versions, Taproot control blocks, and OP_IF or OP_NOTIF in Tapscript.

Supporters answer that OP_RETURN is only one obvious data path. If Bitcoin closes only OP_RETURN, data can move into other script and witness structures. In their view, a narrow OP_RETURN-only limit would push the same problem into uglier places.

Critics answer that this is exactly why consensus changes should move slowly. A soft fork that temporarily disables or restricts several script paths may affect future upgrades, advanced smart contract experiments, or edge-case wallet behavior. Even if the risk is small, Bitcoiners usually do not like rushed consensus changes unless the threat is extremely clear.

That is the honest tradeoff. A narrow fix may be too weak. A broad fix may be too risky.

How do we quantify support for BIP-110?

There is no perfect Bitcoin opinion poll. Twitter likes, podcast applause, GitHub comments, and loud Telegram groups do not equal consensus.

A better way to measure BIP-110 support is to separate four different signals.

First, look at miner signaling. BIP-110 uses bit 4 in the block version field. The public BIP-110 monitor says activation requires 55% of blocks in a 2,016-block difficulty period, which means 1,109 signaling blocks in one period. As of July 30, 2026 at 03:26 UTC, the monitor showed 10 signaling blocks out of 587 tracked blocks in the current period, or 1.70%. Across the completed periods tracked since block 937,440, the monitor showed 84 signaling blocks out of 22,176 completed-period blocks, or about 0.38%.

That is the cleanest hard number because miners produce blocks. If the people mining Bitcoin are not signaling, the proposal is not close to miner-driven activation.

Second, look at node adoption. Nodes matter because they verify rules. If a large number of reachable nodes run BIP-110-enforcing software, that shows real user energy. But a node does not mine blocks by itself. A minority of enforcing nodes without miner and economic support can split themselves onto a minority chain rather than change the main chain.

Third, look at economic support. Exchanges, wallets, custodians, payment processors, and major businesses matter because they decide which chain they treat as Bitcoin in practice. This is harder to measure than miner signaling, but public commitments are useful. If major exchanges, large wallets, and big service providers are silent or opposed, that tells you something.

Fourth, look at developer and review support. Bitcoin Core has not merged BIP-110. The BIP repository discussion shows technical review and public disagreement, but publication as a BIP should not be confused with adoption. A BIP can be documented, debated, and still not become Bitcoin.

So the practical scorecard is simple:

1. Miner signaling: measurable and currently very low.
2. Node adoption: meaningful as a user signal, but not enough by itself.
3. Economic support: watch public commitments from exchanges, wallets, and businesses.
4. Developer review: useful for technical quality, but not a vote to activate.

If someone says “many people support BIP-110,” ask which group they mean. Miners? Nodes? Businesses? Developers? Social media followers? Those are different measurements.

What does opposition look like?

Opposition also needs to be measured carefully.

Some people oppose BIP-110 because they like inscriptions or data storage. Some oppose it because they dislike rushed consensus changes. Some oppose it because they think policy should be handled at the relay or mining layer instead. Some oppose it because they believe Bitcoin should remain neutral toward valid fee-paying transactions, even ugly ones.

Michael Saylor argued in July 2026 that BIP-110 turns a spam dispute into a consensus change that would invalidate some currently valid fee-paying transactions. Adam Back also criticized the proposal and warned supporters that if they want different rules without broad agreement, they are effectively choosing a fork.

You do not need to agree with either person to understand the concern. If the rules can change quickly whenever a vocal group identifies an unwanted use case, then every future unwanted use case becomes a political fight over consensus.

At the same time, supporters are not imagining the data problem. Non-financial data really does consume block space. Node operators really do care about the cost and purpose of running nodes. Some people really do not want Bitcoin to become a general-purpose storage layer.

The disagreement is over the cure.

What should regular Bitcoin users watch?

Regular Bitcoin users should watch the numbers more than the noise.

The main number is miner signaling. If BIP-110 stays in the low single digits, it is not close to changing the main Bitcoin chain through miner support. If major pools suddenly begin signaling, the situation changes.

The second thing to watch is whether major economic actors publicly support the BIP-110 chain. Without that, a minority-enforced chain is likely to remain a minority chain.

The third thing to watch is your own software. If you run Bitcoin Knots or any BIP-110-enforcing version, understand exactly what rules your node will enforce during the mandatory signaling window. A node that rejects the blocks most miners are producing may show you a different chain tip than the broader network.

Your coins can still exist on the main chain while your node temporarily follows a different chain tip. That is why software choice matters during a disputed rules window.

Bottom line

BIP-110 is a serious proposal born from a serious concern: Bitcoin block space is being used for more than money, and many Bitcoiners think that trend weakens Bitcoin’s purpose.

The opposition is also serious: changing consensus rules to fight unwanted but valid transactions can create a precedent that may be more dangerous than the spam itself.

The cleanest way to think about it is this: OP_RETURN began as a small, prunable place for limited data because worse data-storage behavior already existed. Bitcoin Core 30.0 widened default relay behavior around OP_RETURN. BIP-110 is the backlash, trying to move limits from policy into consensus for one year.

Whether that becomes Bitcoin depends on measurable support, not volume. Watch miners, nodes, economic actors, and actual software adoption. If those groups do not align, BIP-110 remains a proposal and a debate, not a change to Bitcoin.

Sources

• BIP-110 specification: https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki
• BIP-110 pull request #2017: https://github.com/bitcoin/bips/pull/2017
• BIP-110 live miner signaling monitor: https://bip110monitor.com/
• Bitcoin Core 0.9.0 release notes: https://bitcoin.org/en/release/v0.9.0
• Bitcoin Core 30.0 release notes: https://bitcoincore.org/en/releases/30.0/
• BIP-110 website: https://bip110.org/

Disclaimer: The content on this blog is provided for general informational and educational purposes only and does not constitute financial, investment, legal, or tax advice. Cryptocurrency and Bitcoin investments are highly volatile and involve substantial risk. Mitigate your own risk with your own management practices. Always conduct your own research and consult a qualified professional before making financial decisions. Past performance does not guarantee future results. The author and blog assume no responsibility for losses arising from reliance on this content. Any opinions expressed are the author’s own, and any holdings, sponsorships, or affiliate relationships are disclosed where applicable.