path: root/de/5b7300628fa364a627399a852cd6967ddf14cc

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 <bitcoindev+bncBDSKF7WH24FRB3NHQ3BAMGQE2NGKT7I@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <aDWfDI03I-Rakopb@petertodd.org> <CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw@mail.gmail.com>
 <CAAANnUwHcd1w6phwyfDKebzEabAtm=A3i2qkLDpJ9L47q75T9Q@mail.gmail.com> <aD83wBeeuZ32bGjz@petertodd.org>
In-Reply-To: <aD83wBeeuZ32bGjz@petertodd.org>
From: Chris Guida <chrisguida@gmail.com>
Date: Wed, 4 Jun 2025 14:16:23 -0600
X-Gm-Features: AX0GCFtuNRUbnFQ0FG6ngzSco4DL5RF4mwNWbOYm8WhxiiDwIoUgvQ6cHKdVkr8
Message-ID: <CAAANnUwW=kXx1Nfgf4dyhSjh+-hf+3UB53jKvEPs3OUQbncz2A@mail.gmail.com>
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out
 the garbage(man)
To: Peter Todd <pete@petertodd.org>
Cc: John Carvalho <john@synonym.to>, 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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <pete@petertodd.org> 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

<div dir=3D"ltr">&gt;What things mean is defined by customary usage. Which =
in this case is pretty<br><div>
clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.</div=
><div><br></div><div>I don&#39;t think a handful of nodes using a random se=
rvice bit for a couple of years qualifies as &quot;customary&quot;. The vas=
t majority of nodes do not even parse this bit.</div><div><br></div><div>&g=
t;This is nonsense. In a sense, the noderunner community *was* opposed to<b=
r>
full-rbf for a very long time: hardly any nodes relayed full-rbf replacemen=
ts<br>
until Bitcoin Core decided to turn it on by default.</div><div><br></div><d=
iv>This is merely a reflection of core&#39;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><div><br></div><div>&gt;Sounds like you don&#39;t actually have anythi=
ng to say about my proposed<br>
anti-censorship mechanism of measuring total fees relayed. That&#39;s a dec=
ent sign<br>
that it does in fact work and garbageman has no way to defeat it.</div><div=
><br></div><div>All of your mitigations can be countered with just more GM =
nodes. &quot;Private peering&quot; is not defeated by GM, but that&#39;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.</div><div><br></div><div>&gt;Anywa=
y, I think this conversation risks wasting the time of everyone on this<br>
list</div><div><br></div><div>I am down to move this conversation to a diff=
erent venue if you can suggest a better one.<br></div><div><br></div><div>&=
gt;as you don&#39;t actually have anything technical to say.</div><div><br>=
</div><div>Yes Peter, I didn&#39;t say &quot;anything technical&quot;. Not =
a single thing xD</div><div><br></div><div>--Chris<br></div><div><span clas=
s=3D"gmail-im"></span></div><div><span class=3D"gmail-im"></span></div></di=
v><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, Jun 3, 2025 at 11:58=E2=80=AFAM Peter Todd &lt;<a=
 href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 02, 2025 =
at 08:52:15PM -0600, Chris Guida wrote:<br>
&gt; &quot;NODE_LIBRE_RELAY&quot; is not defined anywhere in bitcoin core o=
r any other<br>
&gt; official documentation. Bit 29 is just a random bit reserved for futur=
e<br>
&gt; use, as far as the bitcoin protocol itself is concerned. So when Peter=
 says<br>
&gt; Garbageman &quot;falsely advertises the NODE_LIBRE_RELAY service bit&q=
uot;, this is<br>
&gt; incorrect. It is not possible for GM or any other software to misuse t=
his<br>
&gt; bit, as it has no official significance.<br>
<br>
This is Bitcoin: there is no &quot;official documentation&quot;.<br>
<br>
What things mean is defined by customary usage. Which in this case is prett=
y<br>
clear: Libre Relay is using the NODE_LIBRE_RELAY (bit 29) service bit.<br>
<br>
&gt; Peter himself, using Libre Relay, was ultimately responsible for getti=
ng<br>
&gt; this option defaulted to =E2=80=9Con=E2=80=9D in core, by taking the b=
attle directly to the<br>
&gt; mining pools. What the anti-filter crowd does not seem to realize is t=
hat<br>
&gt; Peter never would have succeeded if the noderunner community had been<=
br>
&gt; opposing him on this.<br>
<br>
This is nonsense. In a sense, the noderunner community *was* opposed to<br>
full-rbf for a very long time: hardly any nodes relayed full-rbf replacemen=
ts<br>
until Bitcoin Core decided to turn it on by default.<br>
<br>
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<br>
fork to relay full-rbf replacements to the miners that were interested in t=
hem.<br>
As with Libre Relay, many of those miners didn&#39;t actually run that fork=
<br>
themselves, and instead privately peered with my full-rbf peering nodes to<=
br>
ensure they got the transactions they were interested in.<br>
<br>
Funny enough, Bitcoin Knots also sybil attacked full-rbf peering, probably<=
br>
unintentionally: Knots advertises the full-RBF peering bit without actually=
<br>
doing the peering that makes the service bit worthwhile. For awhile there w=
ere<br>
a sufficiently large number of Knots nodes that an actual full-rbf peering =
node<br>
would tend to have only Knots nodes as peers. While at the same time, there=
<br>
weren&#39;t enough Knots nodes to reliably propagate full-RBF replacements.=
<br>
<br>
I fixed this problem by running a dozen or so genuine full-RBF peering node=
s,<br>
each on a different VPS, and thus diverse address space (I went through a l=
ist<br>
of Bitcoin accepting VPS&#39;s, and bought one from pretty much every VPS p=
rovider<br>
I could find in Ukraine - obviously their ISPs could use the revenue right<=
br>
now).<br>
<br>
&gt; Yes, I=E2=80=99m sure there are strategies for getting LR nodes to det=
ect GM nodes<br>
&gt; and banning them. And I=E2=80=99m equally sure that, if implemented:<b=
r>
&gt; <br>
&gt; 1) Very few people will run them. Only LR nodes are likely to run the<=
br>
&gt; garbage-maximizing strategies Peter outlined above. I don=E2=80=99t kn=
ow of any<br>
&gt; noderunners in their right minds who would run them.<br>
&gt; 2) The pro-spam-filtration noderunner community will work around these=
<br>
&gt; detection methods any way we can, and we will never give up.<br>
<br>
Sounds like you don&#39;t actually have anything to say about my proposed<b=
r>
anti-censorship mechanism of measuring total fees relayed. That&#39;s a dec=
ent sign<br>
that it does in fact work and garbageman has no way to defeat it.<br>
<br>
<br>
Anyway, I think this conversation risks wasting the time of everyone on thi=
s<br>
list, as you don&#39;t actually have anything technical to say. But I will =
say,<br>
once cluster mempool is merged in Bitcoin Core, I&#39;d be open to working =
with<br>
anyone interested in either funding or implementing this (ideally as a pull=
-req<br>
to Bitcoin Core - all Bitcoin nodes have an interest in bypassing censorshi=
p of<br>
transactions they accept).<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

<p></p>

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

--00000000000035b89b0636c4b41a--