The 80-Byte Limit

The data capacity of an OP_RETURN output has changed over the years as the Bitcoin community debated the balance between functionality and network health. Today, the 80-byte limit is the "Standardness" rule followed by almost all nodes.

1. Evolution of the Limit

• Early Days: There was no formal limit, but data was rarely used.

• 2013 (v0.9.0): A 40-byte limit was introduced. This was seen as just enough for a single hash.

• 2015 (v0.11.0): The limit was increased to 80 bytes. This allowed for more complex protocols like those used for "Colored Coins" and metadata anchoring.

2. Why not higher?

If OP_RETURN were unlimited, the blockchain would quickly fill up with non-financial data (images, movies, text).

• Bandwidth Cost: Every node in the world has to download and propagate every byte of data.

• Incentive Alignment: Keeping the limit low ensures that Bitcoin remains specialized for high-value financial security rather than generic data storage.

3. "Standard" vs. "Consensus"

It is important to understand that the 80-byte limit is a Standardness Rule, not a Consensus Rule.

• Standardness: Nodes will only "relay" a transaction if the OP_RETURN is 80 bytes or less.

• Consensus: A miner can still include a transaction with a larger OP_RETURN (e.g., 200 bytes) in a block, and other nodes will accept it as valid.

• However, because almost all wallets and nodes follow the 80-byte rule, it is effectively the law for 99% of users.

4. Packing the 80 Bytes

Developers have become incredibly efficient at packing data into these 80 bytes.

• SHA256 Hash: 32 Bytes.

• Protocol Prefix: 4-8 Bytes (e.g., OMNI or DOCS).

• Version/Flags: 1-2 Bytes. Even with 80 bytes, there is often room to spare for simple applications.

Version	Limit	Reasoning
Pre-2013	N/A	Low awareness of data use.
0.9.0	40 Bytes	Protect the UTXO set from bloat.
0.11.0	80 Bytes	Compromise for metadata protocols.

In the next section, we will explain why OP_RETURN is Provably Unspendable.