bitcoin op-return bitcoin-core data-storage

Bitcoin's OP_RETURN Renaissance: Core v30.0 Just Unlocked a New Data Layer

bitcoinindex.net · · 8 min read
Bitcoin's OP_RETURN Renaissance: Core v30.0 Just Unlocked a New Data Layer

Bitcoin Core just unlocked a new data layer, and almost nobody noticed. The numbers show it’s already being used.

On October 10, 2025, Bitcoin Core v30.0 quietly raised the OP_RETURN limit from 83 bytes to 100,000 bytes. At the same time, it started allowing multiple OP_RETURN outputs per transaction instead of just one. These weren’t consensus changes. They were mempool policy updates that nodes can adopt independently.

Now we have data. Bitcoin Optech Newsletter published an analysis on February 20, 2026, covering blocks 915,800 to 936,000. That’s roughly four months since the v30.0 release. The findings: 24.4 million OP_RETURN transactions total, with 396 using the expanded limits. That’s 396 transactions with more than 83 bytes or multiple outputs.

I keep thinking about that number. 396 sounds tiny out of 24 million. But it’s a 100x jump from what was possible under the old limit. This is Bitcoin’s data layer quietly waking up.

What is OP_RETURN?

OP_RETURN is a Bitcoin Script opcode that marks a transaction output as provably unspendable. When the Bitcoin virtual machine hits OP_RETURN, it immediately stops and returns false. That output can never be spent, even if you have the private keys.

Why does this exist? Satoshi Nakamoto included it to give people a proper way to store data on the blockchain. Without OP_RETURN, users were encoding data in fake addresses, which bloated the UTXO set that every node has to maintain. OP_RETURN outputs can be pruned immediately because they’re provably unspendable. No permanent UTXO pollution.

The history is short but relevant:

  • Originally disabled entirely
  • Re-enabled in March 2014 (Bitcoin Core 0.9.0) with a 40-byte limit
  • Increased to 80 bytes in February 2015
  • Effectively 83 bytes as of January 2016 (opcode + length byte + data)
  • 100,000 bytes as of October 2025

The critical distinction: Bitcoin’s consensus rules have no hard limit on OP_RETURN size. Any miner can include a transaction with 1MB+ of OP_RETURN data in a valid block, and all nodes will accept it. The 83-byte limit was a policy rule. Bitcoin Core nodes wouldn’t relay transactions above that size or add them to their mempool. Miners running Bitcoin Core by default wouldn’t mine them. But if a miner manually included one, the block was valid.

Bitcoin Core v30.0 changed the policy, not the consensus. Nodes can still set -datacarriersize=83 to revert to the old behavior. This is important because it means the change is opt-in at the relay level.

The numbers

Anthony Towns posted an analysis to Delving Bitcoin breaking down OP_RETURN usage since the v30.0 release. Bitcoin Optech Newsletter picked it up and published the summary.

All OP_RETURN transactions:

  • 24,362,310 transactions with OP_RETURN outputs
  • 473,815,552 bytes of OP_RETURN data (roughly 474 MB)
  • Average: about 19.4 bytes per transaction

Size distribution:

  • 23,412,911 transactions: 42 bytes or less
  • 949,003 transactions: 43 to 83 bytes (near the old limit)
  • 396 transactions: more than 83 bytes total

Multiple outputs:

  • 61 transactions used the new multi-output allowance

The 396 large transactions break down further. Half had less than 210 bytes of OP_RETURN data. 10% had more than 10kB. A few were in the 10 to 100kB range.

Most early adopters are using hundreds of bytes, not maxing out the 100kB limit. But there’s a long tail.

Block space impact

Here’s what I find interesting: OP_RETURN is not causing congestion.

The math: 473.8 MB of OP_RETURN data divided by 20,200 blocks equals about 23.4 KB per block on average. Bitcoin blocks average 1.5 to 2 MB including witness data. OP_RETURN is roughly 1 to 2% of block space.

The 396 large transactions spread across 20,200 blocks means about 0.02 large OP_RETURN transactions per block on average. Large OP_RETURN data is 0.44% of total OP_RETURN volume. Negligible.

The theoretical maximum is different. A 100kB OP_RETURN transaction is about 400,000 weight units. A block can hold 4 million weight units. You could fit about 10 maxed-out OP_RETURN transactions per block if someone wanted to saturate blocks.

But the economics prevent that. OP_RETURN doesn’t get the witness discount. It pays full freight at 4 weight units per byte. Ordinals inscriptions pay 1 weight unit per witness byte. OP_RETURN is 4x more expensive per byte than Ordinals for data storage. A 100kB OP_RETURN transaction at 10 sat/vB costs 1 million sats, or about $450 at $45k BTC.

Nobody is spamming the chain with 100kB OP_RETURNs at those prices. The fee market works.

Use cases

What are people storing?

Timestamping is the most established use case. OpenTimestamps anchors Merkle roots of timestamped documents to the Bitcoin blockchain. You hash a file, submit it to the OTS calendar server, the server batches hashes into a Merkle tree, and commits the root to an OP_RETURN output. One transaction can timestamp thousands of files. Use cases include legal documents, software releases (git commits), journalism, and research data.

Data anchoring stores hashes of off-chain data. IPFS content IDs, SHA-256 digests, anything that proves the existence of data at a specific time without storing the full data on-chain. Supply chain provenance, audit logs, regulatory compliance records.

Colored coins and asset metadata were early users of OP_RETURN. Protocols like Counterparty and Omni Layer used it to encode asset issuance and transfers. The modern RGB protocol (client-side validation) uses OP_RETURN for state commitments.

