Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man)

[Chris Guida <chrisguida@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 16709 bytes --]

Hi Sjors, thanks for the thoughtful response.

>More importantly it doesn't contain any numerical analysis as to its
effectiveness.

Well, as I said, I think Peter's analysis is sufficient, and I don't think
there's much for me to add. It seems to me that Peter's analysis
effectively comes down to relative numbers of LR vs GM nodes. GM nodes will
always be able to detect LR nodes, but the reverse is not necessarily true.
To illustrate this point: once the arms race has advanced sufficiently, it
may only be possible to really detect the difference between GM and LR
*during* a spam attack, as spam filtration is just rate-limiting, not
censorship. This means that, since merely rate-limiting abusive transaction
types is sufficient to protect the network against spam attacks such as the
ones we saw from BRC-20 and Runes, GM nodes might relay *low volumes* of
spammy transaction types, because low-volume spam, while undesirable, is
not really harmful. Again, as I tried to emphasize in my prior message, the
goal is not to *censor*; the goal is to *rate-limit spam*.

Given this, it is unlikely that LR nodes will be able to reliably detect GM
nodes, except during high-volume spam attacks, and at that point, why is LR
still facilitating the attack?

>Presence on the OFAC list is an objective criterion. Your distinction
between "objective" and "subjective" seems rather arbitrary.

This is a valid criticism; you are correct that this point warrants
clarification.

When I say "subjective", what I mean is that some authority has arbitrarily
decided that certain transaction types are undesirable, without evidence of
actual harm to bitcoin. OFAC is an example of such an arbitrary criterion.
OFAC transactions do not harm bitcoin in any way, as bitcoin's purpose is
to be permissionless money. Thus bitcoin infrastructure providers should
not worry about whether some political authority has decided that certain
actors should not be able to send money. That is up to law enforcement, not
the payment network.

Conversely, inscriptions and runes are two examples of transaction types
that have produced *measurable harm* to the bitcoin network. This is not a
matter of subjective opinion, but rather of incontrovertible historical
fact. I have already produced evidence of this fact in my prior message,
which anyone can verify because it is public.

>In any case it's not relevant for the purpose of censorship resistance.

It's relevant, because certain transaction formats are known to be harmful
(ie those associated with Ponzi metaprotocols), and others are not. In the
context of censorship resistance, if transaction formats that have no
objective possibility of harming bitcoin are prohibited, then censorship
has occurred. On the other hand, if transaction formats that are
objectively known to be harmful are rate-limited, then no censorship has
occurred; rather, spam filtration has occurred. Again, I'm trying to draw a
clear distinction between censorship and spam filtration, because the
former should be considered harmful and the latter should be considered
good and necessary.

I hope that clarifies this point.

>The reality is that there are different groups using Bitcoin and they have
different opinions on which transactions it should include.

Yes, and we should rate-limit transaction formats where there exists a
rough consensus that they are harmful (rough consensus being a proxy for
objectivity), while we should not rate-limit transactions that objectively
do not cause harm. Groups that "use bitcoin" in objectively harmful ways
should not have a seat at the table.

>Governments are one such group and they could decide tomorrow to spin up a
bigger version Garbageman and disrupt the entire mempool. If they perceive
it as an attack on their interest.

Can you go more into detail about the attack that concerns you here? There
are a number of issues with the scenario you outlined here:

What is a "bigger version of Garbageman"? As I already explained above,
Garbageman does nothing to censor anything. It does not "disrupt the
mempool" at all. It merely acts as a counterbalance to LR, which has an
extremely liberal mempool policy. On the contrary, LR is "disrupting the
mempool" by filling it with junk. GM neutralizes this disruption.

Is your concern that the USG would spin up a bunch of GM nodes that don't
relay transactions from OFAC addresses? As I've already detailed, this
would be completely ineffective, as anyone can get a single transaction
confirmed if they want. There is no way the government could effect
censorship against OFAC addresses unless literally 100% of the hashrate is
filtering such transactions.

In addition to this, there have been pools (to wit, F2Pool and Mara) that
have started filtering OFAC transactions, and there was an immediate
backlash against this activity, because again, OFAC transactions are
objectively not harmful to bitcoin, and censoring them *would* be
objectively harmful to bitcoin. Neither of the pools mentioned above is
filtering OFAC transactions anymore. This is a well-documented example of
social pressure preventing mining pools from harming bitcoin in order to
bolster their medium-term profits.

>As a result everyone has to submit transactions directly to a handful of,
often US based, pools.

