Parker: I would not run Core v30

Antoine: rebuttal

Here's where it gets interesting:

1. This is my conclusion based on the short timeline between PR and initial decision put out in early May combined with my observation that I haven't really seen any introspection or willingness to reconsider, it's just my opinion based on individual interactions.
2. When the comments early were made, paraphrasing, "if there's consensus among core, we have an obligation to move forward" there's an implicit consequence that user dissent is not really relevant. I understand the logic but it presents a dilemma.
3. No, it's my opinion and conclusion based on my interactions with a number of people and broader observations. I really haven't seen anyone say "maybe we're wrong" even if a position doesn't change. Nor have I, in direct interactions, seen anyone internalize the dilemma put forward by the Pretence of Knowledge. From my vantage point, I've seen overconfidence and little introspection. It's not been possible to disagree respectfully. If you disagree and simply support no change, you're a retard or influencer or filterooor.
4. It's not a clear solution to a problem. I understand the "harm reduction" view with fake pub keys but I don't see slowing growth (marginally and potentially) of a problem as a solution. I don't even think people would agree on the problem, which is an inherent underlying challenge. Op return isn't causing people to do harmful things. They are doing that on their own. Some people think large op returns are bad. Some don't. To each their own but hard to agree to disagree if people differ on this and it influences how people perceive this change being a solution. Marginally addressing one issue while potentially creating others is not a solution as I see it.
5. I've outlined potential unintended consequences in the past. I'm not suggesting a change. I haven't seen an outline of all the potential unintended consequences and risk weighting by people supportive of the change. I think there is going to be significant divergence for a time in relay policies and I think there is benefit to their being rough consensus on standardness (both op return and min fees). I also think there's going to be a lot of money raised to explore possibilities of arbitrary data. I see risk, maybe it influences other changes, maybe not. Balancing unintended consequences and the unknown should have been more rigorous in my opinion. I see it all as marginal, not existential and in my view, in that case, the default position is not to change.

I respect the dialogue and the fact that you disagree.

Antoine responds in kind

Thanks for taking the time to write a thoughtful criticism. I think some of the points you raise actually apply to yourself.

1. This has been an ongoing debate for over 2 years. This topic has been debated at great length on various public and private fora over the years. Maybe the decision reached is not the one you would have preferred, but denying the plain fact that this has been debated at length is ridiculous.
2. I understand your point, but this cannot be a robust way for Bitcoin Core to make decisions. In fact, i think you say this now because you disagree with this specific decision but you would not support such a standard to be applied consistently. (Since it can be trivially exploited.)
   • a) First of all, there are millions of Bitcoin users. Changes should not be made that benefit the concentrated interest of a few at the expense of the dispersed interests of all users. Of course, it is reasonable to give weight to the opinion of bitcoiners (a likely small subset of Bitcoin users nowadays), if only for the reason that they are for the most part power users that contribute back to the project more than the average user. Concerns need to be heard, and hopefully one contributor takes it upon himself to address them, but this should not guarantee a change in decision if there is consensus that this would make users at large worse off (cf point b).
   • b) Secondly, arguments should be considered on their own merits, not based on the identity of the person formulating them. This is paramount. A user (even a power user like a bitcoiner) must only have influence on the rough consensus process only insofar as he raises valid objective arguments. Bitcoin Core needs to make decisions based on objective reality and not emotions.
