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.