From: Sjors Provoost <sjors@sprovoost•nl>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man)
Date: Tue, 3 Jun 2025 08:50:34 +0200 [thread overview]
Message-ID: <4BA2B86E-3E4B-416B-9237-AFD66FC4E37A@sprovoost.nl> (raw)
In-Reply-To: <CAAANnUwHcd1w6phwyfDKebzEabAtm=A3i2qkLDpJ9L47q75T9Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4093 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 5759 bytes --]
next prev parent reply other threads:[~2025-06-03 8:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-27 11:16 Peter Todd
2025-05-27 11:37 ` John Carvalho
2025-06-03 2:52 ` Chris Guida
2025-06-03 6:50 ` Sjors Provoost [this message]
2025-06-03 17:00 ` Greg Maxwell
2025-06-05 12:16 ` Peter Todd
2025-06-03 17:41 ` Peter Todd
2025-06-03 17:51 ` Sjors Provoost
2025-06-03 20:32 ` Sjors Provoost
2025-06-03 17:58 ` Peter Todd
2025-06-04 20:16 ` Chris Guida
2025-06-05 11:59 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA2B86E-3E4B-416B-9237-AFD66FC4E37A@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox