pull down to refresh
0 sats \ 1 reply \ @Murch 11h \ parent \ on: Mom and Dad are Fighting....Again (Re: Bitcoin Core OP_RETURN Restrictions) bitcoin
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.
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