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

From: Peter Todd <[email-masked]>
Date: Thu, 5 Jun 2025 11:59:09 +0000

On Wed, Jun 04, 2025 at 02:16:23PM -0600, Chris Guida wrote:
> >What things mean is defined by customary usage. Which in this case is
> pretty
> clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.
> 
> I don't think a handful of nodes using a random service bit for a couple of
> years qualifies as "customary". The vast majority of nodes do not even
> parse this bit.

You admit that Libre Relay nodes customarily use that service bit: as you
openly claim, the whole point of garbageman is to perform a sybil attack
against the nodes using that service bit.

> >This is nonsense. In a sense, the noderunner community *was* opposed to
> full-rbf for a very long time: hardly any nodes relayed full-rbf
> replacements
> until Bitcoin Core decided to turn it on by default.
> 
> This is merely a reflection of core's defaults which, indeed, are quite
> sticky. But everyone I spoke to who understood the issue decided to turn
> fullrbf on. You probably could have succeeded with just a bit more lobbying
> of the node network, without using LR at all. But, sure, LR was faster.

Bitcoin's technical functioning has nothing to do with the state of mind of
people running nodes: what matters is what nodes actually did. As I said, the
vast majority of nodes were running with full-rbf relaying off until Bitcoin
Core changed the defaults. That was technical opposition, and full-rbf peering
code defeated that opposition.

> >Sounds like you don't actually have anything to say about my proposed
> anti-censorship mechanism of measuring total fees relayed. That's a decent
> sign
> that it does in fact work and garbageman has no way to defeat it.
> 
> All of your mitigations can be countered with just more GM nodes. "Private
> peering" is not defeated by GM, but that's really no more impactful than
> direct-to-miner submission anyway. That is countered by assuming that less
> than half of hashrate is hostile, which is the base assumption of bitcoin
> anyway. If true, this assumption means that at most half the hashrate will
> expensive on average.

That's just not how fees work: https://opreturnbot.eldamar.icu/

> >Anyway, I think this conversation risks wasting the time of everyone on
> this
> list
> 
> I am down to move this conversation to a different venue if you can suggest
> a better one.
> 
> >as you don't actually have anything technical to say.
> 
> Yes Peter, I didn't say "anything technical". Not a single thing xD

What you just said above is a great example of the lack of technical rigor in
your discussion: your just making a bald assertion that "All of your
mitigations can be countered with just more [garbageman] nodes." You're not
making a concrete technical claim here. You're just saying that. And you add to
that nonsense with an entirely unrelated and irrelevant digression about hash
power.

Here's what an actual technical analysis would look like:

Suppose that there does *not* exist a Libre Relay service bit. For sake of
argument, let's say that the only mechanism that Libre Relay nodes find each
other is via next-double-block total fee advertisements. We'll also assume that
*all* nodes support this mechanism. Every t seconds on average, assume that a
Libre Relay node drops its peer advertising the smallest total
next-double-block fee, and tries a different peer.

Since there is no Libre Relay service bit, garbageman nodes are in fact
irrelevant to this discussion. As I covered in my previous writeup, total fee
advertisements can't be fooled: either you do in fact propagate the
transactions whose fee you advertise, or you don't. If you lie, you're node is
going to be banned.

Finally, let's assume that there are always enough extra Libre Relay
transactions to make a "noticable" difference to peering. Basically, enough
extra fees that the extra fees show up over the inevitable noise you'll see in
peering policies.

If the ratio of nodes without Libre Relay peering policies to nodes with Libre
Relay peering policies is q, the total average time it will take for a node to
find another Libre Relay compatible peer is just q*t.

For example, if t=120s, and q=1000, (e.g. 40 nodes out of the ~40,000 IPv4
listening nodes that bitnodes.io is reporting at the moment) it'll take 1.4
days on average for a Libre Relay node to find another compatible peer. Not
particularly fast. But even in this circumstance, with a 1000-to-1 ratio
against you, Libre Relay nodes would have a decent set of peers in a week. And
obviously, we can improve that time further by connecting to more peers and
trying to find two or three better ones at once.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aEGGjeC9FxJS0Sxt%40petertodd.org.