path: root/69/ce1cc6114bd2befc63bfb24967884ba7deff1a

Delivery-date: Mon, 02 Jun 2025 20:34:30 -0700
Received: from mail-qk1-f188.google.com ([209.85.222.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDSKF7WH24FRBN627HAQMGQEWHBMRRA@googlegroups.com>)
	id 1uMIPy-0008I0-Fg
	for bitcoindev@gnusha.org; Mon, 02 Jun 2025 20:34:30 -0700
Received: by mail-qk1-f188.google.com with SMTP id af79cd13be357-7d09ed509aasf740082085a.3
        for <bitcoindev@gnusha.org>; Mon, 02 Jun 2025 20:34:26 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1748921660; cv=pass;
        d=google.com; s=arc-20240605;
        b=G+pA3C8Z5T9iiWbMeTNTdGXQG09FgvdkNfRfzbe3EGvC3Bl2gIrvhWXtxUV60idq8V
         3UQOTUCyBr5pxzamLdE2vSBsGjzK8Lr61kAdi5iFVqELMVLaCm0Sfz/aHVsKpvzNkSWA
         YulRwIyphqKu5zw9TpM1WNboCulOMISA1V2lyOepCQIb6xBjbmTuxiQlDLTB26IiAbaw
         N1AeffEzxgDKaxT/RFD2dHXK9ZnOZbS21i/6YqsDxA7VLWJN/bwQ9bPUxkP0JhPzEwyO
         BW0Ggy5XVT7z2ICnvLzga004qTGk2mje8RFWGpQj/BIWA2YM9FCEIQlWTDgu3ymo+2GE
         Ed0A==
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=wPduGqhS4AwbGqsbZlrrF7S/kqeZWKEjiE+aALqAdp4=;
        fh=RyjdHZp36SdOA2/baRy1C13CA+fe/sTzu/oNpJ/KwwY=;
        b=YE9CaDIHV290C9Q5Rd4sfCfficeNeCJJKBWy/R7tKPhT2H7oHNw2T+8KmsFwL+32dV
         vvUIVGKEpPDefbgW8PSpk7aN9XDDCxqM6Mo4WhPTeYzPzlTHl1+B5k5odpCHznc3J+/T
         tYu5lX4Az6sobohpjZ7DDXbzV/74uogUkCIDiOu/HDgvoe4tTwYCtLnpVIgz23Lbwcfl
         6HGN+XyUWNcO9sRNgbTis40uftbE3C+d2CY+OtxVKG+jaQybIxhEwT0cod6vUOt5LJ6Z
         fe5wNn+OGe2VVgaTzA9RT/RTd6sltNPGRsBNsrfCebUfuTxobL7DBn9A0Q/MdbcrF9W7
         PmLQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=muSenHbw;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2c 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=1748921660; x=1749526460; 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=wPduGqhS4AwbGqsbZlrrF7S/kqeZWKEjiE+aALqAdp4=;
        b=s5B3YVcm6rAm2NTJsL8Yw5xrUaBfQgv/XXH5Ci7JVst3mhU7ExZYzyjvOWDsUZ5S22
         Csbug/cKB8aIm0FaduhstqVt9zFOaTd1xpitslGX6WlSFo4/hg0g4qkITPYCYGbpERwt
         BhTWZQwRe8+nMncYhwejKgwqy7vEu3G00tkxkT3+BLaR0wsbS6OvgfUiRj95HBmXPnVn
         Seu+x6UfxgMxjUHg6tC3XVNRxI3vqLHASIC74DO60hwmzAm0cBYSz/o+fdBr3P9kqBgJ
         /tM2rBAtI/mTneQuFHKkR2rHGi3piayAyRK+h+xeFUQk6hfUxgE4cdidjY5E5vPv932a
         6yVA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748921660; x=1749526460; 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=wPduGqhS4AwbGqsbZlrrF7S/kqeZWKEjiE+aALqAdp4=;
        b=hSB5zrKhQcScR71Ic3XNxcmNV+h/G40rFiGFCuumvlyEm0+7agbQyYMkLli4h8/1aH
         KxI4k8YVceGKGRBZE4CjMYMNCAjwVy7xiLyt6MFkf8su8abq0yVLsKTm2L9j5JquuExO
         9VqlA95uhSdRlELysjCbeuGVSMOsqGBmDaaU+PWHl0kOPB9xt9SP4EQ4AhmQeFz8FWLz
         eTC2DahEp9lqQhKMJm801UpVHi7878i2nys5jaEff6kdeb+SW550FdJa99JGbWGBc31d
         WBaiqXfUNhr4b6MkOP1AsyEyFbukptfmp1Kq8yrytDI2lgIVnRLPTqsf3DPZE6Qbm3ov
         +ggA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748921660; x=1749526460;
        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=wPduGqhS4AwbGqsbZlrrF7S/kqeZWKEjiE+aALqAdp4=;
        b=iGK9WteGmb1OFpgblGxqwG77CrxqqtqkliewzjZseNOTfbHJdCxmyzDTdIIVm94wVW
         gzw8dqvX+YORNk3pktmu+9iBxNSt3BL+q1MI1Rz3n5GM6GEq7YT2NX151n0s8M3UY00a
         W9w8TH0ksFKRieXj7VIesyaNjVjWGcR7HIUz/Jh7QqOrQAip25M/htCqZqmvMiK1np8L
         Mu5Jd3hk31AmDw9rHcL1lOoNrThgZ/j3I+CJ1vtRB4EXRUK4LePA3i54GQVi0TIY+NDp
         hYpbzC3o0yGRZC81lIVYNKe2T5Ko4YlPjnfkVOhTmX9i2W6ZClXNeqgK0zKXK9EJ1Rkx
         tQiA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXS1yyu19cJtUeSogsD349dyAC4d2fsO5J85xt3A/n/htnoKRoTO42w4EjIQnFQK2TuZoH75S1I2VC7@gnusha.org
X-Gm-Message-State: AOJu0YypvJwepLXIcNSfXs48fmjUqRQQk16q0PujaKNsBLyYDdLbdie5
	cB+lJFB8yEW/CvL7ES//vJRvYI7Gl+zdZw6O77/ZZWAEBcfLl3dw4Hiu
X-Google-Smtp-Source: AGHT+IHKWA9c5OqPgDotmdTFvdrlnQq7l+lyQTltnr+SEzYHtzXQXGCuwVIIms6Len7OCOoY7rDVEQ==
X-Received: by 2002:a05:620a:1a1d:b0:7cd:5b2a:979e with SMTP id af79cd13be357-7d0a1fbddcdmr2488041285a.30.1748921660070;
        Mon, 02 Jun 2025 20:34:20 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZej7zHJDEGpuBoCrpVdxlL0BNC/R9g3sFNoDXiVRlpbqw==
Received: by 2002:a0c:f902:0:b0:6fa:bb85:f1b9 with SMTP id 6a1803df08f44-6fac5d6f107ls77937976d6.2.-pod-prod-03-us;
 Mon, 02 Jun 2025 20:34:15 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVTfU84DjP0fdC19vLQa/S4y1YCYr4WlGQb9XzKqDEPpRyDYHmJajHmVL2N0pD7X2M21y5kepP/a100@googlegroups.com
X-Received: by 2002:a05:620a:a70c:b0:7d0:9a80:1ea1 with SMTP id af79cd13be357-7d0a1f9829cmr2054153085a.1.1748921655599;
        Mon, 02 Jun 2025 20:34:15 -0700 (PDT)
Received: by 2002:a05:620a:27cc:b0:7c5:3b15:3956 with SMTP id af79cd13be357-7d210d61645ms85a;
        Mon, 2 Jun 2025 19:54:39 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUQic0Bv2GJd41LzatzZ7C67LfeyvflyQUgTTGy+Qjm0HfOrw0hkRql5VMjYk0lW3ecX/S7hmhYp7ED@googlegroups.com
X-Received: by 2002:a05:620a:2720:b0:7c7:6667:ade5 with SMTP id af79cd13be357-7d0a1fbd32dmr2356480085a.27.1748919278508;
        Mon, 02 Jun 2025 19:54:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1748919278; cv=none;
        d=google.com; s=arc-20240605;
        b=Hqn6mWNHoQAZBOp4mxfckVcRBpF/OvI/Dnksm3Sx18Nt1aLZhXuHg/jMeELim7AFQQ
         7Xo7Nh9cVkvUknhOQXVGOCqhjiInNqRfClMTMuCXDpifEU1qXE2UQolSKL0qvNoUMJqe
         Snqba3fjd9VgvX9QhJccXjufYA+MYwlOcCyQWTUK3HtwihSJngRf4FmqyBy4uFdLqZZ5
         SVA83mMKraecUqlLXNYkTaATggdalp0bJ51tVXKfBcPdE2yi+fpFt82awJerWiodM4MV
         nVEbF9NXANKmU1Kh+Gg19WT5K/e+tBwUoLvVE/LHmnLWlJHP1zLs+O5+DMfAiLJgI10k
         43qg==
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=TmumBnV2Y4I9yAkqDWd3Y+s4IEQw6c5RdYjsz4SneRs=;
        fh=yE9jiRwaXpxM69+9PWqYWqwUE3bnbed7pP9PdVwOHkM=;
        b=RKBgleZSKJGje6uQTL0goVzs801hTlW+4h+1kfWgH8XbhcsviEMMJKm998mBjIfaL+
         U9s6HQF+NJuBU8ssKejGYjQ9D5F6/R3zjiVIQtJGRbYlHgyJydf5b00nHKjvxJZ4OtjM
         V+rAXJsN636kSUEZK/osu56dELewOTVQAdGwTdH+oX1O/SyDkhybAfqprph6rhJnXf8a
         g6TssKKAEv0+JEll9I8a6z9ke+oG4Pcl0QY7avh0X+QFhKN2Scn9exsz7yT+0RBHPLnZ
         GoZ2NGFUOnlq++OzCCBtGq/wZe3AV3T37Pn111uI8ZQmDXmIKpW6+XujiXHW+H/6HRny
         B4vg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=muSenHbw;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2c 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-xf2c.google.com (mail-qv1-xf2c.google.com. [2607:f8b0:4864:20::f2c])
        by gmr-mx.google.com with ESMTPS id af79cd13be357-7d09a0e295dsi48606985a.2.2025.06.02.19.54.38
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 02 Jun 2025 19:54:38 -0700 (PDT)
Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2c as permitted sender) client-ip=2607:f8b0:4864:20::f2c;
Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-6fad3400ea3so34027256d6.0
        for <bitcoindev@googlegroups.com>; Mon, 02 Jun 2025 19:54:38 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCXxFfbGUjs90j+fTZIzHaHylEt449TAD2HI2ZKO34S+ELz6Vmz220/D9xSz9MCc/6tyHHlrzjtn3eB0@googlegroups.com
