@npub12rv5...85vg
Calle, I appreciate the clarity and depth of your post. I agree with you on the importance of assuming good faith. Everyone here is trying to strengthen Bitcoin, not weaken it. But the changes currently being made around OP_RETURN size and relay fee policy are not being carefully examined. They are introducing new problems that are more immediate and concrete than the hypothetical problems they are claimed to address.
You frame the issue primarily as a question of how to prevent blockchain spam, with fees as the only decentralized answer. That misses two key layers. First, the blockchain itself already has structural spam filters built into the protocol: the block size limit and the 10-minute block interval determined by difficulty adjustment. Those are what prevent infinite transactions, not fees. Fees determine priority within the fixed block space, but they are not the mechanism that sets the boundary. The size and timing constraints were deliberately chosen so that individuals could afford to keep a full copy of the chain on inexpensive hardware. This was the original economic model, and it remains central to Bitcoin’s decentralization.
Second, you are not addressing the relay mesh. The change to allow OP_RETURN data up to 100 kilobytes per transaction, combined with the sub-sat per vbyte relay policy introduced in v29, creates a completely new class of abuse. It is one thing for someone to pay a miner directly to insert 100 kilobytes of arbitrary data into a block. That has always been possible by paying a mining pool directly. It is another thing to let anyone use the peer-to-peer relay mesh as a free content distribution network by pushing 100 kilobyte transactions through the network at negligible potential cost, knowing they will never be mined.
Before v29, the minimum relay fee was around 1 sat per vbyte. This meant that using the relay network carried a real economic cost. Lowering that threshold to 0.01 sat per vbyte or less removes the cost. A spammer can now broadcast large transactions for essentially nothing. These transactions will sit in mempools, consume RAM, eat bandwidth, and crowd out legitimate activity, without ever reaching a block. There is no fee market mechanism that solves this, because the spammer is not actually paying for block space. They are abusing the transport layer itself.
This is not just a blockchain problem, and it is not just a future problem. It’s a relay layer problem today. If this policy remains in place, the peer-to-peer network becomes an unpriced commons, and like every unpriced commons, it will be abused. The bandwidth and memory requirements to run a node will increase dramatically. Ordinary node operators will be forced out, and centralization pressure will increase. That is the opposite of what Bitcoin’s design intends.
Your analogies to CAPTCHAs, logins, and ad blockers are also misplaced. Those are rate-limiting mechanisms for identity and access control in centralized systems. OP_RETURN filtering and relay policy are content filters. A better analogy is email spam filtering. Each mail server chooses its own rules. There is no central authority dictating identical behavior. Nodes deciding what they are willing to relay is not central planning. It is local policy and a critical component of node sovereignty.
There is also a larger pattern at work here. Developers, by nature, tend to look for technical solutions to potential future problems. But the market is not calling for these changes. The problem being described is not present today. The solutions being introduced do not solve any actual problems, but they do create new ones and worsen existing issues. We are not facing a flood of legitimate transactions that can’t get through because relay fees are too high. What we are doing is opening the door to large-scale abuse of the relay mesh and the blockchain without any clear benefit.
I also want to call attention to something in your post that appears indirectly, but is important. Your closing argument is structurally the same as Peter Todd’s tail emission argument: that someday in the future miners may not have enough incentive, so we must change the protocol now before it’s too late. This is a speculative future scenario. We don’t know if it will happen, when it will happen, or what the economic environment will be if it does. Changing fundamental network policies today based on hypothetical future conditions is not sound systems engineering. If such a problem arises, the tools and circumstances available in that future will almost certainly differ from those we have now. Solving a future potential problem with present tools is not only uninformed by definition, it is most certainly wrong.
Developers are important, but they are not the sole authority on how the network should function. The market is. And the market has already voted, through real use and sustained preference, for the current structure of the Bitcoin blockchain and relay policies over thousands of alternatives. The strength of Bitcoin lies precisely in its ability to let market forces determine what works, not in preemptively changing fundamental parameters based on speculative scenarios.
We should not make these kinds of changes lightly, and although you may have been involved in the discussion for two years, the discussion is not over. The decision is not final, nor will it ever be. We already have open-source forks, more than one viable alternative with more to come. Allowing 100 kilobyte payloads combined with sub-sat relay fees creates immediate, predictable problems, while claiming to address problems that may never materialize. The proper course is to let the market surface real issues, then address them when they exist, not to introduce new vulnerabilities based on hypothetical futures.
Respectfully, the changes being proposed do not solve real problems. They create them.
View quoted note →