Can you elaborate? I'm not seeing how this would work. Again, as long as
there is one pool willing to confirm OFAC transactions, the censorship is
not effective. I'm not seeing how US authorities could compel users to use
only US-based pools.

>If we're going down the route of openly innovating attacks against the
mempool, we should also continue innovating countermeasures, as Peter Todd
did.

I am perfectly fine with devs continuing to innovate methods of avoiding
censorship on bitcoin; this will certainly come in handy if "authorities"
attempt to censor bitcoin. But again, I don't see GM as "innovating attacks
against the mempool", nor do I see it as a viable tool for censorship. GM
has exactly the same mempool policy as Knots, and no one considers Knots to
be "innovating attacks against the mempool". It just follows the same
effective mempool policy as has been in place for over a decade. GM is
merely a countermeasure against LR, which *is* a danger to bitcoin.

>This is extremely vague and avoids the question of effectiveness. What
percentage of attempted "spam" transactions are prevented from entering a
block? What's the average delay in seconds?

This would be hard to measure, because the rate-limiting comes from
increasing the cost in money, time, and frustration on the spammers. Since
I am not a spammer, it would be difficult for me to conduct an experiment
to see how fast my demand falls in proportion to the costs imposed. But it
would be completely absurd to imagine that demand for spam is completely
inelastic; that is, that demand would never fall regardless of the costs
imposed. Economic theory and historical evidence both soundly refute this
notion.

>You speak of "rate limiting", but delaying propagation doesn't rate limit
anything. Unless you completely block some percentage of transactions, the
same amount of spam ends up in blocks, just a little bit later. The rate,
e.g. gigabytes per months, stays the same.

Again, this is simply incorrect. Spam does not have inelastic demand. Spam
filtration is a deterrent, which means that its mechanism of action is
*precisely* that it reduces demand. You seem to be implying that, no matter
what the cost, a spammer who wants to get a transaction confirmed will
never give up. This claim is exceedingly dubious. If one analyzes the
problem in the context of supply and demand, it is not hard to understand
why.

If a certain percentage of the hashrate is confirming spam, let's say 20%,
then that implies that the cost to get a spam transaction mined is much
higher than the cost of a normal transaction. Specifically, since the
supply of block space available for normal transactions is 5x higher than
for spam transactions, we can expect the cost of a spam transaction to be
5x higher and/or to take 5x longer to confirm. This is just basic economics.

And again, it is a matter of uncontroversial historical fact that filters
reduce economic demand for the transaction formats they reject. See [0] for
stats about a filter that is doing a fantastic job.

>If the "spammers" use extremely naive software, perhaps they never try
again and the sybil attack was successful. But this assumes an adversary
who doesn't adapt, which is not a reasonable assumption.

The "adversary" here is scammers and their gullible marks. They can run
their Ponzis on other chains much more easily than they can run them on
bitcoin, and they are lazy. If we just treat them with the hostility they
deserve, they will just give up and spam some other chain, as they did from
2014-2023.

>Anyone would understand from their own experience if that if a transaction
doesn't go through, you try again. You don't just accept that you've been
rate limited.

Again, *to a point*. There is a certain threshold of costliness beyond
which people just say "man, this isn't worth it, let's go spam ETH
instead". And again, bitcoin achieved this for 9 years.

>The simplest next move would be for their software to just connect to more
Libre relay peers and broadcast the transaction again.

Yep, that's where Garbageman comes in! If all LR peers are eclipsed by GM
peers, then this does nothing.

>Or people can just spin up more Libre Relay nodes.

Who are these people? Altcoiners?? Yeah, right. Anyway, we can just spin up
more GM nodes.

>Both miners and issuers of various scam tokens have a monetary incentive
to do that.

If miners do this, then they are hostile. If >50% of miners are hostile,
then bitcoin is dead.

>Whereas proponents of filters are (so far) not willing to invest serious
money.

I wouldn't be so sure about that.

>E.g. when I challenged Luke Dashjr in an earlier post to reorg a single
block with spam, he didn't respond

As Peter and you yourself noted, this is unfair to Ocean.

>Worse, Ocean proactively offers "Core" [0] templates

Yes, this is another reason why it would be silly for Ocean to try to "do"
anything with its hashrate; a large portion of its hashpower is making its
own templates.

>Although running a node is cheap, if this becomes an arms race, the side
that actually spends money has the advantage.

I disagree. I think the side that wants bitcoin to survive has the
advantage, because we are going down with the ship. As previously noted,
spammers are not at all invested in bitcoin's success. We can do this all
day. They can't.

