Good morning, list!

That seems like a good analysis, Peter, thanks for writing that up.

The following is an explanation of why I decided to create Garbageman. Apologies for its length. I tried to make it shorter, but I felt like I needed a lot of space to catch everyone up to the pro-filtering (pro-rate-limiting) position, which I’ve not seen represented much on this list. Please reach out to me if you need something clarified or if I got anything wrong. I am constantly revising my position based on new information, so please do not interpret it as carved in stone.

Also, please let me know if this list is not the proper venue for this discussion. It gets kind of philosophical.

For those who don't know, I made Garbageman as a hackathon project to demonstrate that the battle against spam is not hopeless.

The project's mission of stopping Libre Relay's spread of garbage around the bitcoin network has proven very popular among noderunners, so I decided to continue developing it in order to meet this demand.

As I've discussed the spam issue with many, many people over the last couple of years, I've noticed that those in the anti-filter camp often use LR as a rhetorical device, effectively arguing "there's no way to stop this". Well, Garbageman is an assertion to the contrary. I think the battle should be fought, and that we should see how it plays out, because I think we can win. For me, winning means keeping bitcoin both spam-resistant and censorship-resistant.

Almost no one I've ever talked to likes the spam, even those in the anti-filter camp. Likewise, almost no one I know who runs a node wants to relay non-monetary transactions. But bitcoiners are feeling demoralized after the BRC-20 attack of 2023-24, which expanded the utxoset from 5GB to 12GB [0], significantly raising the minimum cost of a bitcoin node, while core maintainers refused to accept PRs that would have mitigated the spam. So I hope that Garbageman can be a demonstration that all is not lost, and that noderunners who wish to shoulder some responsibility can make a big enough impact to deter spammers, if we all work together.

Peter's OP, while containing a lot of useful analysis, also contains some inaccuracies I would like to correct.

While Peter characterizes Garbageman as an "attack" - and he is correct that it is an attack on Libre Relay - what he leaves out is that Libre Relay itself is an attack on bitcoin, and thus Garbageman is a defensive measure from the point of view of the bitcoin network.

Specifically, Libre Relay facilitates denial-of-service attacks on bitcoin, because it assists Ponzi promoters in launching their Ponzis using metaprotocols directly on bitcoin, which, as we've seen with past waves of spam, can easily overwhelm block space, sending fees sky-high for months on end. This of course crowds out real monetary usages, such as merchants in developing countries trying to start self-custodial Lightning points-of-sale. It also tends to encourage utxoset bloat (even if the arbitrary data itself is not stored in the utxoset, as we saw with BRC-20's ~tripling of utxoset data [0] using the inscriptions hack to stuff data into the witness).

That is to say: Libre Relay intentionally increases the likelihood that people will not be able to use bitcoin as money. Permissionless money is, of course, the primary service that bitcoin offers, and its entire reason for existence. So when Libre Relay facilitates the mining of transactions associated with altcoin Ponzis on bitcoin, it is actively complicit in perpetrating denial-of-service attacks against bitcoin.

LR operates by using the peer relay network in an unintended way. It attempts to circumvent filters active on honest nodes by preferentially peering with other LR nodes. Garbageman subverts this mechanism by signaling on the same bit that LR nodes use to identify other LR nodes, then throwing away any garbage that comes its way. Assuming that noderunners who don't like spam vastly outnumber those who do (very likely in my experience), it should be fairly straightforward to protect bitcoin against LR's abuse by using up the preferential connections on LR nodes, preventing them from finding each other.

"NODE_LIBRE_RELAY" is not defined anywhere in bitcoin core or any other official documentation. Bit 29 is just a random bit reserved for future use, as far as the bitcoin protocol itself is concerned. So when Peter says Garbageman "falsely advertises the NODE_LIBRE_RELAY service bit", this is incorrect. It is not possible for GM or any other software to misuse this bit, as it has no official significance.

Peter also claims that the Garbageman noderunner community's goal is to "[prevent] people from getting transactions that they disagree with mined". This is also false. In this claim, as filter opponents often do, Peter is conflating spam filtration with censorship. They are, however, complete opposite ends of a spectrum.

Censorship is the complete or near-complete prohibition of transactions for subjective reasons, usually according to some kind of "blacklist" like OFAC. Such behavior is obviously extremely harmful to bitcoin, as one of its core properties is censorship resistance (aka permissionlessness). Luckily, censorship on bitcoin is extremely unlikely, given that just one block template creator with a small percentage of total hashrate can mine whatever transactions it wants. As opponents of filtering love to point out, the miner can even solicit such transactions out-of-band, avoiding mempool filters entirely. They almost never realize that they are merely bolstering the view that bitcoin is hard to censor, and not that it is hard to deter spam on bitcoin.

Spam filtration, conversely, is a rate-limiting of transactions based on objective criteria, which serves to deter, but not completely block, the creation and confirmation of abusive transactions into the chain. Spam filtration, in contrast to censorship, is harmless, and in fact absolutely essential to bitcoin's survival. Why? Because bitcoin's purpose as money is impossible to codify into the consensus rules. Even if we activated some kind of hashing or signing scheme to prevent arbitrary data by consensus (such as the one from Greg Maxwell that Peter brought up in an earlier thread [1]), such a change would still not fully prohibit the abuse of key grinding, etc, for storing arbitrary data (though it would increase costs substantially).

What this means is that bitcoin's identity as money is only enforceable at the social and mempool policy layers. So when core devs enumerate the "three reasons" [2] mempool policy exists, they are missing reason 4:

4) Making sure bitcoin stays money


A blockchain's technology is tightly intertwined with its culture. We've seen historical examples of how tech influences culture, and vice versa. Some examples:

