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

[Chris Guida <chrisguida@gmail.com>]

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

>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.

>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.

>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
mine abusive txs, which means they will always be at least 2x more
expensive on average.

>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

--Chris

On Tue, Jun 3, 2025 at 11:58 AM Peter Todd <pete@petertodd.org> wrote:

> On Mon, Jun 02, 2025 at 08:52:15PM -0600, Chris Guida wrote:
> > "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.
>
> This is Bitcoin: there is no "official documentation".
>
> 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.
>
> > 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.
>
> 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.
>
> As with Libre Relay, I maintained a full-rbf peering fork of Bitcoin Core,
> advertising a FULL-RBF service bit, and a sufficiently large minority ran
> that
> fork to relay full-rbf replacements to the miners that were interested in
> them.
> As with Libre Relay, many of those miners didn't actually run that fork
> themselves, and instead privately peered with my full-rbf peering nodes to
> ensure they got the transactions they were interested in.
>
> Funny enough, Bitcoin Knots also sybil attacked full-rbf peering, probably
> unintentionally: Knots advertises the full-RBF peering bit without actually
> doing the peering that makes the service bit worthwhile. For awhile there
> were
> a sufficiently large number of Knots nodes that an actual full-rbf peering
> node
> would tend to have only Knots nodes as peers. While at the same time, there
> weren't enough Knots nodes to reliably propagate full-RBF replacements.
>
> I fixed this problem by running a dozen or so genuine full-RBF peering
> nodes,
> each on a different VPS, and thus diverse address space (I went through a
> list
> of Bitcoin accepting VPS's, and bought one from pretty much every VPS
> provider
> I could find in Ukraine - obviously their ISPs could use the revenue right
> now).
>
> > 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.
>
> 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.
>
>
> Anyway, I think this conversation risks wasting the time of everyone on
> this
> list, as you don't actually have anything technical to say. But I will say,
> once cluster mempool is merged in Bitcoin Core, I'd be open to working with
> anyone interested in either funding or implementing this (ideally as a
> pull-req
> to Bitcoin Core - all Bitcoin nodes have an interest in bypassing
> censorship of
> transactions they accept).
>
> --
> 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/CAAANnUwW%3DkXx1Nfgf4dyhSjh%2B-hf%2B3UB53jKvEPs3OUQbncz2A%40mail.gmail.com.

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