From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 05 Jun 2025 05:56:23 -0700 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uNA8s-0005E8-Mv for bitcoindev@gnusha.org; Thu, 05 Jun 2025 05:56:23 -0700 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-60d6896035dsf1080761eaf.1 for ; Thu, 05 Jun 2025 05:56:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1749128177; cv=pass; d=google.com; s=arc-20240605; b=LyZgldis/ZdIOXrRV4ExSEPIwZ8CtkPwl2fsEadp83391EEhMoMAk6KChMnzz5e9+v 0kzlrkMCUr+yh77RmqEewziYy6mzNvpo7e/5uDgzNrBGVh8VkT5UDtKKYokeuEbdeQEQ f8RlIGhEGafPHTrxnr13mkJJ/d14e4EcwCm9X+87mTDaf2fPFRZid7UlQasr+XTWeGzu ZR2SMM2RbX5mgwSDULrOV4Y89rG22FGbrJkkpGMDN4P1W7e251wJcrAbYPJVWj8+6k1n 6j+1CazgZxkLxNUxrrISHepndP+gzcsF9ELUt2nPvKBLN6xUs6Y9PJ0pwzkZJZ7ikggK xo3Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=uObBK176zeT5rH1o5DefXzVnv72bnJTXrxdP3mwyO14=; fh=u6hNq2nvb/1SCYoCnhh04Rwh51zmpSoPXH1SWZTd4Bw=; b=eegZZZ9qI5NpEeJtHpT/pqbcr4Cpdmt6a+j/fhDchjwv4mkRDwcAVm+tTw6oDsj4D3 fzsuhP0xFTo0JE/Xs22zuyS7NlenDW6f45oXFkCOArEIk0AQhBthOZxczVVFTz39H2YY geEPVyr/lyfJu/6a7UyADmtsuyvJQoK7BMfYl+Y3+z510I1MudaRu2fdKU6EWxI5Vo9S 8osTHE637f1n4sMcWnFH/M11zr1ME8bW/TkGyixQ86H+/cO2wTOaBfBNBONYVbDwgU1u A8D2dsvZIDCOLviZ0+1AVrgpPxUvFwfEq+m1sQokgcZux7d7scVOqu0SfiFXTxpJDMgB 73vQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MwYaIU5c; spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f33 as permitted sender) smtp.mailfrom=chrisguida@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749128177; x=1749732977; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=uObBK176zeT5rH1o5DefXzVnv72bnJTXrxdP3mwyO14=; b=BSQNPdegwURuv1yvRPklYKrrNBFydW0VK/GWujDpFqRhyAeZ0NFj8sWs2Jv13YKWRJ 76H98R+3smBldQJWVVIpxVjr/lqKI2OsrnZ1EGNNfZ693knEhlysDcOafaDmMqgzMPNN SpVHltlR4joBMZODBZn8yOApVAuhzPnsnSUhUMmPg6Lj44W5xT5OZAe3xJTxRdeTam7u pFjIxtM2kVIdrEazcr97wGpOTIM8fmkQ1yORvlZaSjpi4JvbimWaJxfyXmNeyTu4Vt1R aSMzTEvYoJpo60P5ln/mCbzTYRtJhH9C02EzgWcBHkgRnWGlLSdyKy9nndBz+3eJf0qI pB7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749128177; x=1749732977; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uObBK176zeT5rH1o5DefXzVnv72bnJTXrxdP3mwyO14=; b=AKVeWLZYpnRm26/MG/T7/KUR/beJTgusi/4VVIuA58BaA3EALEbvc0NBbYxnntbyF+ aEU6r4rTAzxVKHwR9+Mq7nxWA/BcDZEG3LgvESvzuIU/wHf1dH8zp87RlNCjTIbfm5oy Kdl1wtK4Wd/VSE7Z/0QlbvGxafN46MR+1CyvDVZtgGBkqivBc7noFeLBMk2ekiq8cPNl Uauv2L++0N+d7gQ80Wb0x9+Adj7uMXCO8QWP/63UBkOk9hultTJu+DPCQk3n8ZlfllbP CY46eyI+LbEhGG2P19GQPok5atFYFm2QTadsyirFVX5/Z0rxxZdLW0iJAiqmSLc2/Uz+ Ma9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749128177; x=1749732977; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=uObBK176zeT5rH1o5DefXzVnv72bnJTXrxdP3mwyO14=; b=rdkr09hJfIINP/d4JXyaV5+zYcmXVaHSgeIV/117hqPp2RVLPbMUOwofPYHCapw8Cg hrkG6WA4jrXR0a8+DhrcnvKgogv3VE1u1aVnztdN2STg4ClNvyllCH07yGsT8A3fcUWL 7LCvF5dli8gYwZ4F23TH9aKriDYaAlMwMpiZwtyIqyks6hxB6uk5/CHUjiXjBKOuq/+P EPLKuVjw7uME8nQfhUpZ60q0HKvwlRxWx3f+/0613kHHG5flyYpdEAZ4oggrNIZRWK/V 1BaO4dGSZIvC0IljN7+SftDQdSaQdVKByZfRdpBZaB9ZesUVXIsDJ6HcrVKP5Od+3tW4 n4fg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWMKS+5LxMIbjAlO+apzEV2BZ1AvJy4+jsppHGFR5UKWmapPrTPrNwbXNTCRoL5Di1VFZEdgeDlm7yC@gnusha.org X-Gm-Message-State: AOJu0Yyfhn7iLYbTnD0yEfseB0MJj1BZEPuszSbMZFK/D+f0+VGtmkDv dWXDWY+k8AgKhKuhC9ERUKqrwOornA2d49xUS9+IS5QLiQ+SOTJs28C9 X-Google-Smtp-Source: AGHT+IHHhZTYPEi0vPDUaKXURhXoB0WUsdmSYyVBKoQ651LMlQgt+3MYTo61s9Ln6WZEUGD4sYRVzg== X-Received: by 2002:a05:6820:212:b0:60e:d47d:f616 with SMTP id 006d021491bc7-60f0c7f0064mr4778970eaf.3.1749128176905; Thu, 05 Jun 2025 05:56:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc2q+k9624shSFI7CrcN6xGmondYLqW9UsF6NZ6UMyZCQ== Received: by 2002:a4a:d810:0:b0:60b:e31f:50c9 with SMTP id 006d021491bc7-60f283af794ls571382eaf.1.-pod-prod-03-us; Thu, 05 Jun 2025 05:56:13 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWFT169NBDOKS9amO0/zT7eyqlsoeRLx8dv0Ff/DKGiBjXZ47c2oZgLJxjjoWF/7Lq5pZjJf2BrPThx@googlegroups.com X-Received: by 2002:a05:6808:6c91:b0:406:7054:f7ac with SMTP id 5614622812f47-408f0f93ca1mr4763192b6e.27.1749128173470; Thu, 05 Jun 2025 05:56:13 -0700 (PDT) Received: by 2002:a05:6808:6482:b0:403:484c:9068 with SMTP id 5614622812f47-408f0257a78msb6e; Wed, 4 Jun 2025 13:18:47 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWKbXA2CK/RVhZTSbm8o+fqFUJ+KZvE7wRDblUYGxz2oxODjFEVW+s1vnUgu3DSzxNoztuLoLn9ypky@googlegroups.com X-Received: by 2002:a17:90b:1806:b0:313:1e60:584d with SMTP id 98e67ed59e1d1-3131e606802mr3452731a91.11.1749068326271; Wed, 04 Jun 2025 13:18:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1749068326; cv=none; d=google.com; s=arc-20240605; b=e//YZgJ/Djt6+VG2Uraz5K2NpZUMJJXTcpf5wqZ6a6R34W8XryLhrdv2iXaVF1heG8 j7XjoswGte68WOm08oVKzpnB3I09VcHkonKglj+0nBfWhRs78KocmGtn/tM5V4umlpnt MZ5hUyrTtkb0UDf2gmvwerS2q9ij3isWOBZ5/ecxgiTHltrBbnmnxrNtYVU+o0jygv1q +xwunC6xACTlTDl5BAY51ptGxu9iAPii2/c47pHmMwKc9bLHAT3asdvIWj/znJHFyixc ODFH4lzCBGlWwBpr0iekpiQm+CoSlx0Va1ONFkoc5i6i8YC1ufmW5RQW3dd2+2nQcOzT ZX2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=hsh4jY6cpQqOrXV/3z/q7gxfWOHvREQG7LNlsS8oY58=; fh=AWDiN+omN0VPq3F9HVclc+ik+ypb9sn2O1CdVVQSK08=; b=gSSg58McAtxABojJofoOgK8ITw3yPuui31GdNJ1V2X0wTBK9yCoKS+U5c0RuWQVDnB VKlBBDLns+pDHJ0JSeU+Psi51osMqGgHHvpFy1yenSlC56MSMcl35wmtaRnYvHQ9yon+ kgNSJ6EIdZAuH+jo1gxLvkh2VUrUxWOqsyIOzdQL5XXDuX/BnSKADZPs4MmSvw5CYP0Z M16tGIH9wLbFcCj/MNthj3LCmFzjHhYQh5vxHsvHBiYWiB83wXcbBn/vKw9ZSnE2V2Ga cLU1x5MKbZMk8Hi9uK0YvDqmMwVcRGzqPXYtCxRSHtBIwahXVA2gv+snIWw0XHcSqF0T O2/Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MwYaIU5c; spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f33 as permitted sender) smtp.mailfrom=chrisguida@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com. [2607:f8b0:4864:20::f33]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3132c07497asi5779a91.2.2025.06.04.13.18.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jun 2025 13:18:46 -0700 (PDT) Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f33 as permitted sender) client-ip=2607:f8b0:4864:20::f33; Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-6fadd3ad18eso3679636d6.2 for ; Wed, 04 Jun 2025 13:18:46 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCU/eN9B7gzHxmiqlK87/JcCTuYWpwLMJhbNPaEZNIzmaf+gJ72uEay4y8Lkw/ToSMSiYBE/2Y2TM+Nr@googlegroups.com X-Gm-Gg: ASbGncvEk25kZqq2YGipP4FwXHe0vLJli5+EZqwhGDPcXigqqMVMK6Ui5j3w0101Po2 5sSUhnq50cBT0N1RQaKn6tEKFElbcQCWdIuKylUDfjBwfWVCYu6w4p//VXRVAvgiUIyitF5Uv3U WK9ORMVlK9meGV+YO13XSxX6PCTeAltlmb X-Received: by 2002:a05:6214:301a:b0:6f8:d223:3c32 with SMTP id 6a1803df08f44-6faf6e867damr67134676d6.10.1749068325171; Wed, 04 Jun 2025 13:18:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Guida Date: Wed, 4 Jun 2025 14:16:23 -0600 X-Gm-Features: AX0GCFtuNRUbnFQ0FG6ngzSco4DL5RF4mwNWbOYm8WhxiiDwIoUgvQ6cHKdVkr8 Message-ID: Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man) To: Peter Todd Cc: John Carvalho , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="00000000000035b89b0636c4b41a" X-Original-Sender: ChrisGuida@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=MwYaIU5c; spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f33 as permitted sender) smtp.mailfrom=chrisguida@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --00000000000035b89b0636c4b41a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >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=E2=80=AFAM Peter Todd wro= te: > 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 th= is > > 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 gettin= g > > this option defaulted to =E2=80=9Con=E2=80=9D in core, by taking the ba= ttle directly to > the > > mining pools. What the anti-filter crowd does not seem to realize is th= at > > 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 t= o > ensure they got the transactions they were interested in. > > Funny enough, Bitcoin Knots also sybil attacked full-rbf peering, probabl= y > unintentionally: Knots advertises the full-RBF peering bit without actual= ly > 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 peerin= g > node > would tend to have only Knots nodes as peers. While at the same time, the= re > 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 righ= t > now). > > > Yes, I=E2=80=99m sure there are strategies for getting LR nodes to dete= ct GM > nodes > > and banning them. And I=E2=80=99m 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=E2=80=99t kno= w 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 decen= t > 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 sa= y, > once cluster mempool is merged in Bitcoin Core, I'd be open to working wi= th > 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 > --=20 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 e= mail 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. --00000000000035b89b0636c4b41a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>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 se= rvice bit for a couple of years qualifies as "customary". The vas= t majority of nodes do not even parse this bit.

