pull down to refresh
55 sats \ 8 replies \ @Modus 29 Apr \ on: Mom and Dad are Fighting....Again (Re: Bitcoin Core OP_RETURN Restrictions) bitcoin
What is "bypassing the public network"?
Also, I'm not sure what Wuille means by this. I basically read it as, to exploit a more damaging workaround than the low-filter limits.
I feel like Luke's opposition is getting strawmanned; from his discussions it would seem he wants to fix the bugs with the current filters.
I'll admit, however, I haven't fully groked the purpose and effect that removing the filters would have.
More interesting to me is seeing how these talks are playing out, where voices that are being charged with wanting to "censor" network transactions are simultaneously being throttled (or "collapsed" cf #966183).
reply
reply
Sure, I can try to explain what I meant.
To start, I would never claim to have very much credibility on topics relating to core development (as the naive title and nature of my post might indicate), but only to speak in generalities. I'm glad to admit I'm curious and trying to learn.
I think that the general sentiment is that his projects are overly-idealistic. Attacks against him accuse him of 'burying his head in the sand,' and that he and his camp would cut off their nose to spite their face--to use your expression. This doesn't really get to the crux of the issues he is raising. I generally like when figures like Dash who present a counter-narrative to conventional wisdom.
Wuille engaged with his points in the thread, which I'm confident you have read by now, at a level I can't really claim to rebut. No doubt, and this goes without saying, he gave intelligent response to Dash's 'whitlist approach'.
My left-of-the-curve take is this. By removing standardness restrictions, core-devs are taking a taoist, be like water, sort of approach; these restrictions are largely ignored since there exist cheaper alternatives for such "nonstandard" or "spam" transactions. But the initial charge against restrictions is that they "encourage" harmful practices (i.e. for non-financial transactions to find alternative rails to the miners directly). Myself, and perhaps Dash would sympathize, I question the semantics of saying this encourages undesirable transaction outputs being included.
If the financial incentive is there for these actors to find rails that bypass the network, is a feature that was intended to curb this behaviour actually "encouraging" it? Does removing them not feel unlike throwing the baby out with the bathwater?
reply
My left-of-the-curve take is this. By removing standardness restrictions, core-devs are taking a taoist, be like water, sort of approach; these restrictions are largely ignored since there exist cheaper alternatives for such "nonstandard" or "spam" transactions.
I guess you could describe it that way. I would say that it’s based on a non-emotional assessment of what’s happening on the network. Since Ordinals, Inscriptions, and Runes have started, these transactions have paid about ~$286M (7,050 ₿) in fees and occupied between 5–40% of blockspace.
One of the tenets of Bitcoin is censorship resistance, and in this case, it works well for the NFT-enthusiasts: about 10% of nodes accepting and forwarding their transactions is sufficient for transactions to ~reliably propagate to miners. Miners have a big financial incentive to include these transactions, miners that do not include them take a paycut and increase the revenue of other miners. (I believe this to be self-evident: taking only a subset of the juicy transactions means that the average fees collected by your blocks being lower, and leaves more high feerate transactions to the next block.) When the Ordinal craze started in early 2023, the reachable node count jumped up by several thousand nodes. This implies that even if Bitcoin Core started releasing node software that filtered Inscription transactions, there would likely be sufficient nodes that forward them, simply by those people not updating their nodes. Beyond that, the business with these pictures is probably in the billions if they already pay hundreds of millions in transaction fees, and that is plenty money to organize a patched client that forwards the transactions. That means that even a majority of nodes filtering these transactions would not make any dent into their likelihood of making it to miners.
The Bitcoin community could try to bring out the big guns and soft-fork the transactions out, but with soft forks generally taking months to years to deploy, and there being many different ways how such data carrying transactions could be created, the NFT enthusiasts would likely be more nimble and simply switch to another script. We could restrict transactions just to a small set of whitelisted output scripts, but data could still be embedded in the hashes used by those output scripts, and losing the ability to have programmable money would be too big of a price. There is an argument here, that forbidding one type of NFTs might be sufficient pushback to make the community feel unwelcome, but I doubt that it would turn out that way, if I look at the resurgence of Stamps when Ordinals were popular and consider that there are three more such protocols since.
So, trying to "filter" these transactions so they don’t get into my node’s mempool, while I still accept them in my blocks doesn’t seem useful to me. I don’t buy that it actually saves bandwidth, because I still have to download the transaction once and will forward it with any blocks I relay. It might actually increase the traffic, because almost all of my peers will still announce the transaction to me. It makes my node a less useful peer and makes it minusculy slower for me to receive blocks because it causes the compact block relay to never succeed fully. On the other hand, I no longer have a complete picture of the mempool, to see what my own transactions should be competing with, I cannot predict the next block accurately anymore. Out of these advantages and disadvantages, it seems at best like a toss-up unless I have some sort of emotional reaction about sticking it to the funny picture people by not having their transaction in my mempool (but still in my blockchain). Anyway, it seems useless to get all wound up about this, especially now that it has mostly run its course. It’s not exactly new anyway, we’ve had multiple waves of colored coins, timestamping schemes, and NFTs on Bitcoin in the past ~13 years that I have been around—they just taper out when the respective set of people learn that blockchains don’t work well for data storage and get tired of paying for it.
Regarding the classification of doing inscriptions as "bugs": characterizing the possibility of doing Inscriptions as a bug seems silly, unless you are advocating to remove all custom scripting, and I have already explained why that doesn’t seem right to me above. On the other hand, the datacarrier configuration option was specifically introduced to regulate the size of OP_RETURN outputs, so suddenly claiming that it should apply to any transaction pattern that might be used to put data in transactions even while the methods’ costs are wildly different is charitably at best a new idea—I am not aware of any other Bitcoin Core contributors that share that interpretation.
So yeah, the whole Ordinals, Inscription, Runes, and whatever stuff is not great, but if there is significant demand for creating those sort of transactions and they already show up in blocks, instead of trying censor part of the bitcoin users and thereby incentivizing them to start running private mempools or building tools for direct submission to the bigger miners, I’d very much prefer relaying their transactions on the open network so that all miners get them into their mempools.
reply
Respectfully, perhaps you can point me to a relevant discussion and/or spell out the harm of leaving the op_return restrictions and addressing the "bug" instead?
Is there a grand plan for addressing non-financial transaction data being stored on people's nodes, or is it simply a, 'wait until they get priced out?' strategy Core is following?
reply
What "bug" are we referring to? AFAIK, Luke is the only Bitcoin Core contributor that thinks that a configuration option that was introduced twelve years ago to allow configuring specifically the OP_RETURN size a node accept in their mempool should obviously refer to any new patterns that are used to insert data in the blockchain, and classifies the appearance of new patterns that are not yet handled by the code as a "bug". I really don’t get how that position got picked up by Bitcoin Twitter so broadly—it’s a comically absurd representation.
reply
I won't try to defend Luke's usage of the term.
Although it may seem "absurd" to you, for reasons you outlined clearly and cogently already (#967847), to the user-level understanding, a "bug" would seem to indicate that there's something that may not be working as intended, which "new patterns" of use generally can reveal to developers is not being handled by the code.
Your reply also illustrates in detail the context and means by which op_return standardness limits may be ineffectual, but I still feel that there's a paucity of explanations (not only from you, but from the clerical caste in general) as to the urgency and rationale for removing a part of Core's implementation that has been there for so long (twelve years, as you said), and, to boot, whose vulnerabilities seem to have already been capitalized upon by the ordinals and nft people.
Maybe I'm being naive, but I'm failing to see a logical defense for removing the limits that goes further than saying, "they aren't doing everything we want them to do." One might think that, given the amount of vehemence with which this pr is being defended, keeping the limits threatens the network in some novel way, but so far I've not been able to see how/why that might be the case.
I understand the work-arounds that are being found, and i concede these are problematic; nevertheless, it is still incumbent on those proposing the changes to at least try to forecast the problems they foresee taking form were the they not implemented. In other words, if the rationale cannot be phrased as, "by removing the limits, we are addressing (a)", and instead is always put, "the limits aren't doing (b), so they're not needed," then you can expect backlash from a community that has so much invested in these decisions. While it might be up to debate what (a) problems need to be addressed, at least then we're having an honest conversation about the motivation. With the latter rhetoric, (b) might be something that everybody agrees is needdd, yet those users who are not intimately up to date on all the gritty details are left wanting as for what the a priori cause for the change actually is.
I appreciate your patience and good-faith discussion, Murch. Please don't misunderstand my remarks as an attack on anyone.
reply