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/aD83wBeeuZ32bGjz%40petertodd.org.