From: Peter Todd <pete@petertodd•org>
To: Chris Guida <chrisguida@gmail•com>
Cc: John Carvalho <john@synonym•to>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man)
Date: Thu, 5 Jun 2025 11:59:09 +0000 [thread overview]
Message-ID: <aEGGjeC9FxJS0Sxt@petertodd.org> (raw)
In-Reply-To: <CAAANnUwW=kXx1Nfgf4dyhSjh+-hf+3UB53jKvEPs3OUQbncz2A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5018 bytes --]
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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aEGGjeC9FxJS0Sxt%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2025-06-05 12:56 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
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 [this message]
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=aEGGjeC9FxJS0Sxt@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--cc=chrisguida@gmail$(echo .)com \
--cc=john@synonym$(echo .)to \
/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