>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