Thread

🛡️
This is a long post that hopefully bridges some gaps between technical people (devs) and non-technical users and how they look at spam prevention in Bitcoin. I hope that it clarifies why I think that there is such a huge misunderstanding between both camps. I'll preface this post with first disqualifying any malicious attempts to misrepresent the motives of either camp. Everybody wants to improve Bitcoin as money. Money is Bitcoin's use case. It's not a data storage system. If you think otherwise, there are countless shitcoins to play with. Alright, let's get into it. I have worked on anonymous systems for over a decade. I have read tons of research on spam detection, rate-limiting, and I've implemented spam prevention techniques in the real world. I am very confident to say that there is not a single known method to prevent spam in decentralized anonymous open networks other than proof of work. This is what Satoshi realized when he designed Bitcoin and it's why only transaction fees can reliably fight spam without sacrificing any of Bitcoin's properties. Let me explain. Spam prevention is a cat and mouse game. As a system's architect, your goal is to make the life of a spammer harder (increase the friction). This is why, on the web, you see captchas, sign-ups, or anything that can artificially slow you down. Slowing down is key. This is why Satoshi turned to proof of work. Let's contrast this to other methods for spam prevention. This is not an exhaustive list but it illustrates the design space of this problem, other methods are often derivatives of these: CAPTCHAS are a centralized form of proof of work for humans: Google's servers give you a hard-to-solve task (select all bicycles) that will slow you down so that you can't bombard a website with millions of requests. It requires centralization: you need to prove Google that you're human so that you can use another website. If you could host your own CAPTCHA service, why would anyone believe you're not cheating? LOGINS with email and passwords are most popular way to slow down users. Before you can sign up, you need to get an email address, and to get an email address, you often need a phone number today. The purpose of this is, again, to slow you down (and to track you to be honest). It only works well when emails are hard to get, i.e. in a centralized web where Google controls how hard it is to get an email account. If you could easily use your own email server, why would anyone believe you're not a bot? The next one is the most relevant to Bitcoin: AD BLOCK FILTERS are another form of spam prevention but this time the roles are reversed: you as a user fight against the spam from websites and advertising companies trying to invade your brain. Ad blocking works only under certain conditions: First you need to be able to "spell out" what the spam looks like, i.e. what the filter should filter out. Second, you need to update your filters every time someone circumvents them. Have you ever installed a youtube ad blocker and then noticed that it stops working after a few weeks? That's because you're playing cat-and-mouse with youtube. You block, they circumvent, you update your filters, repeat. The fact that you need to update your filters is critical and that's where it ties back to Bitcoin: Suppose you have a mempool filter for transactions with a locktime of 21 because some stupid NFT project uses that. You maybe slow them down for a few weeks, but then they notice it and change their locktime to 22. You're back at zero, the spam filter doesn't work anymore. What do you do? You update your filter! But where do you get your new filter from? You need a governing body, or some centralized entity that keeps updating these filters and you need to download their new rules every single day. That's what ad blockers in your web browser do. They trust a centralized authority to know what's best for you, and blindly accept their new filters. Every single day. I hope you see the issue here. Nobody should even consider this idea of constantly updating filter rules in Bitcoin. This would give the filter providers a concerning level of power and trust. It would turn Bitcoin into a centrally planned system, the opposite of what makes Bitcoin special. This is why filters do not work for decentralized anonymous systems. They require a central authority. Until now, these rules were determined by Bitcoin Core, but they have realized that these rules do not work anymore. Transactions bypass the filters easily and at some point, carrying them around became a burden to the node runners themselves. Imagine you're using an outdated ad blocker but instead of filtering out ads, it now also filters out legitimate content you might be interested in. That's what mempool filters do, and that's why Bitcoin Core is slowly relaxing these filters. This has been discussed for over two years, it's not a sudden decision. The goal of this change is not to help transactions to slip through more easily. The goal is to improve your node's prediction of what is going to be in the next block. Most people misrepresent this part. They say "it's to turn Bitcoin into a shitcoin" but that is just a false statement at best, or a manipulation tactic at worst. Let's tie it back to proof of work and why fees are the actual filter that keeps Bitcoin secure and prevents spam reasonably well: Satoshi realized that there is no technique that could slow down block production and prevent denial of service attacks in a decentralized system other than proof of work. Fees prevent you from filling blocks with an infinite number of transactions. All the other options would introduce some form of trust or open the door for censorship – nothing works other than proof of work. He was smart enough to design a system where the proof of work that goes into block production is "minted" into the monetary unit of the system itself: You spend energy, you get sats (mining). This slows down block production. How do you slow down transactions within those blocks? You spend the sats themselves, original earned form block production, as fees for the transactions within the block! This idea is truly genius and it's the only reason why Bitcoin can exist. All other attempts of creating decentralized money have failed to solve this step. Think about it: without knowing who you are, whether you're one person pretending to be a thousand, or a thousand people pretending to be one. Bitcoin defends itself (and anyone who runs nodes in the Bitcoin system) from spam by making you pay for your activity. People sometimes counter this by saying: the economic demand for decentralized data storage is higher than the monetary use case. First of all, I think that's just wrong. There are way cheaper ways to store data (there are shitcoins for this), and the value of having decentralized neutral internet money is beyond comparison. However, there's a much deeper concern here. If you truly believe this, I ask you: what is Bitcoin worth to you? If you think Bitcoin can't succeed as money (i.e. be competitive), why do you even care? If you're not willing to pay fees for the use case that we all believe Bitcoin is designed for (money), and you believe that no one is willing to pay for it, how can it even persist into the future? You can't have it all. If Bitcoin is money (which I believe it is), then we need to pay the price to keep it alive. There is no free lunch. Either we centralize, or we pay the price of decentralization. I know where I stand. Peace.