X-Gm-Gg: ASbGnctt3re+czOJw87UZ3xIm+PdC/UTEF+OX9UVd/ngD/Rr8G1cjal8zgslrS+ye47
	+KaEpbFfvvw3UiCt2Z2dkKF6QMqisempSCxwpgEDzaaE+9tl7OqjyHqGqRYPVYoMohHM6hu/Zii
	fI3cH0aIye3yd2kIsdj+AgCP2NABrZd6B7
X-Received: by 2002:a05:6214:2583:b0:6e6:5bd5:f3a8 with SMTP id
 6a1803df08f44-6faced2536cmr217588426d6.29.1748919277769; Mon, 02 Jun 2025
 19:54:37 -0700 (PDT)
MIME-Version: 1.0
References: <aDWfDI03I-Rakopb@petertodd.org> <CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw@mail.gmail.com>
In-Reply-To: <CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw@mail.gmail.com>
From: Chris Guida <chrisguida@gmail.com>
Date: Mon, 2 Jun 2025 20:52:15 -0600
X-Gm-Features: AX0GCFt0rHWTSvC7-dl9KdZt1I9NbaxEGrlVjj5YtxGoUTQmwPavalk19n6oeAs
Message-ID: <CAAANnUwHcd1w6phwyfDKebzEabAtm=A3i2qkLDpJ9L47q75T9Q@mail.gmail.com>
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out
 the garbage(man)
To: John Carvalho <john@synonym.to>
Cc: Peter Todd <pete@petertodd.org>, bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="0000000000004ada780636a200dd"
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=muSenHbw;       spf=pass
 (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2c
 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 (/)

--0000000000004ada780636a200dd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Good morning, list!

That seems like a good analysis, Peter, thanks for writing that up.

The following is an explanation of why I decided to create Garbageman.
Apologies for its length. I tried to make it shorter, but I felt like I
needed a lot of space to catch everyone up to the pro-filtering
(pro-rate-limiting) position, which I=E2=80=99ve not seen represented much =
on this
list. Please reach out to me if you need something clarified or if I got
anything wrong. I am constantly revising my position based on new
information, so please do not interpret it as carved in stone.

Also, please let me know if this list is not the proper venue for this
discussion. It gets kind of philosophical.

For those who don't know, I made Garbageman as a hackathon project to
demonstrate that the battle against spam is not hopeless.

The project's mission of stopping Libre Relay's spread of garbage around
the bitcoin network has proven very popular among noderunners, so I decided
to continue developing it in order to meet this demand.

As I've discussed the spam issue with many, *many* people over the last
couple of years, I've noticed that those in the anti-filter camp often use
LR as a rhetorical device, effectively arguing "there's no way to stop
*this*". Well, Garbageman is an assertion to the contrary. I think the
battle should be fought, and that we should see how it plays out, because I
think we can win. For me, winning means keeping bitcoin both spam-resistant
and censorship-resistant.

Almost no one I've ever talked to likes the spam, even those in the
anti-filter camp. Likewise, almost no one I know who runs a node wants to
relay non-monetary transactions. But bitcoiners are feeling demoralized
after the BRC-20 attack of 2023-24, which expanded the utxoset from 5GB to
12GB [0], significantly raising the minimum cost of a bitcoin node, while
core maintainers refused to accept PRs that would have mitigated the spam.
So I hope that Garbageman can be a demonstration that all is not lost, and
that noderunners who wish to shoulder some responsibility can make a big
enough impact to deter spammers, if we all work together.

Peter's OP, while containing a lot of useful analysis, also contains some
inaccuracies I would like to correct.

While Peter characterizes Garbageman as an "attack" - and he is correct
that it is an attack on Libre Relay - what he leaves out is that Libre
Relay itself is an attack on bitcoin, and thus Garbageman is a defensive
measure from the point of view of the bitcoin network.

Specifically, Libre Relay facilitates denial-of-service attacks on bitcoin,
because it assists Ponzi promoters in launching their Ponzis using
metaprotocols directly on bitcoin, which, as we've seen with past waves of
spam, can easily overwhelm block space, sending fees sky-high for months on
end. This of course crowds out real monetary usages, such as merchants in
developing countries trying to start self-custodial Lightning
points-of-sale. It also tends to encourage utxoset bloat (even if the
arbitrary data itself is not stored in the utxoset, as we saw with BRC-20's
~tripling of utxoset data [0] using the inscriptions hack to stuff data
into the witness).

That is to say: Libre Relay intentionally increases the likelihood that
people will not be able to use bitcoin as money. Permissionless money is,
of course, the primary *service* that bitcoin offers, and its entire reason
for existence. So when Libre Relay facilitates the mining of transactions
associated with altcoin Ponzis on bitcoin, it is actively complicit in
perpetrating denial-of-*service* attacks against bitcoin.

LR operates by using the peer relay network in an unintended way. It
attempts to circumvent filters active on honest nodes by preferentially
peering with other LR nodes. Garbageman subverts this mechanism by
signaling on the same bit that LR nodes use to identify other LR nodes,
then throwing away any garbage that comes its way. Assuming that
noderunners who don't like spam vastly outnumber those who do (very likely
in my experience), it should be fairly straightforward to protect bitcoin
against LR's abuse by using up the preferential connections on LR nodes,
preventing them from finding each other.

"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.

Peter also claims that the Garbageman noderunner community's goal is to
"[prevent] people from getting transactions that they disagree with mined".
This is also false. In this claim, as filter opponents often do, Peter is
conflating spam filtration with censorship. They are, however, complete
opposite ends of a spectrum.

Censorship is the complete or near-complete prohibition of transactions for
subjective reasons, usually according to some kind of "blacklist" like
OFAC. Such behavior is obviously extremely harmful to bitcoin, as one of
its core properties is censorship resistance (aka permissionlessness).
Luckily, censorship on bitcoin is extremely unlikely, given that just one
block template creator with a small percentage of total hashrate can mine
whatever transactions it wants. As opponents of filtering love to point
out, the miner can even solicit such transactions out-of-band, avoiding
mempool filters entirely. They almost never realize that they are merely
bolstering the view that bitcoin is hard to *censor*, and not that it is
hard to *deter spam* on bitcoin.

Spam filtration, conversely, is a rate-limiting of transactions based on
objective criteria, which serves to deter, but not completely block, the
creation and confirmation of abusive transactions into the chain. Spam
filtration, in contrast to censorship, is harmless, and in fact absolutely
essential to bitcoin's survival. Why? Because *bitcoin's purpose as money
is impossible to codify into the consensus rules*. Even if we activated
some kind of hashing or signing scheme to prevent arbitrary data by
consensus (such as the one from Greg Maxwell that Peter brought up in an
earlier thread [1]), such a change would still not fully prohibit the abuse
of key grinding, etc, for storing arbitrary data (though it would increase
costs substantially).

