The 80-Byte OP_RETURN Limit Explained

20. The 80-Byte OP_RETURN Limit Explained

Overview

Bitcoin Core enforces a standardness rule that limits the data payload of OP_RETURN outputs to a maximum of 80 bytes. Transactions violating this limit are considered non-standard and are not relayed by default Bitcoin Core nodes or included in Bitcoin Core's mempool, although they are technically valid at the consensus level and can still appear in mined blocks.

The 80-Byte Limit in Detail

The 80-byte limit applies to the total data payload — everything that follows the OP_RETURN opcode in the scriptPubKey:

OP_RETURN <data>

Where len(data) must be <= 80 bytes for standardness.

The data portion includes any push opcodes and their data:
  6a 01 ff           --> 1 byte payload (OK, ≤80)
  6a 4c 50 <80 bytes> --> 80 bytes via OP_PUSHDATA1 (OK, exactly 80)
  6a 4c 51 <81 bytes> --> 81 bytes (NON-STANDARD)

Importantly, the 80-byte limit is on the data content itself — the OP_RETURN opcode byte itself and any push opcode prefixes do not count toward the limit.

Historical Evolution of the Limit

The OP_RETURN data limit has changed several times in Bitcoin's history:

Before Bitcoin Core 0.9.0:
  OP_RETURN outputs were completely non-standard.
  Any OP_RETURN output would be rejected from the mempool.

Bitcoin Core 0.9.0 (March 2014):
  OP_RETURN outputs standardized.
  Data limit: 40 bytes.

Bitcoin Core 0.11.0 (July 2015):
  Data limit increased: 80 bytes.
  Reasoning: Allow more useful data embedding while keeping
  outputs small enough to avoid UTXO set bloat.

Current (Bitcoin Core 0.12+):
  Data limit: 80 bytes (unchanged).
  Only ONE OP_RETURN output allowed per standard transaction.

Why 80 Bytes?

The choice of 80 bytes was based on several considerations:

1. Hash accommodation: SHA256 produces 32-byte hashes. A 64-byte payload can hold two SHA256 hashes, plus 16 bytes of metadata — useful for two-hash commitment schemes. 80 bytes allows for a 32-byte hash plus significant metadata or a 64-byte hash (SHA512 or combined) plus 16 bytes of metadata.

2. Metadata protocols: Many data-embedding protocols need a 4–8 byte magic prefix for protocol identification, leaving 72–76 bytes for actual content. 80 bytes accommodates most such schemes comfortably.

3. UTXO set impact: Since OP_RETURN outputs are pruned from the UTXO set, the 80-byte limit is less about UTXO bloat and more about preventing unreasonable transaction size growth and blockchain bloat.

4. Block space economics: Larger OP_RETURN payloads compete with regular financial transactions for block space. The 80-byte limit was judged to be a reasonable cap that enables legitimate use cases without incentivizing blockchain-as-file-storage abuse.

One OP_RETURN Per Transaction

Bitcoin Core also enforces a standardness rule of only one OP_RETURN output per transaction:

Standard transaction:
  - At most 1 OP_RETURN output
  - OP_RETURN output value must be 0

Transaction with 2 OP_RETURN outputs:
  - NON-STANDARD (rejected by default mempool)
  - Consensus-valid (can be mined)

This rule prevents transactions from being used as arbitrary data dump vehicles. A single 80-byte OP_RETURN per transaction is seen as a reasonable cost for one "annotation" while not enabling bulk data storage.

Bypassing the Limit

The 80-byte limit is a standardness rule, not a consensus rule. Miners can and do include non-standard transactions if they wish. Several mining pools and alternative node implementations relay non-standard transactions under certain conditions.

Protocols like Ordinals bypass the OP_RETURN limit entirely by using a different mechanism — they embed data in Bitcoin Script witness data (the OP_FALSE OP_IF ... OP_ENDIF pattern in Taproot script path spending), which has no equivalent size restriction:

Ordinals inscription envelope (witness data):
  OP_FALSE
  OP_IF
    OP_PUSH "ord"        -- protocol marker
    OP_PUSH 1            -- field marker (content-type)
    OP_PUSH "image/png"  -- content type
    OP_PUSH 0            -- field separator
    OP_PUSH <chunk1>     -- data chunk 1
    OP_PUSH <chunk2>     -- data chunk 2
    ...
  OP_ENDIF

This witness-based approach can embed arbitrarily large data (limited only by block weight), which has sparked significant controversy in the Bitcoin community about appropriate uses of block space.

Summary of OP_RETURN Economics

Parameter                    Value
--------------------------   -----
OP_RETURN output value:      0 satoshis (standard)
Max data payload:            80 bytes (standardness rule)
Max OP_RETURN outputs/tx:    1 (standardness rule)
UTXO set impact:             None (pruned immediately)
Blockchain footprint:        Stored in block permanently
Fee cost:                    ~80 satoshis/byte at minimum fee rate
                             = ~4800 satoshis for 60-byte payload
                             at 1 sat/vbyte

The fundamental tradeoff is that OP_RETURN data persists in the Bitcoin blockchain forever (as part of the transaction history), but does not burden the UTXO set. Users pay block space fees for the permanence, and Bitcoin's fee market naturally limits abuse by making excessive data embedding expensive.

**

**