Replies (25)

Just because you know some methods of fighting spam you do not know all of them, and you do not know how they can evolve in the future and make what is impossible today possible. The goal is not zero spam, but less spam. You are completely ignoring asymetric risks and surging costs that will fall on node operators, just so that shitcoiners and miners can get richer. The ones who are aware of that are opposing changes pushed by core.
If you would allow anyone to anonymously and permanently store and retrieve forever any number of 100KB contiguous data blocks on 39K redundant nodes all around the globe including in space for a one time fee of roughly $111/100KB of worthless fiat, you haven't really thought this through. There's no other anonymous immutable distributed file sharing service like it in the world. To certain people, that's priceless. To others, fiat currency is unlimited. Think about it. Satoshi said it would be unwise. He's still right. Nick Szabo just reawakened to echo Satoshi on this. This is why we should leave OP_RETURN alone AND fix the inscriptions hack like Knots already does. Thank you for your attention to this matter! #Enshitcoinification Running #Knots #MBDA
I would describe myself as a technical user and I understand the technical arguments core is attempting to make but I think you are still wrong here. Yes perfect spam filters don't exist, but saying that decentralised spam filters can never work is not true otherwise email would be unusable. Yes I know email is more centralised now than originally intended so maybe not the perfect example but I can still run an email server and filter 90%+ of spam myself. What's important is making bitcoin hostile to spam, yes it's a cat and mouse, wack-a-mole game that will never be 'won', but total victory is not needed. The alternative, to accommodate spammers by giving them a 'nice' way to spam only encourages them, both to spam more and to demand more and more 'accommodations' via essentially blackmail - give us what we want or we harm the chain with more UTXOs etc. Making bitcoin hostile to spammers has worked pretty well for years (apart from the inscriptions fiasco caused by core not fixing a bug - again an example of what happens if you accommodate spammers). There is a reason most scams/spam has occured on other chains rather than bitcoin up till now.
I'm skeptical only because of the size increase, which will lead to a larger blockchain and thus harder storage. I'm not sure if this will affect decentralization, but I'm not as technically savvy about Bitcoin as you are. So, I'll trust your judgment and see it as a positive, since I shouldn't always act on first instincts but dive deeper into things.
🛡️
I love you Calle but this is just another post of "let me trying to explain better the technical argument cause you didn't get it well enough" which does not add anything new to the converstaion and that is not addressing the real issues IMO. Thi spost it's just another proof that core, after 5 months, still has not understood where is the disconnect with its users. Most ppl have perfectly understood the technical rational proposed by core but they still DISAGREE on this change. Some people think the potential dangers are noth worth the potential rewards, some people perceive this as another "let's accomodate a little bit more" spammers, some people think the increase from 80 to 100k is too much, some people agree with the change but have been spooked by some core devs attitude. If core really want to gain some of the trust it has clearly lost, it needs to stop focusing only on keep repeating its technical motivations, and direct the focus somehwere else. I can assure you that this core fiasco is not due to insufficient clarity/explanation of its technical motivations, but rather to: 1) management of the whole issue from day 1 (see github banning and open-close PR) 2) core devs reaction to users not liking this change (good god man, the reaction screamed authoritarian all over with sprinkle of arrogance, childish behaviour and ad ominem attack) 3) the most fervent advocates of this change have been Antoine (creator of PR, makes sense), Jameson Loop, Shinobi, Peter Todd. The last 3 names are probalby the least "loved" devs in existance (for some fair reasons), and they are the one who have pushed for this change the most (podcasts, live debates on YT). From a public relations perspective this was the worst possible way to handle it 4) Core went from "if you don't like the change just switch implementation" to assiduosly (and quite desperately honestly) trying to get back ppl once they saw many more ppl than they thought switched implementation. Then you did not really mean what you said about "just switch if you don't like it, we are cool", cause you clearly are not cool with it I already wrote 3 times (the first in May when this all started) to core devs to help them understand they need to get out of their tecno-bubble and stop refusing to cosider any factor that is not technical. Nodes are managed by human beings, and human beings have emotions, sensations and trust. If you do not incorporate this aspects in comunicating/handling your technical decisions, this is just the first of many horrible managed issue. If you really want to reconnect with your users it's not about another technical explanation, listen to the feedback people are providing man Peace and love
@calle 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.
Brunswick's avatar Brunswick
You are getting closer to a valid argument, but it remains incomplete. Filters still provide resistance to spam, making it more expensive the more nodes filter it. Your argument is essentially: "Since Core doesn’t filter spam in OP_RETURN or the UTXO set, and UTXOs are less efficient for the network, then spammers should be allowed to use OP_RETURN." The real question is whether spam should be filtered. The only counterargument presented is "filters don’t work," which is a red herring. The argument against filters that do work is that they are centralizing, but this claim is made without evidence. Yes, IP RBLs are centralized, but they are an ancient and ineffective solution, especially in the era of Tor. Bayesian filters are far more effective, though they can be poisoned; again, an old problem. The fact that we don’t have perfect filters is not an argument against using filters at all. The assertion that every mempool on every node must be identical is presented without justification, and that requirement itself is a centralizing force. This leaves us with: "Core devs are dedicated and underpaid and shouldn’t have to argue with non-experts; they should just do what they’re good at, which is writing software." This is the most pathetic argument of all. It relies on argumentum ad authoritatum and argumentum ad passiones, and implies that we should entrust our future and fortune to people who are wholly socially inept. Not only is this a highly questionable request, it also leaves open the possibility that these same developers might be unable to defend their "technical" positions against more cunning and malevolent influences; whose presence we are fully aware of.
View quoted note →
↩ replying to SatsAndSports
It allows flooding of large and negligible-monetary-committment OP_RETURN transactions over the relay network, increasing the load on the internet connection. The three main design constraints making bitcoin accessible to node runners are: 1) hard drive space limitations 2) computational and RAM demands 3) network connection limitations. The node-runner constraint these changes to relay policy attack primarily are that of item (3)
🛡️
The core insight here cuts through all the noise: you can’t out clever thermodynamics. Every spam filter without cost becomes a centralization vector. Whether it’s Google’s servers deciding you’re human or some council deciding what “legitimate”Bitcoin usage looks like. The genius of fees isn’t that they’re perfect, it’s that they’re the only decentralized solution to the spam problem that doesn’t require asking permission from anyone. Either pay in energy or pay in trust. Pick one.