&g= t;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 replacemen= ts
until Bitcoin Core decided to turn it on by default.

This is merely a reflection of core's defaults which, indeed, are qu= ite sticky. But everyone I spoke to who understood the issue decided to tur= n fullrbf on. You probably could have succeeded with just a bit more lobbyi= ng of the node network, without using LR at all. But, sure, LR was faster.<= /div>

>Sounds like you don't actually have anythi= ng to say about my proposed
anti-censorship mechanism of measuring total fees relayed. That's a dec= ent 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 re= ally no more impactful than direct-to-miner submission anyway. That is coun= tered 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 m= ost half the hashrate will mine abusive txs, which means they will always b= e at least 2x more expensive on average.

>Anywa= y, I think this conversation risks wasting the time of everyone on this
list

I am down to move this conversation to a diff= erent venue if you can suggest a better one.

&= gt;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=E2=80=AFAM 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 o= r any other
> official documentation. Bit 29 is just a random bit reserved for futur= e
> use, as far as the bitcoin protocol itself is concerned. So when Peter= says
> Garbageman "falsely advertises the NODE_LIBRE_RELAY service bit&q= uot;, this is
> incorrect. It is not possible for GM or any other software to misuse t= his
> 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 prett= y
clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.

> Peter himself, using Libre Relay, was ultimately responsible for getti= ng
> this option defaulted to =E2=80=9Con=E2=80=9D in core, by taking the b= attle directly to the
> mining pools. What the anti-filter crowd does not seem to realize is t= hat
> Peter never would have succeeded if the noderunner community had been<= br> > 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 replacemen= ts
until Bitcoin Core decided to turn it on by default.

