https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933
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?
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.
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:
Sjors said something rather smart about this in response:
He's right about this: it actually means there is no point in doing
NACKon 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 (?!?)
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'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.
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 satsfor a witness inscription10,000 * 4 * 2 * 3 = 240000 satsforOP_RETURN(the* 4is caused by not getting segwit discount)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 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.
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.
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.
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?
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.
Just to be clear, I don’t support the idea, I merely think it could be done as a soft fork.
Clients that had not upgraded would treat new segwit transactions @ prior costs as valid, would consider them part of longest chain.
I believe this is why it's considered impossible to roll back segwit without a hard fork.
Fees and tx standard rules such as
OP_RETURNsize and count are simply relay/inclusion policy, not block consensus. So you need just a single path to a similarly configured miner to push and get it included. You'll wait longer of course if only a subset of miners accepts it under their policy. This is why someone running Peter Todd's libre relay fork can actually push a biggerOP_RETURNtoday. F2pool seems to allow these as they mined the taunt the other day. The same goes for changing fee calc.This part is correct.
Depends on what you exactly mean with "rolling back segwit".
deleted by author
there is zero appetite for a hard fork. and even soft forks are extremely contentious/disagreed upon.
it's a feature not a bug dude
I would gladly sell whatever extra hardfork coins get created.. but def don't want to see that
Right, non-upgraded nodes would accept the old rules or the new rules, but upgraded nodes and miners would enforce the new rules. If a majority of the network and hashrate enforces the new rules, the best chain converges on the new rules. That’s the definition of a soft fork.
Thank you for your comment. This discussion is so interesting to me.
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.
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.
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.
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.
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.
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.
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.
Yeah purely for the perceived value of having your jpeg or "BRC-20" token. It's crazy.
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.
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.
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.)
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.
Anyway, putting data into OP_RETURN outputs is only cheaper than inscriptions for payloads smaller than 143 bytes.
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.
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.
The most convincing argument against the change I have seen is the one for node runners. We could forecast an increase in data consumption on the blockchain sent. So this would force us to store data which could be stored elsewhere and accessed in my view more efficiently. And so this would end up in a smaller group of node runners. I don't know if this argument is correct but to me it is the most compelling one.
On the other side, the argument of Pieter Wuille about network fragmentation (his argument being about miners bypassing the public network) looks to me compelling. It was the 12th post here:
https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ
I don't know what the best thing to do is, as I am not knowledgeable enough about the implementation of Bitcoin, but I hope knowledgeable people keep debating without using emotional arguments and keep neutrality. To me what differentiates Bitcoin from other payment networks is its neutrality. You can be a North Korean hacker who stole money or a poor guy fighting inflation, both have equal opportunity to make transactions accepted on Bitcoin. In this regard, using the spam argument seems to me a less important one as it uses the nature of the transactions (and in turns lacks neutrality).
People must have no idea... just the amount of arbitrary data that is already being stored on-chain.
Bitcoin is being used for relatively large amounts of arbitrary data right now, especially through inscription, but through op_return outputs/runes too.
No amount of hand-wringing and 'ideological purity' will fundamentally change this.
Yes Bitcoin is money... yes it is a monetary network. But that can not and has not stopped people from using op_return to create and trade random memecoins... based on ~ 5 bytes of data in op_return. Look at halving block 840000 it's all op_return.
Even if op_return limits are relaxed... (and I'm not saying they should be) would it really increase the amount of data on-chain? My understanding is that it probably wouldn't.
Inscription/witness data already gets a 75% discount, so why would a spammer use op_return which is 4x more expensive? 4x more expensive just to upload a jpeg or name a memecoin. They are already doing that and paying less
I see. If the data on-chain would not increase, then we could expect that the number of nodes would not be negatively impacted. I would be more convinced by those in favor of the change then.
Ultimately regarding spam, I saw a post from Sjors I think saying that to get rid of useless data (by useless I mean unrelated to Bitcoin as a payment network), a deeper change in the consensus mechanism or soft fork would be needed anyway.
I told Bitcoin I’m just data. Now it stores my trauma in OP_RETURN.
Are we encountering another similar block size war situation like back in 2017?
Kratter's video is a good explainer: #967721
Yeah just watched that. Very good and clear
No this is not about block sizes.
Just to get things straight, do you mean Wizkid Ayo the famous Nigerian artist? I've never known him to be a bitcoiner. Wow.
https://xcancel.com/wk057