> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/history-of-op-return.md). # 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 () by Satoshi Nakamoto. 1. 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. 2. Further changes to OP\_RETURN functionality In Bitcoin Core's [v0.9.0 update](https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core), 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. 3. 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. 4. 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. 5. OP\_RETURN in BSV 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](https://whatsonchain.com/tx/21a5c896f23bea81ae5018dfeb8801ddc68691d0186a7e2d8c011e65e0a396d9). 6. 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/history-of-op-return.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.