What this means is that bitcoin's identity as money is only enforceable at
the social and mempool policy layers. So when core devs enumerate the
"three reasons" [2] mempool policy exists, they are missing reason 4:

*4) Making sure bitcoin stays money*

Spam filtration is thus a vital component to bitcoin's success, if its goal
is to be the best money ever.

Yes, consensus is king, but if we deny the importance of the social and
mempool policy layers in maintaining bitcoin's identity as money, then
bitcoin will inevitably cease to be money and become corrupted into
something resembling Ethereum; that is: a giant dumpster fire of
nobody-knows-what.

So when Libre Relay undermines spam filtration, it is not only facilitating
DoS attacks on bitcoin; it is contributing to a situation in which the DoS
becomes *permanent*, because bitcoin is no longer money at all.

A blockchain's technology is tightly intertwined with its culture. We've
seen historical examples of how tech influences culture, and vice versa.
Some examples:

- In BSV, the blocks are so huge and the transaction set so unwieldy, that
everyone thinks it's absurd for individuals to run nodes (because it is).
- In Ethereum:
- The blockchain is large and complex - so individuals generally think
running full nodes is unimportant - so very few people run full nodes - so
the devs are not concerned with making it easier for people to run full
nodes.
- The leadership has no principles and no particular vision for what the
blockchain is trying to achieve - so short-term incentives dominate.
- The contracting language is very challenging to secure - so making useful
contracts that actually work is deprioritized - so 99.99% of the activity
is dedicated to scamming.
- In Monero, the supply is difficult to audit - so everyone thinks that
auditing the supply is unimportant.

The list goes on and on. The point is that, if we still want bitcoin to be
money in a few years, we need to fight to make sure that monetary
transactions dominate, and that other use cases do not get the upper hand.
If making payments with bitcoin becomes too difficult, then the culture
will simply stop valuing payments.

We've already seen a concerning shift in this direction over the last
decade as the Lightning Network has been getting built out. During that
time, bitcoin=E2=80=99s culture has shifted such that statements from promi=
nent
figures unironically discourage spending bitcoin at merchants that directly
accept it. Getting Lightning to where it is today took 4 soft forks, a fork
war, and a decade of hard work from some of our best devs. Now that
Lightning works, we should go all-in on making sure merchants are adopting
it, instead of letting non-monetary use cases drown it out.

The anti-filter side seems to think that other use cases cannot drown out
the monetary use case, because of transaction fees. In order to believe
that fees are sufficient to make sure bitcoin stays money, you'd have to
assume that cloud storage with ironclad censorship resistance,
immutability, and availability guarantees, for any arbitrary data, for a
single upfront fee, *for the rest of eternity*, would have less demand than
Lightning channel opens and closes. This claim seems terribly dubious to
me, as it=E2=80=99s already been proven that Ponzi gamblers are willing to =
dump
millions of dollars into fees in order to store their garbage. And we
haven=E2=80=99t even cracked the surface of all possible non-monetary =E2=
=80=9Cuse cases=E2=80=9D,
because bitcoin=E2=80=99s maintainers have historically been hostile to the=
se uses,
so the vast majority of their would-be creators have simply not even
considered bitcoin an option.

Currently, however, core devs are very fond of "incentive compatibility"
(or "consensus maximalism"). As far as I understand it, this means making
mempool policy as close as possible to the consensus rules, so that miners
can maximize their short-term profits. While this is a good thing to design
for generally because it makes bitcoin much more predictable, it becomes
harmful when taken to its logical extreme. Since bitcoin's identity as
money cannot be enforced at the consensus layer, and since non-monetary use
cases have orders of magnitude more economic demand than monetary ones,
incentive compatibility, when maximized above all other concerns, means
stuffing bitcoin with as much meaningless garbage as possible. This implies
that incentive compatibility is ultimately incompatible with bitcoin
remaining money.

Sensible mempool filters are thus the single most powerful tool in our
arsenal for giving Lightning a fighting chance and making sure bitcoin
stays money for the long term. In addition to sending a strong social
signal as to what noderunners prefer, they also allow the relay network to
raise costs on spammers, while giving a free ride to actual payments, which
are the whole reason the relay network exists. They are the only way I know
of for bitcoin=E2=80=99s social layer to exert direct economic pressure on =
spammers.

Yes, there are most likely slight centralization pressures that can result
from large miners soliciting high-fee spam out-of-band, but if enough
noderunners are filtering abusive transactions, miners confirming large
amounts of these transactions can be seen as hostile, and hostile mining
pools have historically yielded to sufficient social pressure, because for
a mining pool, social pressure often translates, directly or indirectly, to
economic pressure.

If mining pools persist in mining blocks filled with garbage, that will be
a sign that we need to break up the mining pools (by encouraging their
hashers to boycott them), or, in extreme cases, to fire the miners by
changing the PoW algorithm. It would seem that sensible mining pool
operators would stop misbehaving well before this point, to avoid
undermining their (presumably large) investment.

Fortunately, if the community of noderunners comes together and decides on
sensible defaults, the mining pools have historically heeded its decisions.
Prior to mempoolfullrbf, it was rare to see mining pools flouting the will
of the noderunners. This is because the core maintainers always listened to
the noderunners when deciding on the default mempool policy. However, for
some reason, in the case of mempoolfullrbf, core devs decided to keep it
defaulted to =E2=80=9Coff=E2=80=9D, even though the vast majority of noderu=
nners felt that
it was a sensible thing to turn on. I worked at a company that provides
turnkey bitcoin nodes during that episode, and we even exposed
mempoolfullrbf as a config option because users wanted to be allowed to
turn it on.

Peter himself, using Libre Relay, was ultimately responsible for getting
this option defaulted to =E2=80=9Con=E2=80=9D 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. Practically everyone agreed that fullrbf was long
past due, except a handful of people who didn=E2=80=99t understand that zer=
oconf is
fundamentally insecure, and that Lightning is way better if you don=E2=80=
=99t want
to wait for a confirmation.

Peter should be commended for finally getting fullrbf active on mainnet.
But Libre Relay has now outlived its utility. LR has now been converted
into a tool for strong-arming core into removing all its filters, and
shoving garbage down everyone=E2=80=99s throats. Though noderunners were ha=
ppy to
go along with LR when it was just about getting fullrbf activated, we are
overwhelmingly opposed to raising datacarrier limits. Garbageman is the
manifestation of that opposition.

Garbageman protects the bitcoin network by facilitating spam filtration, an
essential function for bitcoin, while avoiding censorship. So Peter's
chosen subject line, "Censorship Resistant Transaction Relay", is
misleading. What he really means is "Spam-Filtration-Resistant Transaction
Relay" which, of course, is not desirable at all.

Yes, I=E2=80=99m sure there are strategies for getting LR nodes to detect G=
M 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 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.

Libre Relay is a direct threat to bitcoin=E2=80=99s ability to remain money=
, and
the threat must be countered.

Garbageman restores the balance.

Best regards,

--Chris Guida

[0]:
https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=3D1&=
refresh=3D10m&viewPanel=3D8&from=3D1588309200000&to=3Dnow
[1]: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ
[2]:
https://gist.github.com/instagibbs/c436110890ab25aa9997b13c2270d5ce#why-sta=
ndardness-policy-exists

On Tue, May 27, 2025 at 5:42=E2=80=AFAM John Carvalho <john@synonym.to> wro=
te:

> I noticed your mention of a missing pubkey identity capability.
>
> A censorship-resistant key-based discovery mechanism is available, PKDNS,
> at github.com/pubky/pkarr (also /mainline and /pkdns), which essentially
> provides public-key domains controlled by the keyholder.
>
> No blockchains, just the largest, oldest, p2p network on earth, Mainline
> DHT.
>
> This could be used to dynamically provide or update any endpoint,
> associate or disassociate keys, or create revokable account-based session=
s,
> etc.
>
> These links may address peoples' likely counterarguments:
> -
> https://medium.com/pubky/public-key-domains-censorship-resistance-explain=
ed-33d0333e6123
> - https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb
>
> Maybe this helps you, or others looking for such primitives!
>
> --
> John Carvalho
> CEO, Synonym.to <http://synonym.to/>
>
>
>
> On Tue, May 27, 2025 at 12:23=E2=80=AFPM Peter Todd <pete@petertodd.org> =
wrote:
>
>> Recently proponents of transaction "filtering" have started sybil
>> attacking
>> Libre Relay nodes by running nodes with their "garbageman" fork=C2=B9. T=
his
>> fork
>> falsely advertise the NODE_LIBRE_RELAY service bit, silently discards
>> transactions that would be relayed by real Libre Relay nodes, and does n=
ot
>> provide any. Additionally, they have made clear that they intend to ramp
>> up
>> this sybil attack with the aim of preventing people people from getting
>> transactions that they disagree with mined:
>>
>>         The costs will increase even more once Libre Relay=E2=80=99s DoS=
 attacks