Decentralized publishing is the emerging category. With 83 bytes, you could store a hash and maybe a tiny identifier. With 100kB, you can store entire blog posts, small PDFs, or rich metadata records. Censorship-resistant publishing becomes viable.

Ordinals alternative is the speculative one. Ordinals inscriptions store data in Taproot witness fields, exploiting the witness discount for cheaper per-byte cost. OP_RETURN is the “proper” way to store data on Bitcoin. It uses the mechanism explicitly designed for it. Before v30.0, 83 bytes was too small for most inscription content. Now 100kB makes OP_RETURN viable for many use cases, though it’s still more expensive per byte.

OP_RETURN versus Ordinals

This is where the politics get messy.

OP_RETURN is provably unspendable. It doesn’t create UTXOs. It’s explicitly designed for data storage. It pays full weight units per byte.

Ordinals inscriptions use Taproot witness data. They create spendable outputs (though they’re usually not spent). They pollute the UTXO set. They get the 75% witness discount, making them 4x cheaper per byte. They can be much larger (hundreds of kilobytes, limited only by max transaction size).

Many Bitcoin developers who opposed Ordinals as “spam” support expanded OP_RETURN limits. The argument: if data storage is happening anyway, better to use the mechanism Bitcoin provides. OP_RETURN doesn’t bloat the UTXO set. It’s cleaner.

The counterargument: both store data on-chain. Both consume block space. Calling one “legitimate” and the other “spam” is arbitrary. Bitcoin consensus allows both. The fee market should decide.

I’m genuinely unsure where I land on this. OP_RETURN is technically cleaner. But the witness discount makes Ordinals cheaper, which is why they dominate. If OP_RETURN becomes culturally accepted while Ordinals remain controversial, will inscribers migrate? Probably not, because economics win. Unless the witness discount policy changes, Ordinals will stay cheaper.

The controversy

This policy change didn’t happen without drama.

In September and October 2025, early release candidates for Bitcoin Core v30.0 planned to deprecate the user configurability of -datacarriersize. That would have forced nodes to either accept the new 100kB limit or manually patch the code. Bitcoin Core maintainer Luke Dashjr, who maintains the more conservative Bitcoin Knots fork, warned of “forced settings” and “legal nightmares.”

Community backlash followed. Node operators wanted to retain control over what their nodes relay. Hours before the October release, Bitcoin Core maintainer Ava Chow restored user configurability. The final v30.0 shipped with -datacarriersize fully configurable, not deprecated.

This reflects a deeper ideological divide. Bitcoin purists argue that Bitcoin is peer-to-peer electronic cash, not a file storage system. Block space is scarce and should be reserved for financial transactions. Pragmatists argue that if people want to store data, better to use OP_RETURN than to encode it in fake addresses. Let the fee market decide what’s valuable.

Bitcoin Knots defaults to -datacarriersize=42, even more restrictive than the old Bitcoin Core limit. Bitcoin Core v30.0 defaults to -datacarriersize=100000. Both are valid implementations. The market will decide which nodes and miners run what.

What happens next

We’re in the early stage. 396 transactions using expanded limits over four months is not a revolution. It’s a data point.

The trajectory could go several ways. Gradual adoption seems most likely. Applications emerge that use 1 to 10kB OP_RETURN payloads. Timestamping services expand to store richer metadata. Data anchoring for compliance and audit use cases grows. OP_RETURN remains under 5% of block space.

Ordinals migration is possible but unlikely. Economic incentives favor Ordinals unless the cultural or policy environment shifts hard against witness data storage.

Policy tightening could happen if large OP_RETURN transactions cause block congestion or community backlash. A future Bitcoin Core release could reduce the default -datacarriersize. But it would likely face the same backlash as the deprecation attempt.

The fourth scenario: nothing significant changes. The 100kB limit remains available but rarely used. Fee economics prevent spam. OP_RETURN stays a niche feature for specific applications.

I’m watching for new projects. Potential use cases include censorship-resistant publishing platforms (store article metadata on-chain, content on IPFS), decentralized certificate authorities (SSL/TLS cert revocation lists), supply chain transparency tools (product provenance hashes), and regulatory compliance solutions (audit log commitments for financial institutions).

No major applications have been announced yet as of February 2026. The community is waiting to see if expanded limits enable new use cases. Build it and they will come, or no demand for 100kB OP_RETURNs. Time will tell.

The bigger question

Bitcoin’s data storage history is messy. Fake addresses polluted the UTXO set. OP_RETURN was introduced as the proper solution. SegWit witness data enabled unintended large data storage. Taproot scripts unlocked Ordinals, which exploited the witness discount. Now expanded OP_RETURN is the “clean” method with higher limits.

Each iteration reflects the same tension: is Bitcoin strictly for financial transactions, or is it a programmable settlement layer?

The v30.0 change is a quiet infrastructure upgrade. It might enable new Bitcoin use cases. It might remain a niche feature. The 396 transactions using expanded limits are early signals, not a trend.

But here’s what sticks with me: Bitcoin Core just made it possible to store 100kB of data in a provably unspendable output, and the network didn’t break. Block space consumption is negligible. Fee economics are working. The infrastructure is there.

Now we wait to see if anyone builds on it.

Sources: Bitcoin Optech Newsletter #393, Anthony Towns: Recent OP_RETURN output statistics, Bitcoin Core v30.0 Release Notes, Murch’s OP_RETURN Dashboard, Mempool.space OP_RETURN Report. Data as of February 22, 2026.