3. This indicates you have not paid enough attention, or are not familiar with how the vast majority of Core contributors approach this. Respectfully, it appears you have a strong opinion about something you don't know much about. I'm not in other people's head but i know several other regular contributors personally and they are not remotely overconfident. On the contrary, many would doubt themselves even a bit too much, which i think is sane. After all we are all a selectively paranoid bunch. And the peer review process is really humbling in this regard: we are all wrong very regularly in various aspects. This is why your position is really off-putting, starting from the ludicrous assumption "every single Core contributor is stupidly overconfident and i know better". If anything this position just means the criticism applies to you, hence my snarky reply to you at the very beginning of the controversy that you were "the embodiment of The Fatal Conceit" back when you kept branding the Pretence of Knowledge around.
4. The reason for the change is not "marginally less UTxO bloat". If you can't steel man the case for the opposite point of view, you are not thinking clearly. The reason is that we are designing an incentives system here and the first thing this is supposed to be doing is to not create malincentives. If it does it needs to be fixed: first, do no harm. As it was stated in the very first post that restarted the controversy earlier this year, the OP_RETURN standardness limit was intended as a slight deterrent against using the block chain to store arbitrary data. It is completely and absolutely obsolete in this regard, because anyone can just store 4 times as much data with standard transactions today, at 4 times cheaper marginal rate. However, this limit was still pushing people that wanted to benefit from the properties of the transaction relay network towards more harmful way of storing payment-related data. This obsolete standardness limit was a strict net-negative. From first principle (don't incentivize harmful behaviour) and validated by evidence (the Citrea stuff that was blown out of proportion, where this policy pushed them toward the harmful behaviour) it had to go. I have never stated that Citrea would create a substantial amount of UTxO bloat and that this is done in reaction, in fact i have often corrected people about this (cf my latest appearance on What Bitcoin Did where Danny had been told that and it's just incorrect).
5. • a) (On considering unintended consequences.) Various risks and potential consequences of both keeping or removing the limit were detailed and discussed at length on public fora such as the mailing list and Delving Bitcoin. Even an abstract piece of how to think about transaction relay (taking a step back) was published by Bitcoin Core contributors on the Core website. This a lot more than has been done for many more consequential changes that were made in the past decade.
   • b) (On shitcoiners raising money.) To explore the possibility of arbitrary data? Have you paid attention in the past 2 years? Data storage has been the main driver of block space demand for the past years, totalling close to $300M in fees. Of course it's not great, but it's also not the end of the world. And if people don't value financial onchain transactions, there is unfortunately not much we can do. Possibilities have been explored, in fact the hype was just dying down when Ocean started refueling it with their stupid campaign. Let's see whether this will restart a new wave.
   • c) (On not changing.) I disagree, bugs should be fixed even if they are not critical vulnerabilities. We do that all the time.

I know you've spent a lot of time thinking about this, and i appreciate we finally get to discuss it properly.

Parker's response

Sharing a few thoughts to clarify my views.

1. I was not suggesting that this has not been long debated or to ignore the history specifically over the last two years or the prior proposal in 2024. More that when it was proposed in April 2025, it was functionally already decided. All the discourse over the past 6 months has not been a debate, more a sideshow. I came to the personal conclusion in May or early June based on personal discussions I was having, that it was decided and I accepted that the change was going to be made.
2. I only began to engage because I was observing contention and not just by two people. I would actually have no problem if Core just recommended changing the setting and the network organically adopted a new policy. Changing the default is the mechanism that I take issue with. I accept that if a change were widely popular, by users of software, that it is a good decision even if I disagree. That is decentralization working. What I'm talking about specifically here is the idea put forward "if there's consensus among core developers, then we move forward". It's been said in multiple variants in response to contention by users, to reinforce that broad user dissent doesn't really matter if there is consensus among Core. Not suggesting a poll be taken or listen to everyone's opinions. There might be millions of users but what matters is users of software. A user of Coinbase is not relaying transactions, Coinbase is. There's also no concentrated interest. A number of valid concerns have been brought up and that is going to dictate why users of software don't change but it's only valid if an inherently small number of people think it is valid.
3. I am basing this comment on my own interactions with actual people. Again, if this were widely popular (as clear cut as you believe it to be), there would not be broad dissent. From the start, I've accepted that I could be wrong. The sign of that will be if most people running nodes disagree, if so that would be great and would give me confidence in the wisdom of the network. The mechanism of changing the default distorts how or why this change will be adopted. Maybe users understand their own incentives best and if a sufficient number remain unconvinced, that it factor in with more weight.
4. Yes this is about incentives. You have not argued from the perspective of why an individual user has an incentive to relay large op returns, other than possibly being altruistic. If each individual had that incentive, it likely would not be contentious. Based on my reading of the debate, nothing has changed seemingly from the beginning. There are users that don't have an incentive to relay large op returns. This also is not a bug as bugs are typically defined in software.
5. Every user of the software has to decide for themselves on the risks and unintended consequences. I accept that affinity scams are run on bitcoin (ordinals for example is an objective, textbook affinity scam) and that those can and do drive a temporary spike in fees. I also know that CrYpTO funds raise 100x the capital than people building applications for bitcoin. I don't see the broad-based benefit of changing the default when it's clear that a large number of nodes are not going to change. Again, I based my original comment on discussions I have had and on my own observations. It's clear you are very well reasoned and I respect that you weight the risks differently.