>> on
>>         bitcoin are countered by enough defensive nodes.
>>         -Chris Guida
>> https://delvingbitcoin.org/t/addressing-community-concerns-and-objection=
s-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-o=
n-op-return-outputs/1697/4
>>
>> They have also put effort into making the attack more than a simple proo=
f
>> of
>> concept, e.g. by adding code that attempts to make it more difficult to
>> detect
>> attacking nodes, by keeping track of transactions received from peers,
>> and then
>> replying to inv messages with those transactions even when they were
>> discarded=C2=B2.
>>
>> With this attack in mind, I thought this would be a good opportunity to
>> review
>> the math on how effective this type of attack is, as well as some of the
>> mitigations that could be implement to defeat sybil attacks on transacti=
on
>> relaying. In particular, I'll present a defense to sybil attacks that is
>> sufficiently powerful that it may even negate the need for preferential
>> peering
>> techniques like the NODE_LIBRE_RELAY bit.
>>
>> Note that I don't deserve credit for any of these ideas. I'm just puttin=
g
>> down
>> in writing some ideas from Gregory Maxwell and others.
>>
>>
>> # The Effectiveness of Sybil Attacks on Transaction Relaying
>>
>> Non-listening nodes make a certain number of outgoing, transaction
>> relaying,
>> connections to listening nodes. In the case of Bitcoin Core, 8 outgoing
>> transaction relaying nodes; in the case of Libre Relay, an additional 4
>> outgoing connections to other Libre Relay nodes to relay transactions
>> relevant
>> to them.
>>
>> For a sybil attack to succeed against a non-listing node, every one of
>> the N
>> outgoing connections must be either a sybil attacking node, or a
>> listening node
>> that itself has been defeated by sybil attack. Additionally, Bitcoin Cor=
e
>> makes
>> outgoing IPv4 and IPv6 connections to a diversity of address space, so t=
he
>> sybil attacking nodes need to themselves be running on a diverse set of =
IP
>> addresses (this is not that difficult to achieve with VPS providers thes=
e
>> days). Thus if the sybil attacking nodes are a ratio of q to all nodes,
>> the
>> probability of the attack succeeding is q^N.
>>
>> Against Libre Relay, N=3D4, this means that the attacker needs to be
>> running ~84%
>> of all NODE_LIBRE_RELAY advertising nodes to have an attack success
>> probability
>> of ~50%. Based on information from my Bitcoin seed node, there appear to
>> be
>> about 15 Libre Relay nodes, so for a 50% attack success probability the
>> attackers would need to run about 85 attack nodes. If N was increased to
>> 8, the
>> attackers would need about 172 nodes to achieve the same success rate.
>>
>> Against *listening* nodes a different type of attack is necessary. The
>> reason
>> for this is that defenders can easily defeat sybil attacks against
>> listening
>> nodes by simply connecting to ~all listening nodes at once to ensure tha=
t
>> transaction propagation succeeds. Of course, the attacker can in turn do
>> things
>> like attempt to exhaust connection slots of Libre Relay nodes, or simply
>> DoS
>> attack them with packet floods. But those are different types of attack
>> than
>> the sybil attack we are discussing here.
>>
>>
>> # Prior Art: Defeating Block Propagation Sybil Attack
>>
>> Bitcoin Core already includes a defense against sybil attack for block
>> propagation: the feeler node system. Basically, every ~2 minutes an
>> outgoing
>> connection is made to a gossiped address to check if a connection can be
>> made;
>> successful connections are recorded in a table of "tried" addresses. If
>> no new
>> blocks have been received for 30 minutes, these tried addresses are then
>> used
>> every 10 minutes to try to find a peer that does know about a new block.
>>
>> Since this process goes on indefinitely, so long as outgoing connections
>> are
>> themselves not censored (e.g. by the ISP), the node should eventually
>> find a
>> non-sybil attacking node and learn about the true most-work chain. Even =
in
>> normal operation periods of >30minutes between blocks are fairly common,
>> so
>> this defense will (eventually) work even if a forked chain exists with
>> some
>> hash power extending it.
>>
>> This approach is relatively straightforward for block propagation, as
>> there is
>> a clear metric: the most-work chain. Peers that aren't giving you the
>> most-work
>> chain can be ignored, and new peers found.  Proof-of-work's inherently
>> self-validating property means that doing this is cheap and straight
>> forward.
>>
>>
>> # Directionality
>>
>> A subtlety to the information censorship sybil attack is there are
>> actually two
>> different simultaneous attacks: the attack on preventing you from learni=
ng
>> about new information, and the attack on preventing you from distribute
>> new
>> information to others.
>>
>> With block propagation, most nodes most directly care about the first
>> class of
>> attack: they want to learn about the most-work chain, and do not want th=
at
>> information censored from them.
>>
>> For miners, in addition to knowing what the most-work chain is, they
>> (typically=C2=B3) have a strong incentive to get their new blocks to all=
 nodes
>> as
>> quickly as possible. Also, all nodes have at least some incentive to do
>> this as
>> Bitcoin will not function properly if miners are getting censored.
>>
>> These attacks are not the same! The most-work-chain metric is only
>> directly
>> detecting and preventing the first class of attack. It only prevents the
>> second
>> attack indirectly, by making it easier for honest nodes to learn about n=
ew
>> blocks and attempt to themselves propagate that information further.
>>
>>
>> # Most Fees Metric
>>
>> For transaction relaying, the moral equivalent to the most-work chain
>> metric
>> are metrics based on the amount of new transaction fees that peers are
>> advertising to you. Unfortunately this isn't as straightforward to
>> implement as
>> the most-work chain metric for a few reasons:
>>
>> 1) Resolution: differences in chain work are very clear, with even a
>> single
>>    additional block being a very significant difference. For transaction
>> relaying,
>>    we'd like to be able to successfully relay transaction types that onl=
y
>> add a
>>    small % to total fees.
>> 2) Bandwidth: a chain of 80 byte headers is sufficient to prove most-wor=
k;
>>    transactions are much larger.
>> 3) Double-spends: mempools are not a consensus. Your peers may have
>>    transactions that conflict with your transactions, yet in ways that
>> don't
>>    constitute a worthwhile RBF replacement (e.g. two different
>> transactions
>>    with the same fees and fee-rate).
>>
>> For example, one straight-forward approach would be to simply keep track
>> of a
>> decaying average of new fees/sec each peer had advertised to you prior t=
o
>> you
>> advertising the transaction to them. Periodically, you could drop the
>> peer with
>> the lowest new fees/sec ranking, and then connect to a new peer.
>>
>> However, it's not clear that this approach has sufficient resolution to
>> actually detect censorship of relatively uncommon transaction types.
>> Additionally, since transaction broadcasting is a one-shot event - we
>> don't
>> have a mempool synchronization mechanism - this approach may not work
>> well if
>> transaction demand is bursty.
>>
>>
>> # Most-Fees Next (Dobule) Block Mempool
>>
>> With the upcoming cluster mempool functionality that is expected to be
>> added to
>> Core in the near future, transactions will be stored in memory in cluste=
rs
>> ordered by fees: essentially the order in which optimal blocks would be
>> created. This will make it computationally cheap to determine what the
>> optimal
>> next block (or blocks) will be by simply iterating through transactions =
in
>> order, and stopping when N weight worth of transactions have been found.
>>
>> Thus nodes can cheaply compute the total fees in the top one or two bloc=
ks
>> worth of transactions they currently have in their mempool, and advertis=
e
>> this
>> fact to their peers. Finally, to prevent lying, we can add a mechanism
>> for a
>> peer to get a copy of all these transactions to ensure that they're not
>> missing
>> out on anything paying enough fees to get mined soon.
>>
>> While beyond the scope of this summary, there are many set-reconciliatio=
n
>> techniques available to do this in a bandwidth efficient manner.
>> Basically,
>> through the existing transaction relay mechanisms we can expect mempools
>> to be
>> relatively consistent between nodes. Thus, to get all transactions that
>> your
>> peer has for the next block or two that you do not, you just need to
>> transfer
>> the deltas between their next-block(s) mempool and yours.
>>
>> Concretely, suppose we do this with the next two blocks worth of
>> transactions.
>> At worst, each node would need to periodically create a maximum 8MB
>> serialized
>> "double-block", using up to 8MB of ram. Secondly, to apply this to all
>> outgoing
>> connections, you'd need to periodically use a set-reconciliation protoco=
l
>> to
>> download the differences between each of your outgoing peers'
>> double-blocks,
>> and attempt to add any newly discovered transactions to your mempool. At
>> worst
>> for 8 peers this would be 64MB of useless data to download, assuming eve=
ry
>> single transaction was a conflicting double-spend. Not great. But not
>> that bad.
>>
>> As with the average fees idea, periodically you would drop the peer
>> advertising
>> the lowest double-block of fees, and then connect to a new peer to see i=
f
>> they're better.
>>
>> Now consider what happens if you are sybil attacked. Due to RBF, with
>> synchronous mempools across different nodes with the same standardness
>> policies
>> will have very similar transaction sets; even without active
>> synchronization
>> long-running mempools across different nodes are already very similar in
>> terms
>> of total fees. Thus even a small difference in transaction relay policy
>> will
>> show up as missing transactions. This difference will translate into the
>> sybil
>> attacking node(s) getting dropped, and honest nodes with policy
>> compatible with
>> yours eventually being found.
>>
>>
>> ## Peers With More Liberal Relay Policy
>>
>> If you apply set reconciliation to a peer with a *more* liberal relay
>> policy
>> than you, they'll have transactions that you will not accept. For exampl=
e,
>> imagine the case of a peer that now accepts a new version number.
>>
>> One way to deal with this could be to just drop peers that give you
>> transactions that you consider non-standard. So long as reconciliation i=
s
>> only
>> applied to a subset of all transaction relaying peers, this is fine.
>> Indeed,
>> even if this is applied to all transaction relaying peers, Bitcoin Core
>> already
>> connects to additional peers in blocks-only mode. So you'll still get
>> send and
>> receive blocks and maintain consensus.
>>
>>
>> ## Privacy
>>
>> Tracking what transactions are in mempools is a potential way for
>> attackers to
>> trace transactions back to their origin. Provided that set-reconciliatio=
n
>> is
>> only a secondary transaction relay mechanism, with sufficient time
>> delays, this
>> should not impact privacy as under normal operation transactions will ha=
ve
>> already propagated widely making the set reconciliation data
>> non-sensitive.
>>
>>
>> # Manual Peering With Known-Honest Friendly Nodes
>>
>> More of a social solution than a technical solution, we should encourage
>> people
>> to manually peer with other nodes they have a personal relationship
>> with.  This
>> is a powerful technique against sybil attacks for the simple reason that
>> person-to-person relationships can evaluate honesty in much more powerfu=
l
>> ways
>> than any code could possibly do so.
>>
>> At the moment, actually doing this is inconvenient. Ideally we would hav=
e
>> a
>> mechanism where node operators could get a simple pubkey@address
>> connection
>> string from their node to tell to their friends, and equally, import tha=
t
>> same
>> connection string into their bitcoin.conf. This mechanism should use som=
e
>> kind
>> of node identity to defeat MITM attacks, and also ensure that connection
>> limits
>> are bypassed for friendly nodes. The existing addnode mechanism doesn't
>> quite
>> achieve this. Notably, without a node identity mechanism, there's no way
>> for
>> someone with a static IP address to whitelist a friend's node with a
>> non-static
>> IP address.
>>
>>
>> # Footnotes
>>
>> 1) Chris Guida's "garbageman" branch:
>> https://github.com/chrisguida/bitcoin/tree/garbageman,
>>    first presented at the btc++ mempool edition (2025) hackathon
>> 2)
>> https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f=
2706848c48fd2?s=3D09
>> 3) https://petertodd.org/2016/block-publication-incentives-for-miners
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40petertod=
d.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/CAHTn92zkmfw2KwZCTRyGhnYPASW=
BUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPAS=
WBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter>
> .
>

--=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/=
CAAANnUwHcd1w6phwyfDKebzEabAtm%3DA3i2qkLDpJ9L47q75T9Q%40mail.gmail.com.

--0000000000004ada780636a200dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Good morning, list!<br><br>That seems like a good analysis=
, Peter, thanks for writing that up.<br><br>The following is an explanation=
 of why I decided to create Garbageman. Apologies for its length. I tried t=
o make it shorter, but I felt like I needed a lot of space to catch everyon=
e up to the pro-filtering (pro-rate-limiting) position, which I=E2=80=99ve =
not seen represented much on this list. Please reach out to me if you need =
something clarified or if I got anything wrong. I am constantly revising my=
 position based on new information, so please do not interpret it as carved=
 in stone.<br><br>Also, please let me know if this list is not the proper v=
enue for this discussion. It gets kind of philosophical.<br><br>For those w=
ho don&#39;t know, I made Garbageman as a hackathon project to demonstrate =
that the battle against spam is not hopeless.<br><br>The project&#39;s miss=
ion of stopping Libre Relay&#39;s spread of garbage around the bitcoin netw=
ork has proven very popular among noderunners, so I decided to continue dev=
eloping it in order to meet this demand.<br><br>As I&#39;ve discussed the s=
pam issue with many, <i>many</i> people over the last couple of years, I&#3=
9;ve noticed that those in the anti-filter camp often use LR as a rhetorica=
l device, effectively arguing &quot;there&#39;s no way to stop <i>this</i>&=
quot;. Well, Garbageman is an assertion to the contrary. I think the battle=
 should be fought, and that we should see how it plays out, because I think=
 we can win. For me, winning means keeping bitcoin both spam-resistant and =
censorship-resistant.<br><br>Almost no one I&#39;ve ever talked to likes th=
e spam, even those in the anti-filter camp. Likewise, almost no one I know =
who runs a node wants to relay non-monetary transactions. But bitcoiners ar=
e feeling demoralized after the BRC-20 attack of 2023-24, which expanded th=
e utxoset from 5GB to 12GB [0], significantly raising the minimum cost of a=
 bitcoin node, while core maintainers refused to accept PRs that would have=
 mitigated the spam. So I hope that Garbageman can be a demonstration that =
all is not lost, and that noderunners who wish to shoulder some responsibil=
ity can make a big enough impact to deter spammers, if we all work together=
.<br><br>Peter&#39;s OP, while containing a lot of useful analysis, also co=
ntains some inaccuracies I would like to correct.<br><br>While Peter charac=
terizes Garbageman as an &quot;attack&quot; - and he is correct that it is =
an attack on Libre Relay - what he leaves out is that Libre Relay itself is=
 an attack on bitcoin, and thus Garbageman is a defensive measure from the =
point of view of the bitcoin network.<br><br>Specifically, Libre Relay faci=
litates denial-of-service attacks on bitcoin, because it assists Ponzi prom=
oters in launching their Ponzis using metaprotocols directly on bitcoin, wh=
ich, as we&#39;ve seen with past waves of spam, can easily overwhelm block =
space, sending fees sky-high for months on end. This of course crowds out r=
eal monetary usages, such as merchants in developing countries trying to st=
art self-custodial Lightning points-of-sale. It also tends to encourage utx=
oset bloat (even if the arbitrary data itself is not stored in the utxoset,=
 as we saw with BRC-20&#39;s ~tripling of utxoset data [0] using the inscri=
ptions hack to stuff data into the witness).<br><br>That is to say: Libre R=
elay intentionally increases the likelihood that people will not be able to=
 use bitcoin as money. Permissionless money is, of course, the primary <i>s=
ervice</i> that bitcoin offers, and its entire reason for existence. So whe=
n Libre Relay facilitates the mining of transactions associated with altcoi=
n Ponzis on bitcoin, it is actively complicit in perpetrating denial-of-<i>=
service</i> attacks against bitcoin.<br><br>LR operates by using the peer r=
elay network in an unintended way. It attempts to circumvent filters active=
 on honest nodes by preferentially peering with other LR nodes. Garbageman =
subverts this mechanism by signaling on the same bit that LR nodes use to i=
dentify other LR nodes, then throwing away any garbage that comes its way. =
Assuming that noderunners who don&#39;t like spam vastly outnumber those wh=
o do (very likely in my experience), it should be fairly straightforward to=
 protect bitcoin against LR&#39;s abuse by using up the preferential connec=
tions on LR nodes, preventing them from finding each other.<br><br>&quot;NO=
DE_LIBRE_RELAY&quot; is not defined anywhere in bitcoin core or any other o=
fficial 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 Gar=
bageman &quot;falsely advertises the NODE_LIBRE_RELAY service bit&quot;, th=
is is incorrect. It is not possible for GM or any other software to misuse =
this bit, as it has no official significance.<br><br>Peter also claims that=
 the Garbageman noderunner community&#39;s goal is to &quot;[prevent] peopl=
e from getting transactions that they disagree with mined&quot;. This is al=
so false. In this claim, as filter opponents often do, Peter is conflating =
spam filtration with censorship. They are, however, complete opposite ends =
of a spectrum.<br><br>Censorship is the complete or near-complete prohibiti=
on of transactions for subjective reasons, usually according to some kind o=
f &quot;blacklist&quot; like OFAC. Such behavior is obviously extremely har=
mful to bitcoin, as one of its core properties is censorship resistance (ak=
a permissionlessness). Luckily, censorship on bitcoin is extremely unlikely=
, given that just one block template creator with a small percentage of tot=
al hashrate can mine whatever transactions it wants. As opponents of filter=
ing love to point out, the miner can even solicit such transactions out-of-=
band, avoiding mempool filters entirely. They almost never realize that the=
y are merely bolstering the view that bitcoin is hard to <i>censor</i>, and=
 not that it is hard to <i>deter spam</i> on bitcoin.<br><br>Spam filtratio=