>But let's say, after all this you find a way to make Garbageman effective,
that it actually causes and sustains an economically meaningful delay
between when a transaction is submitted to Libre Relay network and when its
included in a block. Then all you've achieved is an incentive to submit
directly to miners, making those miners more profitable. Congrats, you
didn't fix spam, you didn't rate limit anything and you made mining more
centralised.

Again, if miners are doing this, then they are hostile. If >50% of miners
are hostile, then we need to know *right now* because Nakamoto Consensus
falls apart if >50% of the hashrate is dishonest. We already trust the
miners not to try to 51% attack the network with their own new rules; why
is burying bitcoin under a mountain of garbage any different, except for
the fact that it's slower and less violent?

[0]: https://x.com/oomahq/status/1916793928025596338

On Tue, Jun 3, 2025 at 2:00 AM Sjors Provoost <sjors@sprovoost.nl> wrote:

>
> Op 3 jun 2025, om 04:52 heeft Chris Guida <chrisguida@gmail.com> het
> volgende geschreven:
>
>
> Also, please let me know if this list is not the proper venue for this
> discussion. It gets kind of philosophical.
>
>
> More importantly it doesn't contain any numerical analysis as to its
> effectiveness.
>
> Spam filtration, conversely, is a rate-limiting of transactions based on
> objective criteria,
>
>
> Presence on the OFAC list is an objective criterion. Your distinction
> between "objective" and "subjective" seems rather arbitrary. In any case
> it's not relevant for the purpose of censorship resistance.
>
> The reality is that there are different groups using Bitcoin and they have
> different opinions on which transactions it should include.
>
> Governments are one such group and they could decide tomorrow to spin up a
> bigger version Garbageman and disrupt the entire mempool. If they perceive
> it as an attack on their interest. As a result everyone has to submit
> transactions directly to a handful of, often US based, pools.
>
> If we're going down the route of openly innovating attacks against the
> mempool, we should also continue innovating countermeasures, as Peter Todd
> did.
>
> Garbageman restores the balance.
>
>
> This is extremely vague and avoids the question of effectiveness.
>
> What percentage of attempted "spam" transactions are prevented from
> entering a block? What's the average delay in seconds?
>
> You speak of "rate limiting", but delaying propagation doesn't rate limit
> anything. Unless you completely block some percentage of transactions, the
> same amount of spam ends up in blocks, just a little bit later. The rate,
> e.g. gigabytes per months, stays the same.
>
> Peter's original email also doesn't answer this: presumably because he's
> trying to be generous:
>
> For a sybil attack to succeed against a non-listing node, every one of the
> N
> outgoing connections must be either a sybil attacking node, or a listening
> node
> that itself has been defeated by sybil attack.
>
>
> "succeed" here just means the transaction doesn't reach a miner in the
> initial broadcast attempt.
>
> If the "spammers" use extremely naive software, perhaps they never try
> again and the sybil attack was successful. But this assumes an adversary
> who doesn't adapt, which is not a reasonable assumption.
>
> Anyone would understand from their own experience if that if a transaction
> doesn't go through, you try again. You don't just accept that you've been
> rate limited.
>
> The simplest next move would be for their software to just connect to more
> Libre relay peers and broadcast the transaction again.
>
> Or people can just spin up more Libre Relay nodes. Both miners and issuers
> of various scam tokens have a monetary incentive to do that. Whereas
> proponents of filters are (so far) not willing to invest serious money.
> E.g. when I challenged Luke Dashjr in an earlier post to reorg a single
> block with spam, he didn't respond [1]. Worse, Ocean proactively offers
> "Core" [0] templates. Although running a node is cheap, if this becomes an
> arms race, the side that actually spends money has the advantage.
>
> But let's say, after all this you find a way to make Garbageman effective,
> that it actually causes and sustains an economically meaningful delay
> between when a transaction is submitted to Libre Relay network and when its
> included in a block. Then all you've achieved is an incentive to submit
> directly to miners, making those miners more profitable. Congrats, you
> didn't fix spam, you didn't rate limit anything and you made mining more
> centralised.
>
> - Sjors
>
> [0] https://ocean.xyz/docs/templateselection
> [1]
> https://gnusha.org/pi/bitcoindev/f348e4bf-ccc4-48e3-9745-ac72b1b131f5@app.fastmail.com/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl
> <https://groups.google.com/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAANnUyCj2cAgAG-sDZi_xOHHoEf7YO10f4XdKmSZCEDC%3DFx6g%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 20066 bytes --]