The utxoset size is *permanent* it can’t be pruned like other block data unless you consolidate the spend into a smaller set of utxos
basically think of them as a coin purse where if you put two coins in, the only way to shrink the bag is to spend to coins with no change.
JPEGs in witness data means that they will likely be unspendable, meaning that there is a permanent storage increase requirement on all nodes. But they are no provably unspendable so you can’t discard them from the coin purse. This is really bad.
OP_RETURNs are *provably* unspendable, meaning they can be ignored from the utxoset perspective (never goes in the coin purse)
By trying to stop both witness jpegs and large OP_RETURN pushes, it will push people to do even worse things like large multisigs that stores data in the signatures. This is how the whitepaper is permanently stored in the utxoset. This is even worse for utxo bloat.
At this point the censor proponents would say well thats not economically viable… but none of these methods really is. Some are cheaper than others, sure, but overall it’s still the most expensive data storage out there. People have to burn the hardest money on the planet if they want to play stupid games.
The point is people are going to store data anyway, the *least bad* is OP_RETURN, because it minimizes the *permanent* storage burden on pruned nodes.
Login to reply
Replies (16)
This took a couple of reads, but I understand it.
There is good reasoning here IMHO and very valid points.
I'm still thinking about it in terms of limited size OP_RETURN is bad, but the existing options are worse.
i need time to think, it's Friday, I'm going to a couple of parties at the weekend with normies. I'm going to argue with them to see how blank I can make their faces look 😂
View quoted note →
This is why it is so important to understand how bitcoin technically functions before making emotional arguments about "cat JPEGs on the blockchain."
The whole entire reason why OP_RETURN exists in the first place is to avoid far worse and more damaging data storage schemes to the bitcoin blockchain.
OP_RETURN | Storing Data on the Blockchain
OP_RETURN is an opcode that can be used inside a specific locking script pattern to allow you to store data (such as text) within bitcoin transacti...
The utxoset size is *permanent* it can’t be pruned like other block data unless you consolidate the spend into a smaller set of utxos
basically think of them as a coin purse where if you put two coins in, the only way to shrink the bag is to spend to coins with no change.
JPEGs in witness data means that they will likely be unspendable, meaning that there is a permanent storage increase requirement on all nodes. But they are no provably unspendable so you can’t discard them from the coin purse. This is really bad.
OP_RETURNs are *provably* unspendable, meaning they can be ignored from the utxoset perspective (never goes in the coin purse)
By trying to stop both witness jpegs and large OP_RETURN pushes, it will push people to do even worse things like large multisigs that stores data in the signatures. This is how the whitepaper is permanently stored in the utxoset. This is even worse for utxo bloat.
At this point the censor proponents would say well thats not economically viable… but none of these methods really is. Some are cheaper than others, sure, but overall it’s still the most expensive data storage out there. People have to burn the hardest money on the planet if they want to play stupid games.
The point is people are going to store data anyway, the *least bad* is OP_RETURN, because it minimizes the *permanent* storage burden on pruned nodes.
View quoted note →
Thank you for this explanation. I think there is a lot of misunderstanding around this PR and it seems many are fearful of the change.
What stops them from doing both?
@Guy Swann thoughts on my thoughts?
View quoted note →
The utxoset size is *permanent* it can’t be pruned like other block data unless you consolidate the spend into a smaller set of utxos
basically think of them as a coin purse where if you put two coins in, the only way to shrink the bag is to spend to coins with no change.
JPEGs in witness data means that they will likely be unspendable, meaning that there is a permanent storage increase requirement on all nodes. But they are no provably unspendable so you can’t discard them from the coin purse. This is really bad.
OP_RETURNs are *provably* unspendable, meaning they can be ignored from the utxoset perspective (never goes in the coin purse)
By trying to stop both witness jpegs and large OP_RETURN pushes, it will push people to do even worse things like large multisigs that stores data in the signatures. This is how the whitepaper is permanently stored in the utxoset. This is even worse for utxo bloat.
At this point the censor proponents would say well thats not economically viable… but none of these methods really is. Some are cheaper than others, sure, but overall it’s still the most expensive data storage out there. People have to burn the hardest money on the planet if they want to play stupid games.
The point is people are going to store data anyway, the *least bad* is OP_RETURN, because it minimizes the *permanent* storage burden on pruned nodes.
View quoted note →
Which way, Western man? Lolbertarians would prefer to allow degens to poop in the park bc "muh cOnsTiTooshun" and "muh hUmAn rights". We live in a society (for now)
No, libertarians who don't operate in cartoon would advocate that park shitting be regulated by something other than a centralized authority funded by theft, with a monopoly on force, using arbitrary and observability ineffective measures for doing so. (At the exclusion of other innovative solutions.)
It's not economically viable in a one dimensional profit narrative. But these keynesians always fail to recognize dynamic system complexity, human action, irrational actors, bad faith actors. It only takes one buyer to make a sale.
Thanks for this explanation. That is very helpful for a newb
This is a good rational for why we would want to expand OPRETURN
nevent1qqsg8eedsj064kfrzldy7qvk9xctt2j0haw07xkrgzvk5utyrz0eg3gpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhggh46wa
I understand that OP_RETURN is a garbage dump, but the question is whether to remove the "limitation" of OP_RETURN, and are you saying that we should give up on full nodes like Ethereum and use pruned nodes instead?
Surely, I also think that if the network can be resilient from a pruned node that is left *only one* in the world, that would be one direction of "evolution". And that might be already possible if we gave up on past history and continued only with future payments.
This is wrong. Witness data is not stored in the UTXO set. Witness data is revealed when spending a UTXO, removing it from the UTXO set. Witness data is only in blocks and can be pruned.
This OP_RETURN change has nothing to do with JPEGs. It is 4x cheaper to store JPEGs in the witness data, and the witness data is *not* stored in the UTXO set.
This change is for protocols that need some small amount of data but bigger than 40 bytes to be in an output before being spent. Witness data is not suitable for this because the tx has to be spent to reveal the data.
I wish Rodarmor was active on nostr instead of being a little bitch about it, but the way I understand it is the witness data doesn't actually add to the utxo set and you'd likely consolidate your ordinals just like your regular bitcoin, but BRC-20s broke this by exploding the utxoset. This was why runes were made and use OP_RETURN. A larger OP_RETURN would be good for more use cases like this, but jpegs would likely still be in the witness data because of the discount.
Totalmene de acuerdo.
On the one hand, relaxing policy to incentivize usage that does not bloat the utxoset sounds reasonable. Yet, it would still be cheaper to store data in the witness? And isn’t the present situation a natural experiment showing that filters do have an impact? Finally, how does this help deal with actors like Mike in Space, who has publicly stated that he designed his shitcoin-on-bircoin protocol to bloat the utxoset?