n, conversely, is a rate-limiting of transactions based on objective criter=
ia, which serves to deter, but not completely block, the creation and confi=
rmation of abusive transactions into the chain. Spam filtration, in contras=
t to censorship, is harmless, and in fact absolutely essential to bitcoin&#=
39;s survival. Why? Because <b>bitcoin&#39;s purpose as money is impossible=
 to codify into the consensus rules</b>. Even if we activated some kind of =
hashing or signing scheme to prevent arbitrary data by consensus (such as t=
he one from Greg Maxwell that Peter brought up in an earlier thread [1]), s=
uch a change would still not fully prohibit the abuse of key grinding, etc,=
 for storing arbitrary data (though it would increase costs substantially).=
<br><br>What this means is that bitcoin&#39;s identity as money is only enf=
orceable at the social and mempool policy layers. So when core devs enumera=
te the &quot;three reasons&quot; [2] mempool policy exists, they are missin=
g reason 4:<br><br><b>4) Making sure bitcoin stays money</b><br><br><div>Sp=
am filtration is thus a vital component to bitcoin&#39;s success, if its go=
al is to be the best money ever.</div><div><br></div><div>Yes, consensus is=
 king, but if we deny the importance of the social and mempool policy layer=
s in maintaining bitcoin&#39;s identity as money, then bitcoin will inevita=
bly cease to be money and become corrupted into something resembling Ethere=
um; that is: a giant dumpster fire of nobody-knows-what.</div><div><br></di=
v><div><div>So when Libre Relay undermines spam filtration, it=20
is not only facilitating DoS attacks on bitcoin; it is contributing to a
 situation in which the DoS becomes <i>permanent</i>, because bitcoin is no=
 longer money at all.<br></div></div><br>A blockchain&#39;s technology is t=
ightly intertwined with its culture. We&#39;ve seen historical examples of =
how tech influences culture, and vice versa. Some examples:<br><br>- In BSV=
, the blocks are so huge and the transaction set so unwieldy, that everyone=
 thinks it&#39;s absurd for individuals to run nodes (because it is).<br>- =
In Ethereum:<br><div style=3D"margin-left:40px">- The blockchain is large a=
nd complex - so individuals generally think running full nodes is unimporta=
nt - so very few people run full nodes - so the devs are not concerned with=
 making it easier for people to run full nodes.<br>- The leadership has no =
principles and no particular vision for what the blockchain is trying to ac=
hieve - so short-term incentives dominate.<br>- The contracting language is=
 very challenging to secure - so making useful contracts that actually work=
 is deprioritized - so 99.99% of the activity is dedicated to scamming.<br>=
</div>- In Monero, the supply is difficult to audit - so everyone thinks th=
at auditing the supply is unimportant.<br><br>The list goes on and on. The =
point is that, if we still want bitcoin to be money in a few years, we need=
 to fight to make sure that monetary transactions dominate, and that other =
use cases do not get the upper hand. If making payments with bitcoin become=
s too difficult, then the culture will simply stop valuing payments.<br><br=
>We&#39;ve already seen a concerning shift in this direction over the last =
decade as the Lightning Network has been getting built out. During that tim=
e, bitcoin=E2=80=99s culture has shifted such that statements from prominen=
t figures unironically discourage spending bitcoin at merchants that direct=
ly accept it. Getting Lightning to where it is today took 4 soft forks, a f=
ork war, and a decade of hard work from some of our best devs. Now that Lig=
htning works, we should go all-in on making sure merchants are adopting it,=
 instead of letting non-monetary use cases drown it out.<br><br>The anti-fi=
lter side seems to think that other use cases cannot drown out the monetary=
 use case, because of transaction fees. In order to believe that fees are s=
ufficient to make sure bitcoin stays money, you&#39;d have to assume that c=
loud storage with ironclad censorship resistance, immutability, and availab=
ility guarantees, for any arbitrary data, for a single upfront fee, <i>for =
the rest of eternity</i>, would have less demand than Lightning channel ope=
ns and closes. This claim seems terribly dubious to me, as it=E2=80=99s alr=
eady been proven that Ponzi gamblers are willing to dump millions of dollar=
s into fees in order to store their garbage. And we haven=E2=80=99t even cr=
acked the surface of all possible non-monetary =E2=80=9Cuse cases=E2=80=9D,=
 because bitcoin=E2=80=99s maintainers have historically been hostile to th=
ese uses, so the vast majority of their would-be creators have simply not e=
ven considered bitcoin an option.<br><br>Currently, however, core devs are =
very fond of &quot;incentive compatibility&quot; (or &quot;consensus maxima=
lism&quot;). As far as I understand it, this means making mempool policy as=
 close as possible to the consensus rules, so that miners can maximize thei=
r short-term profits. While this is a good thing to design for generally be=
cause it makes bitcoin much more predictable, it becomes harmful when taken=
 to its logical extreme. Since bitcoin&#39;s identity as money cannot be en=
forced at the consensus layer, and since non-monetary use cases have orders=
 of magnitude more economic demand than monetary ones, incentive compatibil=
ity, when maximized above all other concerns, means stuffing bitcoin with a=
s much meaningless garbage as possible. This implies that incentive compati=
bility is ultimately incompatible with bitcoin remaining money.<br><br>Sens=
ible mempool filters are thus the single most powerful tool in our arsenal =
for giving Lightning a fighting chance and making sure bitcoin stays money =
for the long term. In addition to sending a strong social signal as to what=
 noderunners prefer, they also allow the relay network to raise costs on sp=
ammers, while giving a free ride to actual payments, which are the whole re=
ason the relay network exists. They are the only way I know of for bitcoin=
=E2=80=99s social layer to exert direct economic pressure on spammers.<br><=
br>Yes, there are most likely slight centralization pressures that can resu=
lt from large miners soliciting high-fee spam out-of-band, but if enough no=
derunners are filtering abusive transactions, miners confirming large amoun=
ts of these transactions can be seen as hostile, and hostile mining pools h=
ave historically yielded to sufficient social pressure, because for a minin=
g pool, social pressure often translates, directly or indirectly, to econom=
ic pressure.<br><br>If mining pools persist in mining blocks filled with ga=
rbage, that will be a sign that we need to break up the mining pools (by en=
couraging their hashers to boycott them), or, in extreme cases, to fire the=
 miners by changing the PoW algorithm. It would seem that sensible mining p=
ool operators would stop misbehaving well before this point, to avoid under=
mining their (presumably large) investment.<br><br>Fortunately, if the comm=
unity of noderunners comes together and decides on sensible defaults, the m=
ining pools have historically heeded its decisions. Prior to mempoolfullrbf=
, it was rare to see mining pools flouting the will of the noderunners. Thi=
s is because the core maintainers always listened to the noderunners when d=
eciding on the default mempool policy. However, for some reason, in the cas=
e of mempoolfullrbf, core devs decided to keep it defaulted to =E2=80=9Coff=
=E2=80=9D, even though the vast majority of noderunners felt that it was a =
sensible thing to turn on. I worked at a company that provides turnkey bitc=
oin nodes during that episode, and we even exposed mempoolfullrbf as a conf=
ig option because users wanted to be allowed to turn it on.<br><br>Peter hi=
mself, using Libre Relay, was ultimately responsible for getting this optio=
n defaulted to =E2=80=9Con=E2=80=9D 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. Practically everyone agreed that fullrbf was long pa=
st due, except a handful of people who didn=E2=80=99t understand that zeroc=
onf is fundamentally insecure, and that Lightning is way better if you don=
=E2=80=99t want to wait for a confirmation.<br><br>Peter should be commende=
d for finally getting fullrbf active on mainnet. But Libre Relay has now ou=
tlived its utility. LR has now been converted into a tool for strong-arming=
 core into removing all its filters, and shoving garbage down everyone=E2=
=80=99s throats. Though noderunners were happy to go along with LR when it =
was just about getting fullrbf activated, we are overwhelmingly opposed to =
raising datacarrier limits. Garbageman is the manifestation of that opposit=
ion.<br><br>Garbageman protects the bitcoin network by facilitating spam fi=
ltration, an essential function for bitcoin, while avoiding censorship. So =
Peter&#39;s chosen subject line, &quot;Censorship Resistant Transaction Rel=
ay&quot;, is misleading. What he really means is &quot;Spam-Filtration-Resi=
stant Transaction Relay&quot; which, of course, is not desirable at all.<br=
><br>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 implem=
ented:<br><br>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=99=
t know of any noderunners in their right minds who would run them.<br>2) Th=
e pro-spam-filtration noderunner community will work around these detection=
 methods any way we can, and we will never give up.<br><br>Libre Relay is a=
 direct threat to bitcoin=E2=80=99s ability to remain money, and the threat=
 must be countered. <br><br>Garbageman restores the balance.<br><br>Best re=