As with Libre Relay, I maintained a full-rbf peering fork of Bitcoin Core,<= br> advertising a FULL-RBF service bit, and a sufficiently large minority ran t= hat
fork to relay full-rbf replacements to the miners that were interested in t= hem.
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<= br> ensure they got the transactions they were interested in.

Funny enough, Bitcoin Knots also sybil attacked full-rbf peering, probably<= br> unintentionally: Knots advertises the full-RBF peering bit without actually=
doing the peering that makes the service bit worthwhile. For awhile there w= ere
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 node= s,
each on a different VPS, and thus diverse address space (I went through a l= ist
of Bitcoin accepting VPS's, and bought one from pretty much every VPS p= rovider
I could find in Ukraine - obviously their ISPs could use the revenue right<= br> now).

> Yes, I=E2=80=99m sure there are strategies for getting LR nodes to det= ect GM nodes
> and banning them. And I=E2=80=99m equally sure that, if implemented: >
> 1) Very few people will run them. Only LR nodes are likely to run the<= br> > garbage-maximizing strategies Peter outlined above. I don=E2=80=99t kn= ow 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 dec= ent 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 thi= s
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 censorshi= p of
transactions they accept).

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.co= m/d/msgid/bitcoindev/CAAANnUwW%3DkXx1Nfgf4dyhSjh%2B-hf%2B3UB53jKvEPs3OUQbnc= z2A%40mail.gmail.com.
--00000000000035b89b0636c4b41a--