pull down to refresh

That may sound like hyperbole
When it looks like hyperbole and it moves like hyperbole, it probably is hyperbole?
I'd not worry about the existential crisis some people assign to it, but that doesn't mean there's not an underlying issue here.

Does reducing the limits on op_return really make the arbitrary data storage on Bitcoin worse? Isn't it already out of control? If Op_return unspendable outputs can carry practically 'unlimited' data (like they can in the Witness already) is anything really being changed?
It isn't; except it gets technically easier at the cost of fee sats.
With the current proposal, as long as the segwit discount exists, witness script data abuse is still cheaper. This was raised on the mailing list today by the same author:
Relaxing OP_RETURN size limits without dealing with the inscriptions exploit means no one will use this for anything besides attacking the network with the worst possible data. There's little to no incentive to use OP_RETURN for data storage when using the 'inscriptions' exploit costs 4x less in transactions. What's the point of having a "standard" way to store arbitrary data if the exploit method is 4x cheaper? And the nonstandard version of the exploit allows 4x the data?
Sjors said something rather smart about this in response:
There is no point in restricting transactions that are 4x more expensive than the alternative.
He's right about this: it actually means there is no point in doing NACK on the PR for this reason.
The only remaining issue is that new spam "protocol" implementations will be easier to implement and thus may attract a whole ton of bad actors (or will, according to Murphy's law), but then to your other point, abusers will most likely just lose tons of sats to their petty get-rich-quick schemes and will run out of cash eventually while in the short-mid term possibly congesting the network.
PS: I'm not sure why Sjors is mentioning that removing the segwit discount is a hardfork. I'll have to dig a bit deeper to try and understand his p.o.v. better, right now I suspect it has to do with optimum economic usage of the blockspace always dictating that less functional space should be cheaper than more functional space - perhaps in ratio to their availability (?!?)

Don't we have a growing issue with UTXO dust and economically unspendable outputs... either due to the sizes of the UTXOs, or even from public keys implemented as arbitrary data? (Fake keys)
Yes. It passed 16GB in 2023, which is more than needed for financial txs. At risk of sounding like a total Sjors fanboy, see bitcoin/bitcoin#28249.

I can "run" Bitcoin knots (it's easy to do on Umbrel) however the arbitrary data is still consensus valid so even if it's not "in my mempool" it's still being stored on my node.
I'm not an expert on how knots implemented this, but assuming that it doesn't keep every rejected tx due to these rules in a cache, you'll also put yourself at a disadvantage when doing block validation: you'll see transactions in your block that you'll need to re-request from peers whereas non-knots users don't need to. This may also explain the higher-than-average % of empty blocks mined by OCEAN: it takes more time to validate the previous block from another pool that doesn't have the same filters because the slowest component in validation is the network.

How high do fees need to go (and they need to go really high eventually in the face of declining subsidy) in order to "outprice" the spammers and scammers so that they eventually give up? In the face of "high demand" will there be demand for arbitrary data?
I think the question is the other way around: how much perceived external value per vB is needed to be included among the next 1-5 blocks? 2 sat/vB as of writing means:
a 10KB jpeg currently needs to be more valuable than (per Core's own rules for dust: (size * sat/vB * 3) - 1 = uneconomical ):
  • 10,000 * 2 * 3 = 60000 sats for a witness inscription
  • 10,000 * 4 * 2 * 3 = 240000 sats for OP_RETURN (the * 4 is caused by not getting segwit discount)

What is the Best thing to do?
Properly discuss it. As much as I love Peter's no-nonsense "let's do it" PR, it probably needs to be discussed a bit because the last script element size constraint change brought us inscriptions as an unintended side-effect... Discussing takes patience, listening to people you may dislike, some debate outside of safe channels, and all the other things we haven't seen an awful lot of lately... I'm sitting here and reading, hoping for a win for "team discourse without escalation"
Thank you for your comment. This discussion is so interesting to me.
It isn't; except it gets technically easier at the cost of fee sats.
This is amazing to me. Bitcoiners/monetary users are reluctant to 'overpay' on fees but the spammers... have really deep pockets. They 'overpay' on fees all day long and they don't care I still don't understand this.
The only remaining issue is that new spam "protocol" implementations will be easier to implement and thus may attract a whole ton of bad actors (or will, according to Murphy's law), but then to your other point, abusers will most likely just lose tons of sats to their petty get-rich-quick schemes and will run out of cash eventually while in the short-mid term possibly congesting the network.
As much as I want to avoid network congestion... the crazy thing is that it's not that congested, not really. Blocks are still 1-2 sats/vb even with both monetary txs and the spam sometimes it goes up to 3... but the fees are low let's face it.
I believe that 'low demand' for transactions low utilization is a far greater threat than basically any amount of spam because while spam can cause 'high fees' for short periods, it's only speculative. Who buys the jpeg "off of me".
If people don't and can't want to transact... with declining subsidy that's a problem. In my opinion this isn't talked about enough.
With the current proposal, as long as the segwit discount exists, witness script data abuse is still cheaper. This was raised on the mailing list today by the same author:
Wizkid made some comments on this... essentially saying that inscriptions are in maximum 500 byte 'chunks' that are "pushed"... but op_return is maximum 100KB in a single chunk. Meaning it's way easier to use the op_return with no limits... even if it's more expensive? A lot more could be uploaded much easier.
He makes the point that more could be uploaded... potentially illicit material or even illegal material that no-one wants to facilitate.
Yes. It passed 16GB in 2023, which is more than needed for financial txs. At risk of sounding like a total Sjors fanboy, see bitcoin/bitcoin#28249.
I had hoped that the spammers would take advantage of the 'low fees'/half empty blocks a few weeks ago (when fees were 1 sat/vb mostly empty) and do some serious 'consolidations' on their dust outputs. While fees are low... why not consolidate your 'memecoins' into fewer UTXOs as long as those coins are spendable?
For them to not do otherwise doesn't make any sense to me. A 330 sat output needs to be consolidated eventually at 1 sat/vb.
I'm not an expert on how knots implemented this, but assuming that it doesn't keep every rejected tx due to these rules in a cache, you'll also put yourself at a disadvantage when doing block validation: you'll see transactions in your block that you'll need to re-request from peers whereas non-knots users don't need to.
This is interesting. Even if those transactions aren't 'in your mempool' they're still in blocks. I think Mechanic mentioned at some point why Ocean had a number of empty blocks but this wasn't it.
I think the question is the other way around: how much perceived external value per vB is needed to be included among the next 1-5 blocks? 2 sat/vB as of writing means: a 10KB jpeg currently needs to be more valuable than (per Core's own rules for dust: (size * sat/vB * 3) - 1 = uneconomical ):
Wait, you're telling me that an inscription of that size... needs to be 'extraneously' more valuable than 60k sats? HA! They are 99% worthless in my opinion?
They are 99% cartoon nfts for the life of me I can't understand the appeal of NFTs.
Properly discuss it. As much as I love Peter's no-nonsense "let's do it" PR, it probably needs to be discussed a bit because the last script element size constraint change brought us inscriptions as an unintended side-effect... Discussing takes patience, listening to people you may dislike, some debate outside of safe channels, and all the other things we haven't seen an awful lot of lately... I'm sitting here and reading, hoping for a win for "team discourse without escalation"
I agree with "doing nothing" when it's not clear what to do. A slightly different perspective though... it wasn't the 'script element size constraint' that brought the inscriptions.
It was the Human Beings that wanted to gamble on nonsense/cartoons/speculate etc. They are ultimately responsible.
If a 10kb jpeg needs to exceed 60k sats value at 2 sats/vb to "break even" (if I'm understanding this right)....
then at 10x demand for blockspace, at 20 sats/vb it's 600k sats to 'break even'?
And if Bitcoin were 5x more valuable in exchange then... 600k sats is ~3000$. So the Jpeg has to be re-sell-able for at least 3000$ to 'break even'? PLUS the overhead costs so 3000$ to sell the JPEG makes it break even but that doesn't incorporate profit for the scammer.
reply
100 sats \ 0 replies \ @optimism 10h
They 'overpay' on fees all day long and they don't care. Still don't understand this.
Yeah purely for the perceived value of having your jpeg or "BRC-20" token. It's crazy.
it's not that congested
Indeed, it isn't at all. I paid a 28k sats bill on-chain the other day because the merchant didn't support LN and I didn't cry.
Wait, you're telling me that an inscription of that size... needs to be 'extraneously' more valuable than 60k sats? [..] then at 10x demand for blockspace, at 20 sats/vb it's 600k sats to 'break even'? And if Bitcoin were 5x more valuable in exchange then... 600k sats is ~3000$. So the Jpeg has to be re-sell-able for at least 3000$ to 'break even'?
Exactly! Not break-even but make sense economically. Break even would be 1x - that too is crazy. But then... stupid algo-generated monkey pics go for millions - we live in an insane world.
I agree with "doing nothing" when it's not clear what to do.
At least give people time for a chance to articulate their thoughts and talk it over. Which is happening on the mailing list right now, so that's great (even though I can't help but feeling that it's less active than it used to be.)
reply
100 sats \ 4 replies \ @Murch 10h
PS: I'm not sure why Sjors is mentioning that removing the segwit discount is a hardfork. I'll have to dig a bit deeper to try and understand his p.o.v. better, right now I suspect it has to do with optimum economic usage of the blockspace always dictating that less functional space should be cheaper than more functional space - perhaps in ratio to their availability (?!?)
I don’t think that’s correct. It seems to me that counting witness data at a higher weight could be implemented as a soft fork.
reply
That's what I thought too but now I'm doing the head scratching economic analysis of filling up the blocks with the most profitable template.
counting witness data at a higher weight
Technically, miners can ask whatever they want and try to extort higher fees on any arbitrary parameter, but that is the opposite of what we've seen happening since the removal of a default-configured minfee. I don't see miners doing this being likely, though as long as there is subsidy, it may be doable.
reply
Hypothetical...
If ~ 4 years from now we get a halving, and Tx fees are still at 1-3 sats/vb and then another 4 years later at another 1-3 sats/vb... and another 4 years later we're still at 1-3 sats/vb with ~ 50% monkey jpegs + memecoins 'in blocks'...
Will Bitcoin fail? Is it on that path now?
reply
21 sats \ 0 replies \ @optimism 9h
Not if the amount of energy you can buy for the blockreward remains the same as it is now; as in sats/MW goes down similarly to the earnings, and there is no competitor for the same ASICs.
reply
100 sats \ 0 replies \ @Murch 9h
Just to be clear, I don’t support the idea, I merely think it could be done as a soft fork.
reply