pull down to refresh

300 sats \ 1 reply \ @Murch 1 May \ parent \ on: Mom and Dad are Fighting....Again (Re: Bitcoin Core OP_RETURN Restrictions) bitcoin
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:
  1. Big OP_RETURN outputs 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).
  2. Big OP_RETURN outputs 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.
  3. OP_RETURN outputs 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.
write
preview
0 sats \ 0 replies \ @unschooled OP 21h
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_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.
OP_RETURN outputs 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 larger OP_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.
reply