OP_RETURN: 40 bytes, then 80, then uncapped. History with the blocks to check it

[windpath]

New story on ChainQuery: how Bitcoin's data output came to be, what ran on it, and what changed in October 2025. Every block and transaction it mentions has a Run button that hits our node, so you can check the numbers rather than take them from us.

https://chainquery.com/stories/op-return

The short version of the opcode itself, for anyone who wants that first:
https://www.learnbitcoin.com/glossary/opreturn

What the story covers:

• Before 2014, people who wanted data on chain encoded it as fake addresses. Those outputs can never be spent, so they sit in every node's UTXO set for good.
• Bitcoin Core 0.9.0 (March 2014) made OP_RETURN outputs standard as a prunable alternative, with a 40-byte cap. The release notes called it a relief valve, not an endorsement.
• Core 0.11 (July 2015) raised the cap to 80 bytes, and that number stood for ten years.
• Core 30.0 (October 10, 2025) raised the default to 100,000 bytes and began relaying transactions with more than one OP_RETURN output. Bitcoin Knots kept a small default. None of it is consensus; it is relay policy, and a miner could always include a larger one.
• What ran on it: Counterparty (payload scrambled with ARC4, so the CNTRPRTY tag is only visible after decoding), OpenTimestamps (which timestamped the Internet Archive's 750 million files in one transaction in 2017), Omni, the original home of Tether, and VeriBlock, which at its early-2019 peak was behind up to a fifth of Bitcoin's daily transactions.
• Two getblockstats calls side by side: block 350,000 from March 2015 and block 840,000 from April 2024, plus the full block 800,000 so you can find the nulldata outputs yourself.

If you were around for any of this and we got a detail wrong, say so here. It gets fixed the same day and the correction is credited in the story. The last round of that turned up real mistakes, we greatly appriciate your support and contributions!

[ABCbits]

For Bitcoin's first five years, people who wanted to embed arbitrary data on chain (timestamping services, alt-protocol bootstraps, image enthusiasts) did so by encoding bytes as fake Bitcoin addresses, sending tiny amounts to those addresses, and accepting that the bitcoin would be lost forever.

It's probably better to explicitly mention that this method was probably most popular/used method. There are other method such as P2MS that used by CounterParty and OmniLayer. Here's an example https://classic.tokenscan.io/tx/3089 before Bitcoin 0.9 released.

[windpath]

It's probably better to explicitly mention that this method was probably most popular/used method. There are other method such as P2MS that used by CounterParty and OmniLayer. Here's an example https://classic.tokenscan.io/tx/3089 before Bitcoin 0.9 released.

Fixed, thanks, you are right again! The paragraph now says fake addresses were the common method and bare multisig the other one, used by Counterparty and Mastercoin. Your example went into the story as a Run button: it is in block 283,886 (February 3, 2014), six weeks before 0.9.0, and its first three outputs are 1 <key> <data> 2 OP_CHECKMULTISIG, which Core labels nonstandard because the second key is not a key. The correction note at the bottom credits you.

https://chainquery.com/stories/op-return#p2ms-example