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
Replies (4)
I'm ignorant sorry!
Why do we need to download all the data, including OP_RETURNs ?
Why can't we when we sync a fres node select to ignore that data ?
Or make that the default sync mechanism?
I'm in favor of strictly limiting onchain data.
So I would vote to not allow stuff like NFT's.
But would like to keep open a smart contact path.
No idea yet how to distinguish between that kind of data ?
Should it be a different storage than onchain?
I'm a bit stuck.
#Bitcoin is money/payment system.
Including whatever data on-chain is hampering that function.
But if money is no issue filling the blockchain with spam transactions is also possible.
The miners could filter these, but filter on what is useless data or not, is not always clear and neither is what are spam transactions or not ?
We have been through the block-size war and the outcome is clear, small blocks rule.
Let's take that as basis and not introduce ways to increase block size or onchain data ?
If needed we need to find alternative ways.
Fast fixes are not the way to go.
One issue- the initial download is taking longer and longer, and verifying it is taking longer and longer.
As hardware is prone to failure, sometimes one needs to download the chain from the network.
Even with faster internet and faster drives, this IBD is still becoming prohibitive.
With an unlimited opreturn, this IBD could become a “trust me bro” situation. It’s already a bitch with low end hardware, and we would exacerbate that problem.
Now, we could try to hash everything prior to a certain point or something and archive it, but that could raise issues like leaving coins stranded in the archive.
