OP_RETURN

An output whose script starts with 0x6a can never be spent by anyone, so full nodes drop it from the UTXO set they have to keep at hand. Bitcoin Core 0.9.0 made such outputs standard in March 2014 with a 40-byte allowance, raised to 80 bytes of payload in 0.11.0. If you are buying and holding, you will never need to create one, but you pay for other people's through the fee market.

How it works

OP_RETURN fails the script the instant it is reached. Nothing can satisfy an output locked that way, and unlike a burn address, where coins are sent to a hash nobody has the key for, the impossibility is visible to software rather than merely likely. That visibility is the whole point: a node maintains an index of every spendable output, and an output that can be proven dead never has to enter it.

Wallets that build one set its value to zero and put the payload after the opcode, usually as a single push. The result is a transaction with a normal output paying somebody and a second output that carries bytes and no money.

The opcode's first version was a disaster. In 2010 an input script and an output script were run joined together, and OP_RETURN ended evaluation reporting success, so a spender could append it and walk away with coins belonging to someone else. The fix that year both separated the two halves of execution and turned the opcode into an unconditional failure. Its modern use as a data carrier came four years later, once developers were already stuffing data into fake public keys that nodes could never prune.

Relay limits followed, and none of them were consensus rules. Bitcoin Core shipped a standard 40-byte carrier in version 0.9.0, doubled the allowance to 80 bytes in 0.11.0 in July 2015, and permitted one such output per transaction. Version 30.0 removed the default size cap and the one-output rule after a long and bad-tempered public argument, on the reasoning that the limits were trivially bypassed and pushed data into worse places. Bitcoin Knots kept the stricter defaults, and the split in node policy is one of the live disagreements in bitcoin today.

Why this matters when you buy bitcoin

You will never be asked to create an OP_RETURN output, and if a website tells you to send bitcoin to one, it is a scam: there is nothing to send to. Some exchanges and chains use memo fields, but a bitcoin withdrawal never needs one.

What reaches you is the fee. Data written on-chain competes with your withdrawal for the same limited space, and the effect is measurable. Block 840,000, mined on April 20, 2024, collected roughly 37.6 bitcoin in fees, the highest of any block to date, because a new token protocol activated at that exact height and thousands of people raced to write into it. Anyone who happened to withdraw from an exchange that afternoon paid several times the going rate for the privilege.

The defence is timing rather than outrage. Fees swing by an order of magnitude within a single week, so consolidating your coins, moving them off an exchange, or making any non-urgent transfer on a quiet weekend costs a fraction of what the same transfer costs during a data rush. Wallets that let you set your own fee rate, rather than guessing on your behalf, are worth preferring for exactly this reason. If you feel strongly about the policy question, running Bitcoin Knots instead of Bitcoin Core is the direct way to register it, since relay policy is chosen by every node operator individually.

Worked example: what 80 bytes costs

A maximum-size legacy carrier output is 92 bytes on the wire: 8 bytes of value that is set to zero, one byte for the script length, then 83 script bytes made of the opcode, a push instruction, a length byte and 80 bytes of payload. None of that is witness data, so each byte counts four weight units, giving 368 weight units or 92 virtual bytes. At 10 satoshis per virtual byte that is 920 satoshis before the rest of the transaction is counted.

For comparison, an ordinary native SegWit output is 31 bytes, or 31 virtual bytes, so the data output costs three times as much as paying somebody. Data has never been free, and the fee market is the only rationing mechanism bitcoin has.

OP_RETURN vs Null data transaction

OP_RETURN is the opcode; a null data transaction is what Bitcoin Core calls the whole transaction pattern once one of these outputs appears in it. The software reports the output type as "nulldata" in the decoded JSON, and that string is what block explorers usually surface. The distinction is small but it stops a common misreading: a null data transaction is not a transaction that moves no money. It nearly always pays somebody as well, with the data riding along in a second output.

OP_RETURN vs Inscription

Inscriptions do not use OP_RETURN at all, which is the source of endless confusion about bitcoin data storage. The ordinals scheme, released in January 2023, hides content inside a Taproot script branch that is never executed, and that branch lives in the witness where each byte costs one weight unit instead of four. The practical consequence is scale. An OP_RETURN payload was capped by relay policy at 80 bytes for a decade, while a single inscription can approach the size of an entire block at a quarter of the weight cost per byte. Runes, launched in April 2024, went the other way and deliberately encodes its protocol messages in OP_RETURN, which is why the two arguments about data on bitcoin are really arguments about two different mechanisms.