History of OP_RETURN

Revision as of 11:55, 7 February 2021 by Brendan (talk | contribs) (→‎OP_RETURN in BSV)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The OP_RETURN opcode has seen historical changes to its functionality that have resulted in it being used as the primary mechanism to store arbitrary data on-chain.

Its original functionality was as a return operation that ends execution of the script prematurely, with the topmost stack item presented as the execution result.

The original implementation of the opcode created an easily exploitable vulnerability which was quickly patched by Satoshi Nakamoto.

1 RETURN Exploit

OP_RETURN was originally intended to terminate the script, presenting the top value on the stack as the result of the execution.

Given the script:


True would be returned from the script and the script would terminate, ignoring any opcodes that came afterwards; because of this, this example script could prepend any unlocking script, granting the ability for one to steal anyone's Bitcoin.

The functionality of the opcode was changed to always return false instead of returning the value on top of the stack.

Further changes to OP_RETURN functionality

In Bitcoin Core's v0.9.0 update, the 'OP_RETURN output' script was made into a standard output type, allowing users to append data to unspendable transaction outputs. The amount of data usable in these scripts was first limited to 40 bytes, and then later increased to an 80 byte limit.

Storing data on-chain

The modification to OP_RETURN to always return false had interesting implications. Any opcodes or data are not evaluated after the OP_RETURN so users of the network began using this opcode to store arbitrary data.

This opcode was used instead of the OP_PUSHDATA opcodes since the max script size was limited to 520 bytes. These two fundamental changes to Bitcoin resulted in the opcode being used in an unforeseen and interesting way, outside of its original intent.


During the period while Bitcoin was more widely known as Bitcoin Cash (BCH), the length of data able to be appended to OP_RETURN outputs was extended to 220 bytes, allowing for the creation of larger data items and promoting its use in novel ways such as the creation of social media posting services and more.


For a short while after the network was transitioned to a majority of nodes running the BitcoinSV node client, the 220 byte limit was retained for a short period. Then, in January 2019, it was shown that since the OP_RETURN opcode terminated scripts in such a way that nodes did not validate any subsequent opcodes, that nodes also did not check that the script was within the max script size limit of 520 bytes. This was communicated to node operators on the network who were then able to raise the maximum transaction size to 100KB, giving users the freedom to create novel implementations that put larger and more complex data onto the ledger including in this early example, an entire website.

Return to original functionality

The Genesis upgrade in February 2020 restored the original functionality of the opcode. This did not impact the ability to store arbitrary data on-chain, however the best practice was amended to advise the use of False Return scripts for applications that still seek to do so.