- In BSV, the blocks are so huge and the transaction set so unwieldy, that everyone thinks it's absurd for individuals to run nodes (because it is).
- In Ethereum:
- In Monero, the supply is difficult to audit - so everyone thinks that auditing the supply is unimportant.

The list goes on and on. The point is that, if we still want bitcoin to be money in a few years, we need to fight to make sure that monetary transactions dominate, and that other use cases do not get the upper hand. If making payments with bitcoin becomes too difficult, then the culture will simply stop valuing payments.

We've already seen a concerning shift in this direction over the last decade as the Lightning Network has been getting built out. During that time, bitcoin’s culture has shifted such that statements from prominent figures unironically discourage spending bitcoin at merchants that directly accept it. Getting Lightning to where it is today took 4 soft forks, a fork war, and a decade of hard work from some of our best devs. Now that Lightning works, we should go all-in on making sure merchants are adopting it, instead of letting non-monetary use cases drown it out.

The anti-filter side seems to think that other use cases cannot drown out the monetary use case, because of transaction fees. In order to believe that fees are sufficient to make sure bitcoin stays money, you'd have to assume that cloud storage with ironclad censorship resistance, immutability, and availability guarantees, for any arbitrary data, for a single upfront fee, for the rest of eternity, would have less demand than Lightning channel opens and closes. This claim seems terribly dubious to me, as it’s already been proven that Ponzi gamblers are willing to dump millions of dollars into fees in order to store their garbage. And we haven’t even cracked the surface of all possible non-monetary “use cases”, because bitcoin’s maintainers have historically been hostile to these uses, so the vast majority of their would-be creators have simply not even considered bitcoin an option.

Currently, however, core devs are very fond of "incentive compatibility" (or "consensus maximalism"). As far as I understand it, this means making mempool policy as close as possible to the consensus rules, so that miners can maximize their short-term profits. While this is a good thing to design for generally because it makes bitcoin much more predictable, it becomes harmful when taken to its logical extreme. Since bitcoin's identity as money cannot be enforced at the consensus layer, and since non-monetary use cases have orders of magnitude more economic demand than monetary ones, incentive compatibility, when maximized above all other concerns, means stuffing bitcoin with as much meaningless garbage as possible. This implies that incentive compatibility is ultimately incompatible with bitcoin remaining money.

Sensible mempool filters are thus the single most powerful tool in our arsenal for giving Lightning a fighting chance and making sure bitcoin stays money for the long term. In addition to sending a strong social signal as to what noderunners prefer, they also allow the relay network to raise costs on spammers, while giving a free ride to actual payments, which are the whole reason the relay network exists. They are the only way I know of for bitcoin’s social layer to exert direct economic pressure on spammers.

Yes, there are most likely slight centralization pressures that can result from large miners soliciting high-fee spam out-of-band, but if enough noderunners are filtering abusive transactions, miners confirming large amounts of these transactions can be seen as hostile, and hostile mining pools have historically yielded to sufficient social pressure, because for a mining pool, social pressure often translates, directly or indirectly, to economic pressure.

If mining pools persist in mining blocks filled with garbage, that will be a sign that we need to break up the mining pools (by encouraging their hashers to boycott them), or, in extreme cases, to fire the miners by changing the PoW algorithm. It would seem that sensible mining pool operators would stop misbehaving well before this point, to avoid undermining their (presumably large) investment.

Fortunately, if the community of noderunners comes together and decides on sensible defaults, the mining pools have historically heeded its decisions. Prior to mempoolfullrbf, it was rare to see mining pools flouting the will of the noderunners. This is because the core maintainers always listened to the noderunners when deciding on the default mempool policy. However, for some reason, in the case of mempoolfullrbf, core devs decided to keep it defaulted to “off”, even though the vast majority of noderunners felt that it was a sensible thing to turn on. I worked at a company that provides turnkey bitcoin nodes during that episode, and we even exposed mempoolfullrbf as a config option because users wanted to be allowed to turn it on.

Peter himself, using Libre Relay, was ultimately responsible for getting this option defaulted to “on” in core, by taking the battle directly to the mining pools. What the anti-filter crowd does not seem to realize is that Peter never would have succeeded if the noderunner community had been opposing him on this. Practically everyone agreed that fullrbf was long past due, except a handful of people who didn’t understand that zeroconf is fundamentally insecure, and that Lightning is way better if you don’t want to wait for a confirmation.

Peter should be commended for finally getting fullrbf active on mainnet. But Libre Relay has now outlived its utility. LR has now been converted into a tool for strong-arming core into removing all its filters, and shoving garbage down everyone’s throats. Though noderunners were happy to go along with LR when it was just about getting fullrbf activated, we are overwhelmingly opposed to raising datacarrier limits. Garbageman is the manifestation of that opposition.

Garbageman protects the bitcoin network by facilitating spam filtration, an essential function for bitcoin, while avoiding censorship. So Peter's chosen subject line, "Censorship Resistant Transaction Relay", is misleading. What he really means is "Spam-Filtration-Resistant Transaction Relay" which, of course, is not desirable at all.

Yes, I’m sure there are strategies for getting LR nodes to detect GM nodes and banning them. And I’m equally sure that, if implemented:

1) Very few people will run them. Only LR nodes are likely to run the garbage-maximizing strategies Peter outlined above. I don’t know of any noderunners in their right minds who would run them.
2) The pro-spam-filtration noderunner community will work around these detection methods any way we can, and we will never give up.

Libre Relay is a direct threat to bitcoin’s ability to remain money, and the threat must be countered.

Garbageman restores the balance.

Best regards,

--Chris Guida

[0]: https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=10m&viewPanel=8&from=1588309200000&to=now
[1]: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ
[2]: https://gist.github.com/instagibbs/c436110890ab25aa9997b13c2270d5ce#why-standardness-policy-exists