pull down to refresh
0 sats \ 11 replies \ @unschooled OP 29 Apr \ parent \ on: Mom and Dad are Fighting....Again (Re: Bitcoin Core OP_RETURN Restrictions) bitcoin
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).
Could you explain a bit further how Luke is being strawmanned? I would like to better understand that point.
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
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.
Thanks. Sure, I agree that it is valid to debate whether the behavior is intended or not. I would agree that it was an unforeseen outcome, I don’t think bug is the right way to describe, but what really irks me is when it is called it a bug in the handling of the "datacarrier" configuration option.
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), […]
I think there is a misunderstanding in regard to urgency. Either way this change would be released at the earliest in Bitcoin Core 0.30.0 in October or November. The topic merely got a lot of attention which led to an uncommon amount of engagement of contributors with the topic in little time.
and, to boot, whose vulnerabilities seem to have already been capitalized upon by the ordinals and nft people.
I am not sure whether this is a misunderstanding, but
datacarrier has only ever referred to the OP_RETURN size limit, and the opposite narrative is a singular viewpoint by a contributor known for their unique perception of reality. OP_RETURN outputs are not used in Ordinals, Inscriptions, or BRC-20 tokens. I believe that Runes use them, but that use does not require multiple OP_RETURN outputs or OP_RETURN outputs in excess of the current limit. While we are talking about this, I would also like to address the misconception that more use of OP_RETURN outputs would increase the blockchain growth: output data is not subject to the witness discount. Data in OP_RETURN outputs has full weight and would therefore likely push down overall blocksize rather than increase it. While additional transactions with OP_RETURN outputs could increase the competition for blockspace, more OP_RETURN outputs cannot cause bigger blocks.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 needed, 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 think you correctly identify the main argument. The limits no longer fulfill the original purpose of curbing excess blockchain growth while blockspace was heavily underdemanded. While we have seen a few blocks in the past three months that were not full, almost all blocks have been full in the past 27 months. Even when we saw some non-full blocks, the average block size has been above 1.3 MB every day since then:
This means that today, data transactions generally must compete for blockspace on the blockspace market. On the other hand, we are seeing more mining pools run with non-standard configurations, accepting larger OP_RETURNs and other non-standard transactions. There is another Bitcoin implementation, Libre Relay, that already supports relaying transactions considered non-standard by Bitcoin Core. Demand for these non-standard transactions incentivizes the build-out of private mempools and direct submission of transactions to mining pools. It stands to reason that direct submission will predominantly go to the biggest mining pools, the smaller a mining pool, the less manpower they have to run custom configurations, build tooling for direct submission, or be approached by users wanting to submit transactions. Assuming that the hundreds-of-millions monkey-picture industry pays competitive feerates for their non-standard transactions, this directly translates to a business advantage for the largest mining pools. Many Bitcoin contributors consider mining centralization one of the most likely failure scenarios of Bitcoin. These non-standard transactions appearing in blocks more often is an indicator that the
OP_RETURN limit may be causing systemic harm. So, to summarize:- Big
OP_RETURNoutputs do not present a DOS vector, do not bloat the UTXO set, and cannot increase the blockchain growth beyond the current blockchain growth (unless blockspace demand were to drop precipitously without it). - Big
OP_RETURNoutputs are being included in blocks even though they are non-standard 3.. Fees for non-standard outputs being collected only by the largest mining pools puts smaller mining operations at a financial disadvantage. OP_RETURNoutputs are only cheaper for data payloads of up to 143 bytes and up to 4× more expensive for larger data payloads than inscriptions.
Overall, my conclusion is that the
OP_RETURN size limit today is no longer fulfilling its original purpose of curbing blockchain growth, may be slightly harmful for mining decentralization, and only (ineffectively!) serves the paternalistic purpose of one group of Bitcoin users attempting to impose their perspective of acceptable use of Bitcoin on another group of Bitcoin users. While I don’t hold, trade, or otherwise care about any NFTs nor ever have, it seems to me that Bitcoin is many different things to many different people, and either way, the censorship resistance we pride ourselves in works for them in this case.I appreciate your patience and good-faith discussion, Murch. Please don't misunderstand my remarks as an attack on anyone.
Thanks, for taking the time to discuss with me.
reply
Hi again Murch,
I agree that misunderstandings, often stemming from tribalism, are endemic in this debate. I appreciate your collected approach and thorough explanations.
Not having come from a technical background, I am interested in how technical considerations and their motivations are being communicated. Clearly, there are political undertones in discourses about bitcoin, which necessitates a level of dialogue and understanding that may be hindered by past traumas.
I considered your reply, and although I'm expending myself past my wont, I am nevertheless very interested in responding.
As you have stated, OP-RETURN is not being used for ordinals, inscriptions or BRC-20, and the monkey-picture-people, so ostensibly they won't switch to OP_RETURN because Core removed the limit. Witness scripts seem to be working for them.
OP_RETURNoutputs are not used in Ordinals, Inscriptions, or BRC-20 tokens. I believe that Runes use them, but that use does not require multiple OP_RETURN outputs or OP_RETURN outputs in excess of the current limit.
OP_RETURNoutputs are only cheaper for data payloads of up to 143 bytes and up to 4× more expensive for larger data payloads than inscriptions.
I'm having a hard time reconciling these two statements with the point you made about mining-centralization:
On the other hand, we are seeing more mining pools run with non-standard configurations, accepting largerOP_RETURNs and other non-standard transactions.
Demand for these non-standard transactions incentivizes the build-out of private mempools and direct submission of transactions to mining pools. It stands to reason that direct submission will predominantly go to the biggest mining pools, the smaller a mining pool, the less manpower they have to run custom configurations, build tooling for direct submission, or be approached by users wanting to submit transactions. Assuming that the hundreds-of-millions monkey-picture industry pays competitive feerates for their non-standard transactions, this directly translates to a business advantage for the largest mining pools.
Do we have data that backs this claim about private mempools, or is this a theoretical argument, only? Initially, it is not self-evident that there is a specific use-case of data-carrying OP-RETURNs (between 83 and 143 bytes) that Core, by removing the cap, is trying to nudge away from making their own private mempools, since if there were, I reckon it would have to be consequentially large and developed in order to outweigh the fees from the witness scripts that smaller mining pools don't have to adjust for.
Also, here you seem to have conflated the jpeg (ordinals) people with those propagating non-standard OP-RETURNs via private mempools, so you may be able to appreciate why the terminology gets muddled in public discourse. Although they may well be from the same companies/camp, in practice, they function very differently, as you illuminated, in a way that may not be very well understood in the bitcoin community, apparently.
Can you blame people for reacting as though Core is attempting to 'solve' a non-existent problem? If Core wants to be proactive about a supposed threat to mining decentralization, then that should be coherent and provable.
It comes from some of the Ocean Mining people.
Luke's argument is that the disguising of program code in Witness is "the exploit" and this code serves no other purpose than to carry jpegs and nfts and arbitrary data?
So if mempools broadly and universally recognized this code as 'unnecessary' or 'non-standard'... then those transactions wouldn't get propagated and would be excluded. I think that's the "exploit" that @unschooled is referring to
reply
Sure, right—sorry for the rhetorical question. My point is that it is a misleading representation to achieve more clout. I have tried to lay out my thoughts a bit more above: #968695
I do have a few thoughts on that. While it causes me some eyerolling that NFT creation and trading has been such a big use of blockspace in the past couple years, I much prefer people writing data to witness stacks where it is only needs to be processed once by every node and doesn’t get stored in the UTXO set, which was the popular approach before the introduction as OP_RETURN for harm reduction. We saw a bit of that with the brief counterparty/Stamps revival last year.
And while I’m no fan, I am not blind to the data that indicates that people have spent about $280M in the past two years to purchase blockspace for Inscriptions and Runes.
I’m afraid that "if everyone would just act against their financial incentives and do what I want" doesn’t seem a particularly convincing starting point for a hypothetical.
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
This is a brilliant explanation. Thank you very much
reply