Introduction
I’m not a developer, and this piece won’t be heavy on technical detail. Instead, I want to approach the OP_RETURN debate from a pragmatic use case reality perspective.
There are two reasons for this. First, by applying the Feynman Technique … that is, attempting to explain the subject in simple terms, I can test and refine my own understanding. Second, much of the debate I’ve seen seems less concerned with real-world, pragmatic truth and more about emotional investment, leading to point scoring on technicalities. This has led to intellectual dishonesty on both sides, where arguments relying on fallacies such as begging the question or argumentum ad absurdum have now become the default mode.
At its core (pun intended), this issue isn’t about whether Bitcoin can technically accommodate more data (it obviously can), but whether it should, and what the practical trade-offs are
I want to cut through some of the noise, so I’ll structure this as a series of claims, rebuttals, and pragmatic views. The claim represents the argument as presented, in full detail rather than shorthand. The rebuttal looks at why that claim may be flawed or incomplete. And the pragmatic view is where I’ll step back and ask… regardless of theory… what does this actually mean for Bitcoin users and the network in practice? With that said, I’ll get started…
Claims, Rebuttals, and Pragmatics
Claim 1a: Inaccurate mempool estimates degrade the user experience.
The claim:
Supporters of the OP_RETURN expansion argue that without it, mempool fee estimation becomes less accurate. Since transactions embedding arbitrary data outside OP_RETURN can look “non-standard” to nodes, new or lightly configured nodes may misinterpret the fee market. The concern is that this leads to poor user experience… transactions could either overpay (wasting sats) or underpay (causing delays). Advocates frame this as a meaningful degradation in service that justifies normalizing larger OP_RETURN use.
The rebuttal:
Fee estimation is inherently noisy, and Bitcoin users are already aware of this. Whether mempool policy changes or not, users generally rely on wallets, not raw node defaults, to set fees. These wallets already bake in safety margins and dynamic adjustments. At high fee levels (e.g., 90 vs 100 sat/vB), variance is essentially irrelevant; at low levels (<1 sat/vB), spam itself is what distorts the fee market, not the filtering rules.
Enlarging OP_RETURN does not guarantee that arbitrary data will migrate there; actors can still embed payloads in other ways. In other words, fee estimation has always been approximate, and a few “inaccurate” data points don’t fundamentally degrade Bitcoin’s utility.
The pragmatic view:
Most real-world users never directly interact with mempool settings. They follow their wallet’s recommendation, and wallets adapt quickly to network conditions. Pragmatically, the difference between “98 vs 102 sat/vB” is trivial compared to the swings caused by congestion cycles, sudden NFT or ordinals waves, or batching events. So while mempool accuracy is a valid engineering concern, it’s not the kind of issue that materially changes adoption, trust, or user experience at the scale of Bitcoin’s primary use case: settlement of value.
Claim 1b: Initial Block Download (IBD) is degraded without OP_RETURN expansion
The claim:
Proponents argue that new nodes syncing from scratch (Initial Block Download) face degraded performance when arbitrary data is stored outside OP_RETURN. Because these non-standard data patterns appear as “normal” transactions, they remain in mempools and affect how nodes process blocks during IBD. Supporters of expansion frame the change as altruistic: by normalizing OP_RETURN for arbitrary data, future new nodes will avoid these inefficiencies, leading to a smoother onboarding experience. In short, the argument is that IBD becomes needlessly heavier if arbitrary data is left uncontained.
The rebuttal:
IBD has always been the cost of entry… a known price of sovereignty. Syncing Bitcoin from genesis inherently encourages low-time preference, it takes time and resources, and no policy tweak changes that reality. Enlarging OP_RETURN does not guarantee that all arbitrary data will relocate there; actors can still bypass it and use other transaction constructions. This means the “IBD protection” is at best partial, and at worst, a post-facto justification for a change motivated by different incentives (like fee capture). Moreover, once IBD is complete, node operators don’t repeatedly pay this cost… it’s a one-time process, not an ongoing degradation of service.
The pragmatic view:
Pragmatically, the difference OP_RETURN expansion makes for new node sync is marginal. If your TikTok brain can’t wait 2–3 days to sync a node, you probably don’t need to run one. Users serious enough to do so already expect some setup overhead, and hardware continues to improve. What matters is reliability, not shaving a few percent off sync time, after waiting 3 days for IBD, arguing that saving the end user an hour or two is a hill worth dying on, is abrogating common sense to score points on a technicality. Treating IBD as a blocker risks overstating the issue… it’s a bounded cost, not a systemic flaw. In practice, most people use bootstrap data, torrent snapshots, or pruned nodes to accelerate onboarding anyway. Lastly, new software like Utreexo will completely nullify this claim.
Claim 2: Filters don’t work, so it’s better to enlarge OP_RETURN and contain the data
The claim:
Supporters of OP_RETURN expansion argue that mempool and relay filters are ineffective. Since spammers are often economically motivated, they can always find ways to disguise data as valid transactions. Attempts to block non-standard use cases push them into other corners of the protocol, making the fee market less predictable. By enlarging OP_RETURN, the argument goes, Bitcoin provides an explicit “container” for arbitrary data, reducing incentives to hide it elsewhere. This is framed as a pragmatic compromise: since spam is inevitable, better to channel it into a known, standard location where it can be managed and measured.
The rebuttal:
This reasoning is logically inconsistent. If filters “don’t work” why would enlarging OP_RETURN suddenly steer spam into the “safe” container? Enlarging OP_RETURN doesn’t remove a filter, it just makes it less filtery. A filter’s purpose is to add friction… not absolute prevention, but enough resistance to discourage non-monetary use. Actors already motivated to store arbitrary data can continue to use other avenues, just as they always have. Enlarging OP_RETURN only normalizes and incentivizes that behavior, effectively saying, this kind of activity is now acceptable. History supports this, when OP_RETURN was increased to 80 bytes in 2014 (Bartoletti & Pompianu, 2017), data-storing transactions didn’t decline elsewhere, they simply expanded in both volume and scope. Far from containment, it signalled permission.
The pragmatic view:
In practice, filters do work at the margin, they raise the cost and complexity of spamming, which is often enough deterrent for casual actors. That doesn’t eliminate all spam, but perfect elimination isn’t the goal. Bitcoin is built on economic friction… small costs discourage abuse without requiring absolute bans. Pragmatically, the question isn’t whether spam exists but whether it meaningfully degrades Bitcoin’s monetary utility. Enlarging OP_RETURN doesn’t reduce spam; it redistributes and legitimizes it by making the default policy “permissive” The more pragmatic path is to maintain deterrents, imperfect but useful, while keeping Bitcoin focused on its core role as money rather than normalizing it as a general-purpose data ledger.
Claim 3: Spam is existential vs. spam is harmless
The claim:
Supporters of OP_RETURN expansion often argue that spam is not an existential threat to Bitcoin. They reason that Bitcoin’s fee market is self-regulating… every byte of data must pay the market rate for block space, whether it’s a financial transfer or arbitrary metadata. As congestion rises, non-monetary use cases (like NFTs, memes, or “monkey JPGs”) naturally get priced out. In this view, spam is economically harmless… it pays for its own privilege and eventually fades as non-monetary fads collapse in Bitcoin terms. Therefore, engineering changes to discourage spam are unnecessary, since the market already sorts it out.
The rebuttal:
While spam may not kill Bitcoin outright, treating it as harmless ignores its real costs. Block space is scarce, and every spam transaction displaces a monetary one. This forces monetary users to compete with actors who add no lasting value to the monetary network. Claiming “spam pays its own way” is misleading… it doesn’t add value, it merely exploits scarcity. In economic terms, spam is a parasitic load, it feeds on the infrastructure without strengthening it. Moreover, the claim that spam “prices itself out” doesn’t hold historically: when block space demand surges, spam and fads often drive fee spikes (as seen on Ethereum during the 2021 NFT boom), temporarily pricing out ordinary monetary users. That distortion undermines Bitcoin’s primary use case as money, even if it doesn’t threaten the protocol’s survival.
And critically, proponents can’t have their cake and eat it too. If spam is truly harmless, then there’s no reason to justify OP_RETURN expansion as an altruistic fix for degraded IBD or noisy mempool data. If spam is harmful enough to merit containment, then admitting that contradicts the claim that it’s harmless. The two arguments cancel each other out. Pick one.
The pragmatic view:
Spam isn’t existential, but it isn’t harmless either. It acts like a tax on monetary users, raising their costs without contributing to Bitcoin’s mission as sound money. Pragmatically, the debate isn’t whether spam disappears (it won’t) but whether Bitcoin should normalise and encourage it. The most sustainable path is to maintain friction: don’t pretend spam is impossible, but don’t signal that it’s welcome either. That preserves Bitcoin’s ethos as a monetary network while leaving the fee market to handle outliers naturally.
Claim 4: Changing defaults has no effect because node operators can just configure it themselves
The claim:
Supporters of the OP_RETURN expansion argue that it’s only a mempool policy change, not a consensus change. In this view, it doesn’t affect Bitcoin’s rules or economic security. Any node operator uncomfortable with the new default can simply reconfigure their settings, run an older version of Core, or switch to an alternative implementation like Knots. Since Bitcoin is decentralized by design, defaults supposedly carry no binding weight… they’re just conveniences for those who don’t want to tinker. Therefore, critics are accused of overstating the significance of what is “just a default.”
The rebuttal:
It’s true that node operators can always configure their own policies — but that was just as true before the OP_RETURN expansion. Using this point as a defense now is circular: if configurability alone made defaults irrelevant, there would never have been a reason to expand OP_RETURN in the first place. In reality, defaults matter because they set norms. Most economic nodes (exchanges, custodians, wallet software) run defaults to avoid complexity, which is why Core’s policy choices consistently shape ecosystem behavior. So while configurability exists, dismissing the significance of a default change ignores both precedent and practice.
The pragmatic view:
Pragmatically, defaults act as Schelling points. Even though node operators can change them, the majority won’t, because coordination and maintenance overhead is costly. That’s exactly why Core’s defaults carry weight: they establish the “normal” behavior that propagates through the network. The key issue isn’t whether defaults can be changed, but whether shifting them signals a new norm. Saying “it’s just a default” underplays the social and economic power defaults hold in a decentralized system.
Claim 5: Core is decentralized, so this change can’t be a big deal
The claim:
Supporters of the OP_RETURN expansion argue that Core is just one implementation among many, and Bitcoin is decentralized enough that no single group of developers can dictate rules. Since the change only affects policy defaults and not consensus, the reasoning goes, the market of node operators, miners, and users can freely choose alternatives if they disagree. From this perspective, Core has no special power and it’s “just code”, and any perception of centralisation is an illusion. Therefore, critics who see Core’s decision making as significant are accused of exaggerating its influence.
The rebuttal:
This argument confuses technical decentralisation with practical centralisation of influence. Yes, Core is not Bitcoin itself… but in practice, Core functions as a Schelling point. Most economic nodes (exchanges, custodians, merchants, wallet services) run Core because it’s the de facto standard. That convergence gives Core defaults (and thus changes) disproportionate influence, regardless of theoretical decentralisation. Saying “it’s just one repo” ignores the reality that when Core shifts a policy, the majority of the ecosystem shifts with it. History shows this repeatedly… defaults become norms, and norms harden into practice. Claiming Core’s choices are insignificant understates the social weight of the project.
The pragmatic view:
Pragmatically, Bitcoin’s resilience depends on acknowledging both layers… the protocol is decentralized, but implementation choices do influence behavior. Pretending Core’s influence doesn’t matter is a form of denial — the healthier approach is to recognise that defaults are powerful, and dissent (via Knots or config changes) is a valid corrective. The point isn’t to vilify Core, but to keep in mind that influence accumulates where most people converge. Pragmatism means respecting that Core has outsized sway while still keeping alternatives viable. That balance is what prevents Bitcoin from slipping into de facto centralization.
Claim 6: Knots users are overreacting… they can just run an old version or change the defaults
The claim:
Pro-Core advocates often dismiss Knots adoption as unnecessary, framing it as an overreaction. Their argument is that dissenters already had technical options… they could keep running an older version of Core, tweak their mempool policies, or disable OP_RETURN relay if they disliked the new defaults. Since all of these paths remain open, the claim is that running Knots is redundant drama… a needless fork that adds confusion without solving anything.
The rebuttal:
This misses the point. Running Knots wasn’t just a technical decision… it was a visible act of dissent. When the debate around the OP_RETURN change was unceremoniously shut down and dissenters were ridiculed, users turned to Knots as a way of signaling disagreement in a way Core developers could see. Sure, anyone could quietly tweak configs or stay on Core 29, but those actions are invisible, they don’t show up in network metrics. Running Knots allows dissenters to make their position measurable, to show Core devs that there is real pushback against unilateral policy changes. Dismissing this as “overreaction” reduces political protest to a technical footnote, which is itself intellectually dishonest.
From a political science lens, Knots became a coordination device. In Schelling’s terms, Core’s defaults are a focal point that most of the ecosystem converges on, which is precisely why changing them is consequential. Knots emerged as a counter-Schelling point… a visible place for dissenters to coordinate and signal disapproval, even if they lack direct influence over Core maintainers. Without that, dissent would remain atomised and invisible, making it easy to dismiss opposition as just noise.
The pragmatic view:
Pragmatically, the adoption of knots is the healthiest form of dissent… it allows users to voice their disagreement without breaking consensus. It doesn’t fragment Bitcoin, it doesn’t introduce new rules… it simply says “we don’t accept this default” In any open-source ecosystem, visible forks act as a feedback mechanism, showing when a critical mass feels ignored (RedHat/CentOS, MySQL/MariaDB, OpenOffice/LibreOffice). Whether or not you agree with their stance, Knots users are not overreacting; they are engaging in a non-destructive way to register dissent against centralised decisions in a decentralised system. Far from being a problem, it’s a sign of resilience… Bitcoin can tolerate competing Schelling points without collapsing, which strengthens its credibility as a truly decentralised system.
Conclusion
If this change is truly “no big deal” as many pro-Core advocates insist, then why has it become the hill they’ve chosen to die on? Why push so hard for a policy tweak that, by their own framing, makes little real world difference? The result has been the most bitter fight since the blocksize wars… not because the technical stakes are existential, but because the social and philosophical ones are.
When we strip the rhetoric back and look at the debate through a pragmatic lens, the impacts of OP_RETURN expansion are marginal at best, fee estimates aren’t fundamentally broken, IBD is still the cost of sovereignty, and spam will exist regardless of where you try to funnel it. Defaults matter because they signal norms, but defaults alone don’t redefine Bitcoin.
Which leaves the fundamental question… why inflame the community over a change with so little upside? If the goal is to preserve cohesion and keep Bitcoin focused on money, then the cost of this battle has far exceeded the benefit of the change.
Pragmatism means recognising when a technical win is a social loss, and asking whether the victory was worth the fight.