pull down to refresh

This is "wizkid's" comments on the recent proposed changes to op_return in Bitcoin Core (what the vast majority of noderunners use)
This is far more than a small technical change, so the broader community should not be shut out of the discussion or shuffled off to the mailing list. This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety.
Merging this PR means Bitcoin is no longer a decentralized currency.
Merging this PR means Bitcoin is no longer money.
Merging this PR means Bitcoin is no longer a store of value.
Merging this PR means Bitcoin is no longer what users, node runners, etc signed up for and adopted.
Merging this PR means Bitcoin is no longer Bitcoin.
That may sound like hyperbole, but it really isn't. If this PR is merged, Bitcoin as we know it changes forever in the most fundamental way imaginable: The reference implementation explicitly turning the Bitcoin network into an arbitrary data storage system, instead of evolving it as a decentralized currency.

What do the Stackers think of this?
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?
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)
I remember the last halving block, 840000 filled with OP_Return. The limit was (and is) 80 bytes... And yet "runes" memecoins only employ ~10 bytes or so of data. The amount of data "needed" for Runes is minuscule and morons are gambling on memecoins "created" on Bitcoin with data far less than the maximum allowed 'standard.' It's a tiny amount of information used... to mark gambling chips employed by morons. It has been essentially impossible to stop because... op_return exists?
And... It's not like op_return is anything "new" - it was created for arbitrary data storage in the least harmful way possible... with verifiably 'prunable' outputs...
  • But on the other hand... how long is it going to take the spammers and scammers to upload 'reams' of data within OP_Return just to sell more JPegs or memecoins or scams? Why should gamblers get to dictate what Bitcoin is for?
Bitcoin is about sound and transparent capital, sound money unique to the individual NOT arbitrary data storage or cloud storage nonsense.
How do we stop "this" (whatever "this" is) and what do we do about it?

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.
In Witness data. IN OP_Return. In dust outputs...
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?
If fees are "high enough" and Bitcoin "valuable enough" to replace the subsidy completely... who would waste Bitcoin on Memecoin Scams and Monkey Pictures?
What is the Best thing to do?
1842 sats \ 7 replies \ @optimism 2h
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"
reply
100 sats \ 4 replies \ @Murch 1h
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 40m
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 50m
Just to be clear, I don’t support the idea, I merely think it could be done as a soft fork.
reply
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
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
371 sats \ 0 replies \ @Murch 1h
It takes about 10% of nodes accepting a transaction for it to be reliably relayed to miners.
A minority of nodes with more restrictive mempool policies is mostly detrimental to themselves. They are missing transactions from the compact block relay and therefore receive blocks more slowly, have an incomplete mempool for feerate estimation, and presumably slightly increased traffic with their peers, and if they are mining, they pick from a smaller pool of eligible transactions, therefore earning less fees (although fees are currently anyway a vanishing portion of the overall block reward).
While I care not for the whole frog picture on the blockchain thing, it feels to me like a "cut off your nose to spite your face" reaction to run a node with such a configuration.
OP_RETURNs are less harmful than other ways of storing data in the blockchain. Storing data in the blockchain is a millions of dollars business. It’s going to happen despite the noseless zealots, if only because the nodes run by frog picture enthusiasts would be configured to forward them. We are already seeing bigger OP_RETURN outputs in blocks.
The way I see it, we can either have people build out ways to submit transactions directly to mining pools, depriving the rest of the network from having full information and benefiting disproportionally the largest miners, or we can loosen the limits to at least keep the mempool mostly complete, and prevent further incentives to centralize mining.
So, if we take a step back and soberly look at the situation, it seems quixotic and detrimental to keep the OP_RETURN limits in place.
reply
100 sats \ 0 replies \ @unschooled 3h
I'll be honest I'm very unsure what to make of it all at this point.
What's concerning to me, as @optimism alluded to already (#966683), is that some feel as though the Bitcoin Core repo is theirs, a perspective that gets dignified when voices (not so-called 'brigaders', but people with proven clout in the bitcoin space) are being effectively censored in discussions.
Feels a little antithetical to foss to me.
reply
Just to get things straight, do you mean Wizkid Ayo the famous Nigerian artist? I've never known him to be a bitcoiner. Wow.