Came across this article while researching the history of OP_return

In Bitcoin’s early days, the script system technically allowed arbitrary data to be included in transactions, but there was no standard way to do so. Nevertheless, creative users found ways – often by hacking the script in unintended fashions. By 2013, people had begun embedding messages, song lyrics, and other non-financial data in the blockchain. One famous May 2013 transaction even stored all the lyrics to Rick Astley’s “Never Gonna Give You Up” as an on-chain joke. At the time, such transactions were non-standard – Bitcoin nodes wouldn’t relay them – but miners could include them in blocks if they saw fit. This meant arbitrary data was starting to live forever on Bitcoin’s ledger, hitchhiking on what were supposed to be financial transactions.

Bitcoin’s developers grew concerned that these “creative” uses of the blockchain were bloating the system in harmful ways. In particular, users were encoding data in spendable outputs – for example, using fake addresses or abusing opcodes like OP_CHECKMULTISIG – effectively creating unspendable UTXOs that lingered in the UTXO set indefinitely. Every unspendable UTXO is a piece of toxic waste, permanently increasing the size of the UTXO database that every full node must store and track. This was antithetical to Bitcoin’s scalability principles.

OP_RETURN was introduced in 2014 as a solution. It’s a special script opcode that deliberately marks an output as provably unspendable, while allowing a small amount of arbitrary data to be attached. By marking the output invalid, OP_RETURN lets nodes drop that output from the UTXO set, avoiding the buildup of “toxic” UTXOs. In March 2014, Bitcoin Core 0.9.0 officially made OP_RETURN a standard, relayable part of transactions. As the release notes made explicit, this was not an endorsement of packing data into Bitcoin blocks for fun or profit – it was a pressure relief valve. The developers wrote:

“This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data as forever-unspendable TX outputs, bloating Bitcoin’s UTXO database. Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.”

In other words, if you absolutely must store a short message or hash in Bitcoin, OP_RETURN gives you a safe, prunable way to do it – but Bitcoin’s creators wanted to discourage on-chain data altogether. As a nod to that philosophy, they imposed a size limit on OP_RETURN data.