gards,<br><br>--Chris Guida<br><br>[0]: <a href=3D"https://statoshi.info/d/=
000000009/unspent-transaction-output-set?orgId=3D1&amp;refresh=3D10m&amp;vi=
ewPanel=3D8&amp;from=3D1588309200000&amp;to=3Dnow">https://statoshi.info/d/=
000000009/unspent-transaction-output-set?orgId=3D1&amp;refresh=3D10m&amp;vi=
ewPanel=3D8&amp;from=3D1588309200000&amp;to=3Dnow</a><br>[1]: <a href=3D"ht=
tps://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ">https://=
groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ</a><br>[2]: <a =
href=3D"https://gist.github.com/instagibbs/c436110890ab25aa9997b13c2270d5ce=
#why-standardness-policy-exists">https://gist.github.com/instagibbs/c436110=
890ab25aa9997b13c2270d5ce#why-standardness-policy-exists</a><br></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May=
 27, 2025 at 5:42=E2=80=AFAM John Carvalho &lt;<a href=3D"mailto:john@synon=
ym.to" target=3D"_blank">john@synonym.to</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I noticed you=
r mention of a missing pubkey identity capability.=C2=A0</div><div><br></di=
v><div>A censorship-resistant key-based discovery mechanism is available, P=
KDNS, at <a href=3D"http://github.com/pubky/pkarr" target=3D"_blank">github=
.com/pubky/pkarr</a> (also /mainline and /pkdns), which essentially provide=
s public-key domains controlled by the keyholder.=C2=A0</div><div><br></div=
><div>No blockchains, just the largest, oldest, p2p network on earth, Mainl=
ine DHT.</div><div><br></div><div>This could be used to dynamically provide=
 or update any endpoint, associate or disassociate keys, or create revokabl=
e account-based sessions, etc.</div><div><br></div><div>These links may add=
ress peoples&#39; likely counterarguments:</div><div>-=C2=A0<a href=3D"http=
s://medium.com/pubky/public-key-domains-censorship-resistance-explained-33d=
0333e6123" target=3D"_blank">https://medium.com/pubky/public-key-domains-ce=
nsorship-resistance-explained-33d0333e6123</a></div><div>-=C2=A0<a href=3D"=
https://medium.com/pubky/mainline-dht-censorship-explained-b62763db39cb" ta=
rget=3D"_blank">https://medium.com/pubky/mainline-dht-censorship-explained-=
b62763db39cb</a></div><div><br></div><div>Maybe this helps you, or others l=
ooking for such primitives!</div><div>=C2=A0</div><div><div dir=3D"ltr" cla=
ss=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(34,34,34)"=
>--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" style=3D"color=
:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D"ltr">CEO,=
=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204)" target=
=3D"_blank">Synonym.to</a><br><div><font size=3D"1"><br></font></div><div><=
/div></div></div></div></div></div><br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 27, 2025 at 12:23=E2=80=
=AFPM Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank=
">pete@petertodd.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">Recently proponents of transaction &quot;filtering&quot=
; have started sybil attacking<br>
Libre Relay nodes by running nodes with their &quot;garbageman&quot; fork=
=C2=B9. This fork<br>
falsely advertise the NODE_LIBRE_RELAY service bit, silently discards<br>
transactions that would be relayed by real Libre Relay nodes, and does not<=
br>
provide any. Additionally, they have made clear that they intend to ramp up=
<br>
this sybil attack with the aim of preventing people people from getting<br>
transactions that they disagree with mined:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The costs will increase even more once Libre Re=
lay=E2=80=99s DoS attacks on<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin are countered by enough defensive nodes=
.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -Chris Guida <a href=3D"https://delvingbitcoin.=
org/t/addressing-community-concerns-and-objections-regarding-my-recent-prop=
osal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4=
" rel=3D"noreferrer" target=3D"_blank">https://delvingbitcoin.org/t/address=
ing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax=
-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/4</a><br>
<br>
They have also put effort into making the attack more than a simple proof o=
f<br>
concept, e.g. by adding code that attempts to make it more difficult to det=
ect<br>
attacking nodes, by keeping track of transactions received from peers, and =
then<br>
replying to inv messages with those transactions even when they were<br>
discarded=C2=B2.<br>
<br>
With this attack in mind, I thought this would be a good opportunity to rev=
iew<br>
the math on how effective this type of attack is, as well as some of the<br=
>
mitigations that could be implement to defeat sybil attacks on transaction<=
br>
relaying. In particular, I&#39;ll present a defense to sybil attacks that i=
s<br>
sufficiently powerful that it may even negate the need for preferential pee=
ring<br>
techniques like the NODE_LIBRE_RELAY bit. <br>
<br>
Note that I don&#39;t deserve credit for any of these ideas. I&#39;m just p=
utting down<br>
in writing some ideas from Gregory Maxwell and others.<br>
<br>
<br>
# The Effectiveness of Sybil Attacks on Transaction Relaying <br>
<br>
Non-listening nodes make a certain number of outgoing, transaction relaying=
,<br>
connections to listening nodes. In the case of Bitcoin Core, 8 outgoing<br>
transaction relaying nodes; in the case of Libre Relay, an additional 4<br>
outgoing connections to other Libre Relay nodes to relay transactions relev=
ant<br>
to them.<br>
<br>
For a sybil attack to succeed against a non-listing node, every one of the =
N<br>
outgoing connections must be either a sybil attacking node, or a listening =
node<br>
that itself has been defeated by sybil attack. Additionally, Bitcoin Core m=
akes<br>
outgoing IPv4 and IPv6 connections to a diversity of address space, so the<=
br>
sybil attacking nodes need to themselves be running on a diverse set of IP<=
br>
addresses (this is not that difficult to achieve with VPS providers these<b=
r>
days). Thus if the sybil attacking nodes are a ratio of q to all nodes, the=
<br>
probability of the attack succeeding is q^N.<br>
<br>
Against Libre Relay, N=3D4, this means that the attacker needs to be runnin=
g ~84%<br>
of all NODE_LIBRE_RELAY advertising nodes to have an attack success probabi=
lity<br>
of ~50%. Based on information from my Bitcoin seed node, there appear to be=
<br>
about 15 Libre Relay nodes, so for a 50% attack success probability the<br>
attackers would need to run about 85 attack nodes. If N was increased to 8,=
 the<br>
attackers would need about 172 nodes to achieve the same success rate.<br>
<br>
Against *listening* nodes a different type of attack is necessary. The reas=
on<br>
for this is that defenders can easily defeat sybil attacks against listenin=
g<br>
nodes by simply connecting to ~all listening nodes at once to ensure that<b=
r>
transaction propagation succeeds. Of course, the attacker can in turn do th=
ings<br>
like attempt to exhaust connection slots of Libre Relay nodes, or simply Do=
S<br>
attack them with packet floods. But those are different types of attack tha=
n<br>
the sybil attack we are discussing here.<br>
<br>
<br>
# Prior Art: Defeating Block Propagation Sybil Attack<br>
<br>
Bitcoin Core already includes a defense against sybil attack for block<br>
propagation: the feeler node system. Basically, every ~2 minutes an outgoin=
g<br>
connection is made to a gossiped address to check if a connection can be ma=
de;<br>
successful connections are recorded in a table of &quot;tried&quot; address=
es. If no new<br>
blocks have been received for 30 minutes, these tried addresses are then us=
ed<br>
every 10 minutes to try to find a peer that does know about a new block. <b=
r>
<br>
Since this process goes on indefinitely, so long as outgoing connections ar=
e<br>
themselves not censored (e.g. by the ISP), the node should eventually find =
a<br>
non-sybil attacking node and learn about the true most-work chain. Even in<=
br>
normal operation periods of &gt;30minutes between blocks are fairly common,=
 so<br>
this defense will (eventually) work even if a forked chain exists with some=
<br>
hash power extending it.<br>
<br>
This approach is relatively straightforward for block propagation, as there=
 is<br>
a clear metric: the most-work chain. Peers that aren&#39;t giving you the m=
ost-work<br>
chain can be ignored, and new peers found.=C2=A0 Proof-of-work&#39;s inhere=
ntly<br>
self-validating property means that doing this is cheap and straight forwar=
d.<br>
<br>
<br>
# Directionality<br>
<br>
A subtlety to the information censorship sybil attack is there are actually=
 two<br>
different simultaneous attacks: the attack on preventing you from learning<=
br>
about new information, and the attack on preventing you from distribute new=
<br>
information to others.<br>
<br>
With block propagation, most nodes most directly care about the first class=
 of<br>
