IMO, this is fine, and probably better.
To understand why, it helps to start with why OP_RETURN exists at all. OP_RETURN offers a mechanism to add arbitrary data to a transaction that, crucially, can be safely deleted.
So, when you sync a fresh node, you still have to download all the data (including OP_RETURNs) in order to validate it. But you only have to keep the UTXOs. Your node can safely drop the OP_RETURN data, and your node will be able to validate new transactions just fine.
Without OP_RETURN, someone wanting to cram arbitrary data into a TX has to use some other means, such as nonsense addresses, or script content (inscriptions). Every node must maintain this information in perpetually in order to validate future transactions.
Removing the limit on OP_RETURN will allow people to put garbage into the block chain in a node-friendlier way than the status quo. In both cases (OP_RETURN or inscriptions) the sender has to pay for the block space by outcompeting other transactions in the mempool. But at least with OP_RETURN, nodes can delete this garbage after the initial download.
#Bitcoin
jimbocoin / jimbocoin 🃏
npub1v9…x9q3h
2025-04-30 01:04:58
in reply to nevent1q…ww6x
Author Public Key
npub1v9qy0ry6uyh36z65pe790qrxfye84ydsgzc877armmwr2l9tpkjsdx9q3hPublished at
2025-04-30 01:04:58Event JSON
{
"id": "76a23f47d864bc6f11eea1268bdd29b5a163e1d63131933f28ba6cc78a569b6f",
"pubkey": "6140478c9ae12f1d0b540e7c57806649327a91b040b07f7ba3dedc357cab0da5",
"created_at": 1745975098,
"kind": 1,
"tags": [
[
"e",
"d7ce905ef0223fb29af4cacdda08604cab8530ca95965218557709fad3772b5a",
"",
"root"
],
[
"p",
"9c47bb510f8e732abc68518f1e88d3dfcfe2fcc624cd9427aefc759d000381d0"
],
[
"t",
"bitcoin"
]
],
"content": "IMO, this is fine, and probably better.\n\nTo understand why, it helps to start with why OP_RETURN exists at all. OP_RETURN offers a mechanism to add arbitrary data to a transaction that, crucially, can be safely deleted.\n\nSo, when you sync a fresh node, you still have to download all the data (including OP_RETURNs) in order to validate it. But you only have to keep the UTXOs. Your node can safely drop the OP_RETURN data, and your node will be able to validate new transactions just fine.\n\nWithout OP_RETURN, someone wanting to cram arbitrary data into a TX has to use some other means, such as nonsense addresses, or script content (inscriptions). Every node must maintain this information in perpetually in order to validate future transactions.\n \nRemoving the limit on OP_RETURN will allow people to put garbage into the block chain in a node-friendlier way than the status quo. In both cases (OP_RETURN or inscriptions) the sender has to pay for the block space by outcompeting other transactions in the mempool. But at least with OP_RETURN, nodes can delete this garbage after the initial download.\n\n#Bitcoin",
"sig": "d09dd64ad50404f25159a8e3fbe952f4c4e3db18cc444de68e8a85fcaa78ddb1d69211b686afc29f80b446dcd0c44e5d644137346b78d131c07f48d5dfad69fa"
}