The OP_RETURN debate is at the center of BIP 110. But most people don’t know the history of how we got here.
Here’s a brief history of OP_RETURN in Bitcoin, from the beginning to the present controversy.
2009 – 2014: The Early Years
OP_RETURN exists from the very beginning of Bitcoin — it’s in the original code. But for the first five years, it was non-standard. Bitcoin Core nodes wouldn’t relay or mine transactions containing OP_RETURN outputs. If you wanted to embed data on the blockchain, you had to use workarounds like putting data in the coinbase transaction or using addresses that looked like valid Bitcoin addresses but weren’t.
2014 (Core 0.9): Standardization
Bitcoin Core 0.9 standardized OP_RETURN with a 40-byte relay default. The purpose was clear: provide a clean, non-consensus way to timestamp hashes and make small commitments on the blockchain. 40 bytes is enough for a SHA-256 hash. The idea was to give people a legitimate outlet for data embedding so they’d stop using abusive methods that bloated the UTXO set.
2015 (Core 0.11): 40 → 80 Bytes
The relay default was raised from 40 to 80 bytes. This allowed for more complex commitments — multiple hashes, small metadata payloads, and early protocol experiments. Still, this was relay policy, not consensus. Miners could still include larger OP_RETURNs if they wanted to.
2016 (Core 0.12): 83 Script Bytes
The relay default became 83 script bytes — which works out to about 80 bytes of actual payload. This was a technical adjustment based on how the script system encodes data. This 80-byte limit stood for nearly a decade. It was enough for basic use cases but restrictive enough to prevent spam.
2025 (Core 30.0): The Big Change
Bitcoin Core 30.0 changed the default relay policy dramatically: multiple OP_RETURN outputs became standard, and up to 100,000 bytes of total OP_RETURN data was allowed. This was a massive increase — from 80 bytes to 100,000 bytes. The rationale was that relay policy shouldn’t restrict innovation, and that the free market of block space should decide what’s valuable.
2026: BIP 110
BIP 110 was proposed as a temporary soft-fork to restore the old 83-byte OP_RETURN limit at the consensus level. Not just relay policy — actual consensus. The argument: 100,000 bytes of arbitrary data per transaction is spam that degrades Bitcoin’s value as sound money.
The counter-argument: changing consensus to police transaction content is a dangerous precedent that contradicts Bitcoin’s permissionless nature.
The Key Distinction
Before 2025, OP_RETURN limits were relay policy — miners could include bigger OP_RETURNs if they wanted to. After BIP 110, it would be consensus policy — enforced by every node, no exceptions. This is a fundamental difference. Relay policy is a node operator’s choice. Consensus is a rule everyone must follow.
Adam Back’s TCP/IP test applies here: could you stop spam by modifying TCP/IP? No, because the internet is permissionless. Bitcoin is the same. If you don’t like what people put in their transactions, don’t mine them. Don’t relay them. But don’t change the rules for everyone.
The debate continues. Bitcoin’s immune system is working. And the history of OP_RETURN shows that Bitcoin has always found a way to balance innovation with security — without breaking what makes it special.
A BRIEF HISTORY OF OP_RETURN — FROM 40 BYTES TO 100,000 AND THE BATTLE OVER BIP 110