attack: they want to learn about the most-work chain, and do not want that<=
br>
information censored from them.<br>
<br>
For miners, in addition to knowing what the most-work chain is, they<br>
(typically=C2=B3) have a strong incentive to get their new blocks to all no=
des as<br>
quickly as possible. Also, all nodes have at least some incentive to do thi=
s as<br>
Bitcoin will not function properly if miners are getting censored.<br>
<br>
These attacks are not the same! The most-work-chain metric is only directly=
<br>
detecting and preventing the first class of attack. It only prevents the se=
cond<br>
attack indirectly, by making it easier for honest nodes to learn about new<=
br>
blocks and attempt to themselves propagate that information further.<br>
<br>
<br>
# Most Fees Metric<br>
<br>
For transaction relaying, the moral equivalent to the most-work chain metri=
c<br>
are metrics based on the amount of new transaction fees that peers are<br>
advertising to you. Unfortunately this isn&#39;t as straightforward to impl=
ement as<br>
the most-work chain metric for a few reasons:<br>
<br>
1) Resolution: differences in chain work are very clear, with even a single=
<br>
=C2=A0 =C2=A0additional block being a very significant difference. For tran=
saction relaying,<br>
=C2=A0 =C2=A0we&#39;d like to be able to successfully relay transaction typ=
es that only add a<br>
=C2=A0 =C2=A0small % to total fees.<br>
2) Bandwidth: a chain of 80 byte headers is sufficient to prove most-work;<=
br>
=C2=A0 =C2=A0transactions are much larger.<br>
3) Double-spends: mempools are not a consensus. Your peers may have<br>
=C2=A0 =C2=A0transactions that conflict with your transactions, yet in ways=
 that don&#39;t<br>
=C2=A0 =C2=A0constitute a worthwhile RBF replacement (e.g. two different tr=
ansactions<br>
=C2=A0 =C2=A0with the same fees and fee-rate).<br>
<br>
For example, one straight-forward approach would be to simply keep track of=
 a<br>
decaying average of new fees/sec each peer had advertised to you prior to y=
ou<br>
advertising the transaction to them. Periodically, you could drop the peer =
with<br>
the lowest new fees/sec ranking, and then connect to a new peer.<br>
<br>
However, it&#39;s not clear that this approach has sufficient resolution to=
<br>
actually detect censorship of relatively uncommon transaction types.<br>
Additionally, since transaction broadcasting is a one-shot event - we don&#=
39;t<br>
have a mempool synchronization mechanism - this approach may not work well =
if<br>
transaction demand is bursty.<br>
<br>
<br>
# Most-Fees Next (Dobule) Block Mempool<br>
<br>
With the upcoming cluster mempool functionality that is expected to be adde=
d to<br>
Core in the near future, transactions will be stored in memory in clusters<=
br>
ordered by fees: essentially the order in which optimal blocks would be<br>
created. This will make it computationally cheap to determine what the opti=
mal<br>
next block (or blocks) will be by simply iterating through transactions in<=
br>
order, and stopping when N weight worth of transactions have been found.<br=
>
<br>
Thus nodes can cheaply compute the total fees in the top one or two blocks<=
br>
worth of transactions they currently have in their mempool, and advertise t=
his<br>
fact to their peers. Finally, to prevent lying, we can add a mechanism for =
a<br>
peer to get a copy of all these transactions to ensure that they&#39;re not=
 missing<br>
out on anything paying enough fees to get mined soon.<br>
<br>
While beyond the scope of this summary, there are many set-reconciliation<b=
r>
techniques available to do this in a bandwidth efficient manner. Basically,=
<br>
through the existing transaction relay mechanisms we can expect mempools to=
 be<br>
relatively consistent between nodes. Thus, to get all transactions that you=
r<br>
peer has for the next block or two that you do not, you just need to transf=
er<br>
the deltas between their next-block(s) mempool and yours.<br>
<br>
Concretely, suppose we do this with the next two blocks worth of transactio=
ns.<br>
At worst, each node would need to periodically create a maximum 8MB seriali=
zed<br>
&quot;double-block&quot;, using up to 8MB of ram. Secondly, to apply this t=
o all outgoing<br>
connections, you&#39;d need to periodically use a set-reconciliation protoc=
ol to<br>
download the differences between each of your outgoing peers&#39; double-bl=
ocks,<br>
and attempt to add any newly discovered transactions to your mempool. At wo=
rst<br>
for 8 peers this would be 64MB of useless data to download, assuming every<=
br>
single transaction was a conflicting double-spend. Not great. But not that =
bad.<br>
<br>
As with the average fees idea, periodically you would drop the peer adverti=
sing<br>
the lowest double-block of fees, and then connect to a new peer to see if<b=
r>
they&#39;re better.<br>
<br>
Now consider what happens if you are sybil attacked. Due to RBF, with<br>
synchronous mempools across different nodes with the same standardness poli=
cies<br>
will have very similar transaction sets; even without active synchronizatio=
n<br>
long-running mempools across different nodes are already very similar in te=
rms<br>
of total fees. Thus even a small difference in transaction relay policy wil=
l<br>
show up as missing transactions. This difference will translate into the sy=
bil<br>
attacking node(s) getting dropped, and honest nodes with policy compatible =
with<br>
yours eventually being found.<br>
<br>
<br>
## Peers With More Liberal Relay Policy<br>
<br>
If you apply set reconciliation to a peer with a *more* liberal relay polic=
y<br>
than you, they&#39;ll have transactions that you will not accept. For examp=
le,<br>
imagine the case of a peer that now accepts a new version number.<br>
<br>
One way to deal with this could be to just drop peers that give you<br>
transactions that you consider non-standard. So long as reconciliation is o=
nly<br>
applied to a subset of all transaction relaying peers, this is fine. Indeed=
,<br>
even if this is applied to all transaction relaying peers, Bitcoin Core alr=
eady<br>
connects to additional peers in blocks-only mode. So you&#39;ll still get s=
end and<br>
receive blocks and maintain consensus.<br>
<br>
<br>
## Privacy<br>
<br>
Tracking what transactions are in mempools is a potential way for attackers=
 to<br>
trace transactions back to their origin. Provided that set-reconciliation i=
s<br>
only a secondary transaction relay mechanism, with sufficient time delays, =
this<br>
should not impact privacy as under normal operation transactions will have<=
br>
already propagated widely making the set reconciliation data non-sensitive.=
<br>
<br>
<br>
# Manual Peering With Known-Honest Friendly Nodes<br>
<br>
More of a social solution than a technical solution, we should encourage pe=
ople<br>
to manually peer with other nodes they have a personal relationship with.=
=C2=A0 This<br>
is a powerful technique against sybil attacks for the simple reason that<br=
>
person-to-person relationships can evaluate honesty in much more powerful w=
ays<br>
than any code could possibly do so.<br>
<br>
At the moment, actually doing this is inconvenient. Ideally we would have a=
<br>
mechanism where node operators could get a simple pubkey@address connection=
<br>
string from their node to tell to their friends, and equally, import that s=
ame<br>
connection string into their bitcoin.conf. This mechanism should use some k=
ind<br>
of node identity to defeat MITM attacks, and also ensure that connection li=
mits<br>
are bypassed for friendly nodes. The existing addnode mechanism doesn&#39;t=
 quite<br>
achieve this. Notably, without a node identity mechanism, there&#39;s no wa=
y for<br>
someone with a static IP address to whitelist a friend&#39;s node with a no=
n-static<br>
IP address.<br>
<br>
<br>
# Footnotes<br>
<br>
1) Chris Guida&#39;s &quot;garbageman&quot; branch: <a href=3D"https://gith=
ub.com/chrisguida/bitcoin/tree/garbageman" rel=3D"noreferrer" target=3D"_bl=
ank">https://github.com/chrisguida/bitcoin/tree/garbageman</a>,<br>
=C2=A0 =C2=A0first presented at the btc++ mempool edition (2025) hackathon<=
br>
2) <a href=3D"https://github.com/chrisguida/bitcoin/commit/e9a921c045d64828=
a5f0de58d8f2706848c48fd2?s=3D09" rel=3D"noreferrer" target=3D"_blank">https=
://github.com/chrisguida/bitcoin/commit/e9a921c045d64828a5f0de58d8f2706848c=
48fd2?s=3D09</a><br>
3) <a href=3D"https://petertodd.org/2016/block-publication-incentives-for-m=
iners" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2016/bloc=
k-publication-incentives-for-miners</a><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>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/aDWfDI03I-Rakopb%40petertodd.org" rel=3D"noreferrer" target=3D"_=
blank">https://groups.google.com/d/msgid/bitcoindev/aDWfDI03I-Rakopb%40pete=
rtodd.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" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw%40mail.gmail=
.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://=
groups.google.com/d/msgid/bitcoindev/CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65A=
SYpPeBUpX1SWw%40mail.gmail.com</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/CAAANnUwHcd1w6phwyfDKebzEabAtm%3DA3i2qkLDpJ9L47q75T9Q%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAANnUwHcd1w6phwyfDKebzEabAtm%3DA3i2qkLDpJ9L47q75T9Q%40ma=
il.gmail.com</a>.<br />

--0000000000004ada780636a200dd--