History of OP_RETURN

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:

OP_TRUE OP_RETURN

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.

OP_RETURN in BCH

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.

OP_RETURN in BSV

When 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, a discovery was made that because the OP_RETURN opcode terminated the script such that nodes did not validate anything after it occurred, this also meant that nodes did not check that the script did not exceed the max script size limit of 520 bytes. Communication of this went out to the Miners on the network who then raised their maximum transaction size to 100KB. This enabled users to create novel implementations that put various data onto the ledger including in at least one 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.