Replying to Avatar Jameson Lopp

Greg Maxwell's take:

There isn't anything unusual or bad going on *with* Bitcoin Core.

In my opinion there does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core. There have been a dozen threads on reddit on the matter, which is pretty sad because it's mostly a nothing burger... I've wasted tens of hours writing responses only to find that generally the opponents just vanish.

Back in 2014 the average block size was only around 160 kilobytes, as a result there was no real pressure to drive up transaction fees and it was extremely cheap to stuff whatever garbage data you wanted in Bitcoin's chain. Some people were storing data by paying to fake addresses which were really just data instead of an address. This is maximally bad because it bloats up the UTXO database with unprunable data, directly increasing the minimum cost to run a node.

To address this core devs introduced a 'data carrier' output type also called an OP_RETURN. This is a kind of output which provably can't be spent so it doesn't have to go into the utxo database and can be pruned. Additionally, they limited the size of the data to 40 bytes in order to encourage applications which can just store a hash instead of the data to do that. Later this limit was increased to 80 bytes.

The world has changed a lot since 2014: Fees are now not just meaningful but significant, no one is dumping data in Bitcoin because it's *cheap*. People dumping data in have almost entirely moved to dumping data in the witness portion of transactions. Major miners no longer enforce this limit, because it turns out they like money (and have denied requests to limit themselves), and if you are willing to directly connect to one its easy to get them mined. There are some users who are still creating 'fake outputs' but have said they would change to opreturn if not for the limit (particularly some payment channel thing). Finally, use of hashes for commitments is now well understood and there are over 2 commitments per second flowing into open-timestamps which can aggregate an unlimited number of commitments into a single transaction.

The limit also causes some harm to all users of Bitcoin, particularly since multiple significant miners ignore it. When you don't already know a transaction (because it never reached you or you discarded it) it takes *much* longer to relay a block to you (at least 3x the delay if you knew everything but potentially much more depending on how much data you are missing), this harms small miners at the expense of big miners increasing a centralization pressure on mining (because when miners aren't on the same chaintip, one one bigger miners are on will tend to win). It also contributes to mining centralization by encouraging direct transaction submission since no one will bother submitting to a 1% miner, allowing the bigger miners to make more money. An inaccurate mempool also harms users ability to accurately estimate what transactions are pending for the next block so that they can optimally bid against them.

So it was proposed that the limit be removed. There are two proposals, one that just removes the limit completely, which is the first and simpler proposal. Then there is another proposal which makes the default unlimited but retains the ability to adjust it. At this time neither of the proposals have been merged, descriptions of this as having been done are just untruthful.

Arguments against it don't seem to hold up.

The first category of opposition is basically just accusing Bitcoin Core devs of being in favor of shitcoins or monkey jpegs, having talked to many I am confident that few or even none of them like that stuff (no one I've talked to was in favor of it). But no matter how much they don't like that stuff, that doesn't change that this proposal should have no significant effect on it-- it's unrelated. That stuff doesn't use opreturn today and would cost more in transaction fees if it did.

The next category of opposition is just general opposition to 'spam'-- again this proposal is largely unrelated because spammers won't use this, and to whatever extent they do it'll be good news (either moving from utxo bloating fake outputs or increasing their costs). It's an incidious argument because most contributors to Bitcoin core believe there isn't much meaningfully more that can be done about spam: Miners have bypassed the filters that were there, fees have excluded all price sensitive spam. Bitcoin was designed to be censorship resistant and depends on censorship resistance to work-- and a fact of free speech is that it means it allows both speech you like and speech you oppose. Arguments are made that blocking this traffic isn't morally equivalent to censorship. Perhaps! but it's still substantially *technically* equivalent. But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam.

Ultimately the subject is deep in the minutia. It won't make a difference to your usage of Bitcoin. The only really concerning thing I see in the subject is the degree that people have successfully weaponized misinformation to direct a lot of entirely undeserved abuse at contributors to Bitcoin Core. ... who had only just started discussing a proposal when they were waylaid by a flood of disproportionate comments and falsehoods.

https://www.reddit.com/r/Bitcoin/s/elIDdPaQhL

Maxwell claims that spammers don’t use OP_RETURN, so lifting the limit wouldn’t increase spam. But this is misleading. The limit itself prevents certain types of spam. Removing it creates a new attack surface. The fact that miners currently prefer the witness space or fake outputs is due to existing limitations... change the rules, and behavior changes. The mere existence of limits shapes incentives.

He argues that “price-sensitive spam” is already filtered out by fees, so there's no need for limits. But this ignores the long-term externalities of non-financial bloat. Spam isn’t just about cost... it’s about degrading the signal of legitimate financial activity and increasing node operational costs. Just because something pays a fee doesn’t mean it belongs on a system designed for monetary transactions.

He criticizes fake outputs for bloating the UTXO, and claims OP_RETURN was meant to fix that, but then argues for removing limits on OP_RETURN. This is incoherent: the whole reason OP_RETURN was added with a limit was to keep metadata off-chain or at least minimized. Allowing arbitrary data completely undermines this principle.

He states that major miners already ignore the OP_RETURN limit, so it doesn’t matter. This is a poor justification. Miners ignoring a protocol rule is not a reason to codify the violation... it’s an issue to be addressed. This reasoning effectively invites further erosion of protocol standards in the name of convenience or profit.

He equates any filtering of non-financial data to censorship, which is technically and ethically misleading. Bitcoin nodes filter transactions all the time (e.g., invalid signatures, oversize blocks). There’s a fundamental difference between censoring legitimate financial transactions and filtering out non-financial bloat. Bitcoin is not a free-for-all file hosting service.

He claims this proposal is “minutia” and won’t affect users, but earlier admits it could negatively affect block relay speeds, small miners, and mempool consistency. These are not minor concerns... they relate directly to decentralization and fairness in mining. You can’t claim the impact is negligible while also outlining its systemic risks.

Rather than focusing solely on technical merit, Maxwell repeatedly appeals to the poor treatment of Core developers and the “disproportionate” response. While abusive behavior is unacceptable, it does not shield a proposal from critique. Technical decisions must be judged on impact and logic, not on the tone of public reaction.

Reply to this note

Please Login to reply.

Discussion

This is an extremely good and level headed rebuttal to Maxwell's post. The part in the first paragraph about the new attack surface is key in my opinion.

nostr:nevent1qqstcxt30q6h956uhzwpyaw8xa3t585gqpt06w5vztmrjejaksmjprspr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgs0rjgv9vvs92j2jl0e7ch8nll8htax3x4duccl69ylazae838xcagrqsqqqqqpqsh8es

note18juyzq0c40hssh45js7vjncvvmxmmpsac9pnkdg2cgy3j9gu4wgq2q04m7

If spammers will spam with transaction of 1 satoshi will you try to stop them? What’s the rule ?

They already are stopped. Bitcoin Core enforces a dust limit... 546 sats for P2PKH. Any tx below that gets dropped by default. So yeah, we’ve been filtering spam for years. This means that if a spammer tries to send 1 satoshi, it won’t propagate across the network unless miners are directly accepting and mining it themselves. The dust limit was introduced specifically to combat spam, by making it 546 times more expensive to flood the network with meaningless outputs.