Antoine's response

Appreciate the discussion, i feel like we are making progress on some of the points.

1. You are correct that by June, there was rough consensus among contributors that this was a desirable change. That consensus reflects careful study of the issue, extensive discussion, and a deep familiarity with how the P2P network works. Some of those involved are, in fact, largely responsible for how the P2P network operates today. I don't see anything wrong with that, on the contrary?
2. Ok. So what you are saying here is essentially that Core should not make changes to the software without first consulting bitcoiners. Or even all Bitcoin Core users. This is an unreasonable standard. Maintaining the p2p network is what Bitcoin Core does. We make p2p changes in virtually every release (and many more consequential than stupid opreturn), and it's worked out pretty well. In the past decade Core contributors have substantially upgraded the p2p network to the benefit of all Bitcoin users, prevented a number of risks before they materialized, and patched several vulnerabilities before they could be exploited. None of this would have been possible if we relied on the coordination of the 80000 Bitcoin Core users to tweak a few knobs. Bitcoin is not (anymore?) a network ran by a couple of very active enthusiasts. It's a vast global network that underpins a $2T asset, is relied upon by millions of people daily (directly or not), and needs active maintenance. Again, anybody is welcome to participate in development, but nobody will be given a pass to make (or block) changes without strong arguments just because they self-identify as a bitcoiner.
3. You changed this point from "developers are overconfident and i know better" to "look, this change is controversial". I take that my rebuttal of the former was convincing to you. :) Obviously, i agree with the latter.
4. You changed this point from "this is not a solution to a problem" to "users have no incentive to adopt this change". That's not an issue, i'm happy to also address that, just noting it. Users have a direct incentive to have a consistent mempool. To do so their mempool needs to accept what is being mined. Users (especially bitcoiners) have an indirect incentive to keep Bitcoin working correctly. Fast block propagation and a public fee auction are key elements to this end. This requires having consistent mempools across the network and relaying what's being mined. That said, note that users today perform many altruistic actions because they come at a low cost to them. For instance serving historical blocks to people performing IBD, or relaying more transactions than necessary for their own privacy. Saying "i have no incentive to relay transactions containing op_return's!" is equally applicable to having no incentive to relay version 3 transactions or serve historical blocks for that matter.

Parker's response

Couple of points:

2. I specifically said it would NOT make sense to poll users or consult bitcoiners, I said if there is broad dissent, key word broad, and with the back drop of the explicit comments around "if there's consensus among Core contributors, that is the consensus needed", there's an implicit consequence that users aren't stakeholders. Because valid concerns have been raised, but if not considered valid by core contributors, then they aren't valid. Regardless, users are going to determine what software to run so it's fine. But again if broad dissent, you can just think that dissent is not for valid reasons but it's still a reality.
3. Didn't change the point, responded directly to your point. You said "this indicates you have not paid enough attention" and I responded by saying I based the original statement about individual interactions. You then said I have strong opinions I don't know much about. Point is I understand my incentives in running a node and relaying transactions better than you. As do others that disagree, in their own cases. If you think we're all just stupid because we don't agree with you, the market of individuals understand their own incentives better and if you don't realize the limitation of your own knowledge when it comes to incentives of others, that is kind of making my point.
4. Didn't change the point, responded to your point about not being able to steel man others positions and not thinking clearly, then making the comment about how you're designing a system of incentives and the first thing is do no harm. I addressed that by agreeing that it is about incentives. You view the existence of the op return relay limit as causing harm by introducing a malincentive. Your view of relative harm might be and is different than others. So what you see as a solution others view as not being a solution because they differ on views of harm and incentives. You view it as black and white, one position is definitively right and the other wrong but ultimately they are going to choose what software to run based on their own incentives and that eliminating one malincentive can create others. If this were clearly a solution to a problem everyone agreed on, a large number of otherwise reasonable people would not disagree.