path: root/59/841cdefa853820c7fac18f0bc10588a7a7e3fe

Delivery-date: Mon, 09 Jun 2025 03:54:53 -0700
Received: from mail-qv1-f63.google.com ([209.85.219.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+bncBDSKF7WH24FRB4P2TLBAMGQEMRH36XQ@googlegroups.com>)
	id 1uOa9T-0005QY-47
	for bitcoindev@gnusha.org; Mon, 09 Jun 2025 03:54:53 -0700
Received: by mail-qv1-f63.google.com with SMTP id 6a1803df08f44-6facf4cf5e1sf69205286d6.2
        for <bitcoindev@gnusha.org>; Mon, 09 Jun 2025 03:54:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1749466485; cv=pass;
        d=google.com; s=arc-20240605;
        b=DpPbhL4X1pPNQOt8xXB4IxQ4DVUTyLFE4O8haPYoZg8o+TT9AuzsEbI7dWq0qlh6WI
         +5nz7aw/+z1D37xHIvhjlsTXf4RFksYJgiNn+fi47xFNCMGHZ/ArosFbqhnRVpN6O3cj
         zvehQpjxyQU9ycxM+kbEZi+b8Gd691xav9Tk8ybBheAq0MslaEo3AmdnHyLE+2D7Xbal
         3Gp+2oSzWDKFX/7WVKAdjIy/i48MNU4/d/Rz5mHS4jXWleFoSWmwa5V4F8ITVw3zI5JU
         9oTZ78RxTeZRuRzPiWJD6SS/mBAIhV0gy4J3Z7uzpmij/Z1u6kCYgjE9EW3mYKwdJe71
         eaSA==
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=5vXZbm8Gxuf/6vcUOD51hvznaXEPilihofYLjPh8qaY=;
        fh=BAP333cZdu+BiZCtt4szAdk7z+PJTXy/lTkPxnPBl50=;
        b=YNLRMhMcBlwD09pA1GjudQDM5ZuisO1pzR3l1aMb1oQ/xeoB7j2FDK0V2kpSYFmG8U
         XIrqqHKfDcdtVbUjhKsaxKRL9UE+QMCOaLNsS014UKaDhtMwTvITW5IoOrcDvI9TKUR/
         3ZEuU2HeF/BY9lAsVFBps/j3MF+JEht/sc0FfEj6Zuq1NuObJOHotBrFY7sH6dLgQwy2
         NXQTn1KuIWmH42jaALyfp10qIJnYpSc+b/+tqgMREFendJ0keBD9oamp53g4/G5r1v0T
         EPRl3RaMm7+Fo3JYK1hxTbMJDdXVOWkmj4Vn7gsP1nFIqFdLkE0nQ8X5HaBIg1cv+hrB
         f1Jw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=E+BFFMT7;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 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=1749466485; x=1750071285; 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=5vXZbm8Gxuf/6vcUOD51hvznaXEPilihofYLjPh8qaY=;
        b=mhHpgr3msV4QwoILt9X/vb6mdri4UqxtoDCRMMjOqRqp8u6LJy5vCGTxfHlSgnmQbf
         q2pTjv0As0loQImyKr62BuRl2CIJpcJQV1mYP92fs8RKYUNyG5wNJyf8t6uHRZuv66+B
         qhQ9IvHmjfz/RWYWT5pXea8TKGN2HWaH62iAMxVmpyQx2P3maZnZxy32QPEAVklG3nXz
         MNn33KuUQ7kCMG+sFObVT5ZSgQHqNZUruOFri4B/NSFTwlyEm70gs4sAklaejmxvfMY0
         WYzh/qi6OlobBr2VkJjyCPLTydKcwx7bArXHUgoGZafl1b/+AYvBQFM+594gtXIJY3gs
         Dr6w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749466485; x=1750071285; 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=5vXZbm8Gxuf/6vcUOD51hvznaXEPilihofYLjPh8qaY=;
        b=i/frQpH8vpAp91SclMKx/Ea1IydKZ6LOn7Eq6iOokMDp1ORiv3sdtMQrKn95WNXg+M
         jeXKxzEtBT6sLG7FfVmGZHjHD4re5GOH1orkEWQPAR4mwEnqWxKsmwz3jQCkaK5ByxND
         zgk8lf7pS2JQZTeVjIU4NU2ZGkIbvJA0TG4b2GB62eB+p8uA7RQtmTIa26as9tel6hLH
         I/rPz0BYO6D7TyXjLhcWd1RSvqPXTVEpH/ykvUlc75L/m14KoTobogAebRLhwyVVRyKe
         02HXEEICWTWcKtMeGLRC/53Bf4GWgebzODv+xqJTwNcXRBHQUWIeRv+ZBFVQKBwYXZQk
         rECg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749466485; x=1750071285;
        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=5vXZbm8Gxuf/6vcUOD51hvznaXEPilihofYLjPh8qaY=;
        b=IHjlCQOdGVVp93EQJxNqZaHRvbCLRfWlKqFwiwxi0H4vKqTT5Lt48IJpk6E/OEhDHy
         NYj5NbVs8WnL1nailNf/JzolAw12tDnClWD7+G6eupCgIS59phY9dbVdPX4KU39/d/De
         MtVUpQG537RML6hFhZ1ftF3D0t/Xz9stPHnAo3RBm1WtorYsg3wPwbUkxBEryrlGdg3l
         S8ucECYx34p01/Fa7LoX32gyl4dG5zhwIKGuIXaEIFcIUBZOK3pTSCK0Xa81zl1FYia6
         oDlF/zgm5YOYQ2XF/sXXJr9DxfrZwXOuRQ3Lbd7waqpng1GJjYKjVxJKRQjTJjg12yCw
         38IA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVdQNfg7oV3khSHYeIwFNvA7WeQBTYRW/tBUUunJkNyVhYxzbgPoS+fW519VyoF37SPWF1B6b6zPCpO@gnusha.org
X-Gm-Message-State: AOJu0YzXKNz96cP/KiXuA8FVOQNtmHzxHntmLdnFdI8CpT4nZtuyvqZW
	UrTh9MiacIMmswr7C8Re2v+w7t3irQCUx1FqM7x7oEROY9U+0eKJn74s
X-Google-Smtp-Source: AGHT+IFJmKBr5z6fj9sghJgDWB8+nB6VqPXRLeFRDrH5LMdZDijEmSxntEmxihSO2wA+DGvs4twdXw==
X-Received: by 2002:ad4:536b:0:b0:6fb:f19:66f2 with SMTP id 6a1803df08f44-6fb0f196705mr119339816d6.8.1749466484911;
        Mon, 09 Jun 2025 03:54:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZc90fFw62ME37bqjuURuZo1GJOEaqQOheZ9arsNFOK5BA==
Received: by 2002:ad4:5b86:0:b0:6fa:bd34:be98 with SMTP id 6a1803df08f44-6faff967419ls56110946d6.0.-pod-prod-09-us;
 Mon, 09 Jun 2025 03:54:41 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCVT8Dhv67QNWNW7gAYArBWtPsdDFuXSko2WONIJ4orsr41mJtdy7gdgMKon/wvOmEwSFjBJx/9m0lwz@googlegroups.com
X-Received: by 2002:a05:620a:3949:b0:7ca:c9cb:ac1 with SMTP id af79cd13be357-7d229846661mr1976840685a.4.1749466481624;
        Mon, 09 Jun 2025 03:54:41 -0700 (PDT)
Received: by 2002:a05:620a:830f:b0:7c5:495f:5415 with SMTP id af79cd13be357-7d218f3a1c2ms85a;
        Wed, 4 Jun 2025 13:02:43 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCWgoywS/hzkdhtqNiSExCMRutUBx66Btzlh1uwV/QZBoJqqHwh8X1c7AhLGTyBKHKkrDuoG+45Gdy5Z@googlegroups.com
X-Received: by 2002:ad4:59c5:0:b0:6fa:cb58:10b7 with SMTP id 6a1803df08f44-6faf70184a5mr43080366d6.26.1749067362291;
        Wed, 04 Jun 2025 13:02:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1749067362; cv=none;
        d=google.com; s=arc-20240605;
        b=C3UnUeMltYm3ai7ouTAuZ9SJjOz5lgafbSyx73wjTuhQcnxc6OmhnAOjMsM5EbBu5r
         Fj8oY/PGaH+j+g8oh5FceUA9BbIoOYsOJn6aQxQuhtPZfsIyMSpxfFuilxZF68YaC0qz
         nEK7HLyelY4EQmjCMJ2cfuqtaxlmPWXIUn5K44983ahZUtN9fey7xNiZrlwZDbE5AWcL
         DFHeKF7K8ESWq5YQY7nsBprYewnw9oCAI43Bx8vp9GpDJ3412IKwr8hZVy4m/2SkI3ek
         AQzVcw1BtFr+OVtdmz1fzYYnRi9QdyeoRpTC11jIJtXmvpg3jcZQog6Ez0fAk/amaQmU
         Nvgg==
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=dcID3IK9EF+oLpf5VCTHOL/G33oFQaNplf5ioGdLi4Q=;
        fh=p2cJyoOUhWyeKWrbbKsa5r2arQ4YkUFZJ30awMOy50A=;
        b=Tz6E+c//zq3WugNBCkjwvSjfdIKQzsMKUJcxf8YNNePW3tkJH2d3OQA3nMfvMO3zvc
         8XM1KdnUq/9hV+M06mnnjwEawEl6kGutNaXX29+6BeEOEbJDTu2Kh8Ti3GLZLQ7wYeb1
         Tz64shNtxc5ti3x/PIg7hqZsAtC02sATJt9B5VQVAKgP7wEnKgblmudswUWXgz7J/PYs
         qZlU92/rerrrVL2P6zPBdbZuGIQHZRP+GSVGvJMdJOgCE4v1ePHamWk0OAVV9ElE3I8y
         8d3g/WOIn9ZaarYBgxyhJSKQfw4PPhNKPb9Yt09BuNlEsVoUxaMKes44s2wPPVdNI9lE
         nJHg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=E+BFFMT7;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 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-xf36.google.com (mail-qv1-xf36.google.com. [2607:f8b0:4864:20::f36])
        by gmr-mx.google.com with ESMTPS id 6a1803df08f44-6fac6cf7379si5887006d6.0.2025.06.04.13.02.42
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 04 Jun 2025 13:02:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) client-ip=2607:f8b0:4864:20::f36;
Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6facba680a1so3147726d6.3
        for <bitcoindev@googlegroups.com>; Wed, 04 Jun 2025 13:02:42 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVYYcuta3WzzHlTllvrh2o0N84ugfwh4FPOVY0k7mFOM8o/SAreOaVWX8ainRQO2pjhtae3Yxt7KCL5@googlegroups.com
X-Gm-Gg: ASbGncufATYR2pljDhv7VzRqoYxH9L9KI/O2H9BMEDykA0+BRgPYD9/jtypY722nG5d
	bVRW1YR1oYgHnB61XFw0cp2kIVbx2aadKslpcMscKR+Mgphoa/gTmukVKtJQcJw6UjIkbIOZUNA
	dCN2SWczTRYV8/CJUIjPF/Hcd46efWIFwv
X-Received: by 2002:a05:6214:501e:b0:6fa:d975:6572 with SMTP id
 6a1803df08f44-6faf6f93123mr55813726d6.1.1749067361579; Wed, 04 Jun 2025
 13:02:41 -0700 (PDT)
MIME-Version: 1.0
References: <aDWfDI03I-Rakopb@petertodd.org> <CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw@mail.gmail.com>
 <CAAANnUwHcd1w6phwyfDKebzEabAtm=A3i2qkLDpJ9L47q75T9Q@mail.gmail.com>
 <4BA2B86E-3E4B-416B-9237-AFD66FC4E37A@sprovoost.nl> <CAAS2fgT3gyra4BNN1zDVz=n=tmteZLC4xuzTWSm_s0T6Rw2MJA@mail.gmail.com>
In-Reply-To: <CAAS2fgT3gyra4BNN1zDVz=n=tmteZLC4xuzTWSm_s0T6Rw2MJA@mail.gmail.com>
From: Chris Guida <chrisguida@gmail.com>
Date: Wed, 4 Jun 2025 14:00:19 -0600
X-Gm-Features: AX0GCFu7QjAhVTU0EKO2doY2no9fdw3l4B34SKLJGb9cKHbVftuOfQG8MtCfad8
Message-ID: <CAAANnUzBbzHcL_dajefUi5T57qvUeexPijAUBGVxywvRuosF4w@mail.gmail.com>
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out
 the garbage(man)
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Sjors Provoost <sjors@sprovoost.nl>, bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000c6774d0636c47ada"
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=E+BFFMT7;       spf=pass
 (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36
 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 (/)

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

Hey Greg -

I certainly share your concerns about governments censoring bitcoin. We
should absolutely make sure we don't put bitcoin in a position where
governments might start to get ideas.

However, as I tried to argue in my response to Peter, I think being too
permissive with relay policy can be just as harmful as being too
restrictive. We must guide bitcoin through the Scylla of government
censorship and the Charybdis of making bitcoin's monetary function so
expensive and inconvenient that bitcoin simply ceases to be money. Avoiding
the latter catastrophe does not involve "censorship" at all. It involves
rate-limiting spam.

>But when the censorship is backed by threat (even if vague or
unconstitutional) of civil or criminal legal penalties, the avenue to just
bypass may be much less available.

Can you elaborate on why you see this as a threat? Again, I don't see how
governments - even colluding worldwide - can compel 100% of the hashrate
not to mine transactions. The recent movement towards home mining seems to
make this outcome increasingly unlikely. But perhaps I am missing something=
?

>So for example, in an alternative universe: Bitcoin goes along with Guida
and after having built this massive edifice of transaction censorship the
Bitcoin developers lose their UK lawsuit Craig S Wright after he
successfully bribes a judge, and now have a the UK courts imposing a
worldwide order to freeze any of their bitcoin address under threat of
imprisonment.

Again, can you elaborate on how this attack would work? I don't understand
how the UK government, or anyone, could compel a large enough percentage of
hashpower not to mine transactions from certain actors for it to matter. If
bitcoin cannot stand up to tyrannical governments that try to impose unjust
(and in this case, impossible-to-enforce) demands, then what are we even
doing here?

>The censorship is deployed via the prebuilt censorship infrastructure

What is this "prebuilt censorship infrastructure" you refer to? Garbageman
is just a bitcoin node. No one is compelled to run it. It only makes a
difference if a large percentage of the bitcoin network is running it, and
this can only happen voluntarily. And again, it is impossible to use for
*censorship*. You are using that term incorrectly.

>and willingness to bypass it is greatly decreased because doing so would
land the bypasser a UK arrest warrant.

How does this even work? Are you saying that any noderunner who **doesn't**
run Garbageman could be compelled to do so? I'm just not seeing how this
could realistically be enforced.

>Could they still get their transactions through?  Probably but at much
greater costs and delays, creating a significant harm.

Can you go into more detail as to the harm caused? As Sjors pointed out,
people can just resubmit their transactions again and again if they fail to
be accepted the first time. And people can run LR nodes to get around
government *censorship*, if that's what's occurring. I completely agree
with the notion that LR could come in handy again if anyone *actually* ever
tries to censor bitcoin. In the case of a government attempting to
blacklist certain addresses, for example, it is very likely that LR would
see a surge in popularity and GM would not be as effective.

The noderunner network is decentralized. We need to trust that noderunners
will make the right choices and will run more GM nodes when spam is the
most pressing issue, and will run more LR nodes when censorship is top of
mind. I think each tool has its place. I just think we are nowhere near
LR's place currently, and I think it is a terrible idea *not* to build its
conservative counterpart, because then we will have no recourse once the
spam begins in earnest. And make no mistake, governments can attack bitcoin
via spam just as well as they can attack it via censorship. The loss of a
culture that values bitcoin's monetary function is just as deadly to
bitcoin as censorship would be.

>Not building the censorship infrastructure (even though you intend it for
'good' purposes) and instead building anti-censorship infrastructure leaves
us all with a better world.

I agree that building a "censorship infrastructure" would be a terrible
idea. That is not what Garbageman is. And again, I am fine with the
existence of LR, as there are (very unlikely) situations in which it could
come in useful. I just think at the moment we need fewer LR nodes, not
more. Censorship of bitcoin is exceedingly unlikely, whereas spam is the
much more pressing threat at the moment.

>A world that, sure, sometimes has higher transaction fees due to waves of
well funded spam--- but that's just the cost of having limited capacity on
the network to preserve the ability to validate and to provide income for
security.

I disagree. We have successfully deterred spammers for almost a decade
between 2014 and 2023. If we treat them with the hostility they deserve,
then the economic demand for their activity drops precipitously. There is
hard historical data supporting this view. Conversely, if we throw open the
floodgates and welcome all the spammers in, now we've created economic
demand where previously there was very little.

>Even if there was never any spam at all there would sometimes be elevated
transaction fees due to surges in demand.  Essentially the energy behind
this anti-spam stuff is just relitigating the blocksize war, but doing it
under the cover(?) of undermining a foundational property of Bitcoin: that
bitcoin was created to escape other people passing judgement over which
existing transactions are okay or not.

This is inaccurate. I am not interested in relitigating the blocksize war.
I understand that block space needs to be limited to keep validation costs
low and the node network decentralized. I know this better than most, as
I've spent a large portion of the last few years setting up new users with
bitcoin nodes. In fact, this very property has been undermined by the spam
attack that happened during 2023-2024, where the minimum cost of hardware
sufficient to fully validate the chain in under a month went from $100 to
$250.

I am making a more nuanced point: If low-fee monetary activity is drowned
out by high-fee monetary activity, this is acceptable from the bitcoin
network's point of view, because *bitcoin is money*, and this simply
reflects that it is working properly. There are no threats to bitcoin's
culture if such a thing happens. Everyone simply goes on thinking that
bitcoin is money, and people who can't afford to pay high fees just wait
till the fees come back down. If, on the other hand, low-fee monetary
activity is drowned out by high-fee *non-monetary* activity, then this*
undermines bitcoin's entire identity and purpose as money* and corrupts its
culture into no longer believing that bitcoin is money at all, resulting in
a downward spiral ending in bitcoin's death by fading away into
irrelevance, just as we've seen with Ethereum.

>The Bitcoin project has never seen that to be its role.

I certainly hope the bitcoin project sees making sure bitcoin functions as
money as its role!

>Prior to Bitcoin your ability to transact "could always be overridden by
the admin based on his judgment call weighing the principle [...] against
other concerns, or at the behest of his superiors."  If someone cares that
someone else is using bitcoin for things they don't like, or that being
outbid can delay their transactions-- then they ought to be using something
else.  This was settled long ago.

I completely agree that bitcoin is not interesting if it is not
permissionless *money*. If it is to be merely a permissionless *database*,
then it is no more interesting than Ethereum. So there are *two* ways in
which bitcoin can fail to be permissionless money and thus lose relevance:
too much censorship on the one hand, and too much spam on the other.

>That's the problem with all this filtering stuff:  It works better, to the
extent it works at all, against sincere usage which lacks the flexibility
of spam (or outright attacks).  Sincere usage cares that the network
validates its rules, it has to spend specific coins, specific values, use
specific fields.   Collateral usage (a term that I think better captures
most of what people are calling spam)-- where the goal of the transaction
isn't really to move Bitcoins-- can do virtually *anything* with its
transactions, it is far more flexible and so it is less vulnerable to
attempts to filter it.

I don't agree with this view. As long as we detect Ponzi metaprotocols as
soon as they are announced, we can counter them without affecting sincere
usage. There are even proposals for modular filtering, where the bitcoin
node software would not even need a new release in order to counter a new
threat; filter developers could simply write new filters as the threats
evolve, and the node software could import it dynamically. In all
likelihood, once we implement this, the spammers will simply give up and
spam other chains instead.

There are certainly risks to implementing something like this, as it could
be co-opted to nefarious ends if we are not vigilant. However, as I stated
earlier, I think the noderunner network is sufficiently decentralized, and
noderunners themselves are smart enough about what software they run, that
the risk should be manageable. As long as there is no single point of
failure, I don't see much reason to be concerned. Again, everyone chooses
the software they run, and no one can be compelled to run something they
disagree with. I think we should trust noderunners to make the right
decisions.

Kind regards,

--Chris

On Tue, Jun 3, 2025 at 12:29=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> w=
rote:

> On Tue, Jun 3, 2025 at 8:00=E2=80=AFAM Sjors Provoost <sjors@sprovoost.nl=
> wrote:
>
>> Then all you've achieved is an incentive to submit directly to miners,
>> making those miners more profitable. Congrats, you didn't fix spam, you
>> didn't rate limit anything and you made mining more centralised.
>>
>
> That's not all it does: it also created infrastructure for impeding other
> kinds of transactions which may be much more time sensitive than the spam
> transactions and may be much less able to use direct submission.
>
> No one is going to (convincingly) argue that including a monkey jpeg in a
> transaction is _unlawful_ and so for commercial miners there is always
> going to be a price where they will include them-- and that price is lowe=
r
> once excessive filtering pays for the creation of submission mechanisms (=
as
> it already has done).
>
> But when the censorship is backed by threat (even if vague or
> unconstitutional) of civil or criminal legal penalties, the avenue to jus=
t
> bypass may be much less available.
>
> So for example, in an alternative universe: Bitcoin goes along with Guida
> and after having built this massive edifice of transaction censorship the
> Bitcoin developers lose their UK lawsuit Craig S Wright after he
> successfully bribes a judge, and now have a the UK courts imposing a
> worldwide order to freeze any of their bitcoin address under threat of
> imprisonment.  The censorship is deployed via the prebuilt censorship
> infrastructure, and willingness to bypass it is greatly decreased because
> doing so would land the bypasser a UK arrest warrant. Could they still ge=
t
> their transactions through?  Probably but at much greater costs and delay=
s,
> creating a significant harm.  Not building the censorship infrastructure
> (even though you intend it for 'good' purposes) and instead building
> anti-censorship infrastructure leaves us all with a better world.
>
> A world that, sure, sometimes has higher transaction fees due to waves of
> well funded spam--- but that's just the cost of having limited capacity o=
n
> the network to preserve the ability to validate and to provide income for
> security.  It's not a cost of spam itself:  Even if there was never any
> spam at all there would sometimes be elevated transaction fees due to
> surges in demand.  Essentially the energy behind this anti-spam stuff is
> just relitigating the blocksize war, but doing it under the cover(?) of
> undermining a foundational property of Bitcoin: that bitcoin was created =
to
> escape other people passing judgement over which existing transactions ar=
e
> okay or not.  The Bitcoin project has never seen that to be its role.
>
> Prior to Bitcoin your ability to transact "could always be overridden by
> the admin based on his judgment call weighing the principle [...] against
> other concerns, or at the behest of his superiors."  If someone cares tha=
t
> someone else is using bitcoin for things they don't like, or that being
> outbid can delay their transactions-- then they ought to be using somethi=
ng
> else.  This was settled long ago.
>
> That's the problem with all this filtering stuff:  It works better, to th=
e
> extent it works at all, against sincere usage which lacks the flexibility
> of spam (or outright attacks).  Sincere usage cares that the network
> validates its rules, it has to spend specific coins, specific values, use
> specific fields.   Collateral usage (a term that I think better captures
> most of what people are calling spam)-- where the goal of the transaction
> isn't really to move Bitcoins-- can do virtually *anything* with its
> transactions, it is far more flexible and so it is less vulnerable to
> attempts to filter it.
>
>
> --
> 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/CAAS2fgT3gyra4BNN1zDVz%3Dn%3=
DtmteZLC4xuzTWSm_s0T6Rw2MJA%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgT3gyra4BNN1zDVz%3Dn%=
3DtmteZLC4xuzTWSm_s0T6Rw2MJA%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter>
> .
>

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

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

<div dir=3D"ltr"><div>Hey Greg -</div><div><br></div><div>I certainly share=
 your concerns about governments censoring bitcoin. We should absolutely ma=
ke sure we don&#39;t put bitcoin in a position where governments might star=
t to get ideas.</div><div><br></div><div>However, as I tried to argue in my=
 response to Peter, I think being too permissive with relay policy can be j=
ust as harmful as being too restrictive. We must guide bitcoin through the =
Scylla of government censorship and the Charybdis of making bitcoin&#39;s m=
onetary function so expensive and inconvenient that bitcoin simply ceases t=
o be money. Avoiding the latter catastrophe does not involve &quot;censorsh=
ip&quot; at all. It involves rate-limiting spam.</div><div><br></div><div>&=
gt;But when the censorship is backed by threat (even if vague or=20
unconstitutional) of civil or criminal legal penalties, the avenue to=20
just bypass may be much less available.</div><div><br></div><div>Can you el=
aborate on why you see this as a threat? Again, I don&#39;t see how governm=
ents - even colluding worldwide - can compel 100% of the hashrate not to mi=
ne transactions. The recent movement towards home mining seems to make this=
 outcome increasingly unlikely. But perhaps I am missing something?</div><d=
iv><br></div><div>&gt;So for example, in an alternative universe: Bitcoin g=
oes along with=20
Guida and after having built this massive edifice of transaction=20
censorship the Bitcoin developers lose their UK lawsuit Craig S Wright=20
after he successfully bribes a judge, and now have a the UK courts=20
imposing a worldwide order to freeze any of their bitcoin address under=20
threat of imprisonment.</div><div><br></div><div>Again, can you elaborate o=
n how this attack would work? I don&#39;t understand how the UK government,=
 or anyone, could compel a large enough percentage of hashpower not to mine=
 transactions from certain actors for it to matter. If bitcoin cannot stand=
 up to tyrannical governments that try to impose unjust (and in this case, =
impossible-to-enforce) demands, then what are we even doing here?</div><div=
><br></div><div>&gt;The censorship is deployed via the prebuilt censorship =
infrastructure<br></div><div><br></div><div>What is this &quot;prebuilt cen=
sorship infrastructure&quot; you refer to? Garbageman is just a bitcoin nod=
e. No one is compelled to run it. It only makes a difference if a large per=
centage of the bitcoin network is running it, and this can only happen volu=
ntarily. And again, it is impossible to use for <i>censorship</i>. You are =
using that term incorrectly.</div><div><br></div><div>&gt;and willingness t=
o bypass it is greatly decreased because doing so would
 land the bypasser a UK arrest warrant.</div><div><br></div><div>How does t=
his even work? Are you saying that any noderunner who <i>*doesn&#39;t*</i> =
run Garbageman could be compelled to do so? I&#39;m just not seeing how thi=
s could realistically be enforced.</div><div><br></div><div>&gt;Could they =
still get their transactions through?=C2=A0 Probably but at much greater co=
sts and delays, creating a significant harm.</div><div><br></div><div>Can y=
ou go into more detail as to the harm caused? As Sjors pointed out, people =
can just resubmit their transactions again and again if they fail to be acc=
epted the first time. And people can run LR nodes to get around government =
<i>censorship</i>, if that&#39;s what&#39;s occurring. I completely agree w=
ith the notion that LR could come in handy again if anyone <i>actually</i> =
ever tries to censor bitcoin. In the case of a government attempting to bla=
cklist certain addresses, for example, it is very likely that LR would see =
a surge in popularity and GM would not be as effective.</div><div><br></div=
><div>The noderunner network is decentralized. We need to trust that noderu=
nners will make the right choices and will run more GM nodes when spam is t=
he most pressing issue, and will run more LR nodes when censorship is top o=
f mind. I think each tool has its place. I just think we are nowhere near L=
R&#39;s place currently, and I think it is a terrible idea <i>not</i> to bu=
ild its conservative counterpart, because then we will have no recourse onc=
e the spam begins in earnest. And make no mistake, governments can attack b=
itcoin via spam just as well as they can attack it via censorship. The loss=
 of a culture that values bitcoin&#39;s monetary function is just as deadly=
 to bitcoin as censorship would be.<br></div><div><br></div><div>&gt;Not bu=
ilding the censorship infrastructure (even though you intend it=20
for &#39;good&#39; purposes) and instead building anti-censorship infrastru=
cture
 leaves us all with a better world.</div><div><br></div><div>I agree that b=
uilding a &quot;censorship infrastructure&quot; would be a terrible idea. T=
hat is not what Garbageman is. And again, I am fine with the existence of L=
R, as there are (very unlikely) situations in which it could come in useful=
. I just think at the moment we need fewer LR nodes, not more. Censorship o=
f bitcoin is exceedingly unlikely, whereas spam is the much more pressing t=
hreat at the moment.<br></div><div><br></div><div>&gt;A world that, sure, s=
ometimes has higher transaction fees due to waves=20
of well funded spam--- but that&#39;s just the cost of having limited=20
capacity on the network to preserve the ability to validate and to=20
provide income for security.</div><div><br></div><div>I disagree. We have s=
uccessfully deterred spammers for almost a decade between 2014 and 2023. If=
 we treat them with the hostility they deserve, then the economic demand fo=
r their activity drops precipitously. There is hard historical data support=
ing this view. Conversely, if we throw open the floodgates and welcome all =
the spammers in, now we&#39;ve created economic demand where previously the=
re was very little.</div><div><br></div><div>&gt;Even if there was never an=
y spam at all there would sometimes be=20
elevated transaction fees due to surges in demand.=C2=A0 Essentially the=20
energy behind this anti-spam stuff is just relitigating the blocksize=20
war, but doing it under the cover(?) of undermining a foundational=20
property of Bitcoin: that bitcoin was created to escape other people=20
passing judgement over which existing transactions are okay or not.<br></di=
v><div><br></div><div>This is inaccurate. I am not interested in relitigati=
ng the blocksize war. I understand that block space needs to be limited to =
keep validation costs low and the node network decentralized. I know this b=
etter than most, as I&#39;ve spent a large portion of the last few years se=
tting up new users with bitcoin nodes. In fact, this very property has been=
 undermined by the spam attack that happened during 2023-2024, where the mi=
nimum cost of hardware sufficient to fully validate the chain in under a mo=
nth went from $100 to $250.</div><div><br></div><div>I am making a more nua=
nced point: If low-fee monetary activity is drowned out by high-fee monetar=
y activity, this is acceptable from the bitcoin network&#39;s point of view=
, because <i>bitcoin is money</i>, and this simply reflects that it is work=
ing properly. There are no threats to bitcoin&#39;s culture if such a thing=
 happens. Everyone simply goes on thinking that bitcoin is money, and peopl=
e who can&#39;t afford to pay high fees just wait till the fees come back d=
own. If, on the other hand, low-fee monetary activity is drowned out by hig=
h-fee <i>non-monetary</i> activity, then this<i> undermines bitcoin&#39;s e=
ntire identity and purpose as money</i> and corrupts its culture into no lo=
nger believing that bitcoin is money at all, resulting in a downward spiral=
 ending in bitcoin&#39;s death by fading away into irrelevance, just as we&=
#39;ve seen with Ethereum.</div><div><br></div><div>&gt;The
 Bitcoin project has never seen that to be its role.</div><div><br></div><d=
iv>I certainly hope the bitcoin project sees making sure bitcoin functions =
as money as its role!</div><div><br></div><div>&gt;Prior to Bitcoin your ab=
ility to transact &quot;could always be overridden by
 the admin based on his judgment call=20
weighing the principle [...] against other concerns, or at the=20
behest of his superiors.&quot;=C2=A0 If someone cares that someone else is =
using=20
bitcoin for things they don&#39;t like, or that being outbid can delay thei=
r
 transactions-- then they ought to be using something else.=C2=A0 This was=
=20
settled long ago.</div><div><br></div><div>I completely agree that bitcoin =
is not interesting if it is not permissionless <i>money</i>. If it is to be=
 merely a permissionless <i>database</i>, then it is no more interesting th=
an Ethereum. So there are <i>two</i> ways in which bitcoin can fail to be p=
ermissionless money and thus lose relevance: too much censorship on the one=
 hand, and too much spam on the other.</div><div><br></div><div>&gt;That&#3=
9;s the problem with all this filtering stuff:=C2=A0 It works better, to=20
the extent it works at all, against sincere usage which lacks the=20
flexibility of spam (or outright attacks).=C2=A0 Sincere usage cares that t=
he
 network validates its rules, it has to spend specific coins, specific=20
values, use specific fields.=C2=A0=C2=A0 Collateral usage (a term that I th=
ink=20
better captures most of what people are calling spam)-- where the goal=20
of the transaction isn&#39;t really to move Bitcoins-- can do virtually=20
*anything* with its transactions, it is far more flexible and so it is=20
less vulnerable to attempts to filter it.</div><div><br></div><div>I don&#3=
9;t agree with this view. As long as we detect Ponzi metaprotocols as soon =
as they are announced, we can counter them without affecting sincere usage.=
 There are even proposals for modular filtering, where the bitcoin node sof=
tware would not even need a new release in order to counter a new threat; f=
ilter developers could simply write new filters as the threats evolve, and =
the node software could import it dynamically. In all likelihood, once we i=
mplement this, the spammers will simply give up and spam other chains inste=
ad.=C2=A0</div><div><br></div><div>There are certainly risks to implementin=
g something like this, as it could be co-opted to nefarious ends if we are =
not vigilant. However, as I stated earlier, I think the noderunner network =
is sufficiently decentralized, and noderunners themselves are smart enough =
about what software they run, that the risk should be manageable. As long a=
s there is no single point of failure, I don&#39;t see much reason to be co=
ncerned. Again, everyone chooses the software they run, and no one can be c=
ompelled to run something they disagree with. I think we should trust noder=
unners to make the right decisions.</div><div><br></div><div>Kind regards,<=
/div><div><br></div><div>--Chris<br></div></div><br><div class=3D"gmail_quo=
te gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun=
 3, 2025 at 12:29=E2=80=AFPM Greg Maxwell &lt;<a href=3D"mailto:gmaxwell@gm=
ail.com">gmaxwell@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jun 3,=
 2025 at 8:00=E2=80=AFAM Sjors Provoost &lt;<a href=3D"mailto:sjors@sprovoo=
st.nl" target=3D"_blank">sjors@sprovoost.nl</a>&gt; wrote:</div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><di=
v>Then all you&#39;ve achieved is an incentive to submit directly to miners=
, making those miners more profitable. Congrats, you didn&#39;t fix spam, y=
ou didn&#39;t rate limit anything and you made mining more centralised.</di=
v></div></blockquote><div><br></div><div>That&#39;s not all it does: it als=
o created infrastructure for impeding other kinds of transactions which may=
 be much more time sensitive than the spam transactions and may be much les=
s able to use direct submission.</div></div><div class=3D"gmail_quote"><br>=
</div><div class=3D"gmail_quote">No one is going to (convincingly) argue th=
at including a monkey jpeg in a transaction is _unlawful_ and so for commer=
cial miners there is always going to be a price where they will include the=
m-- and that price is lower once excessive filtering pays for the creation =
of submission mechanisms (as it already has done).</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">But when the censorship is bac=
ked by threat (even if vague or unconstitutional) of civil or criminal lega=
l penalties, the avenue to just bypass may be much less available.</div><di=
v class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">So for example=
, in an alternative universe: Bitcoin goes along with Guida and after havin=
g built this massive edifice of transaction censorship the Bitcoin develope=
rs lose their UK lawsuit Craig S Wright after he successfully bribes a judg=
e, and now have a the UK courts imposing a worldwide order to freeze any of=
 their bitcoin address under threat of imprisonment.=C2=A0 The censorship i=
s deployed via the prebuilt censorship infrastructure, and willingness to b=
ypass it is greatly decreased because doing so would land the bypasser a UK=
 arrest warrant. Could they still get their transactions through?=C2=A0 Pro=
bably but at much greater costs and delays, creating a significant harm.=C2=
=A0 Not building the censorship infrastructure (even though you intend it f=
or &#39;good&#39; purposes) and instead building anti-censorship infrastruc=
ture leaves us all with a better world.</div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote">A world that, sure, sometimes has higher =
transaction fees due to waves of well funded spam--- but that&#39;s just th=
e cost of having limited capacity on the network to preserve the ability to=
 validate and to provide income for security.=C2=A0 It&#39;s not a cost of =
spam itself:=C2=A0 Even if there was never any spam at all there would some=
times be elevated transaction fees due to surges in demand.=C2=A0 Essential=
ly the energy behind this anti-spam stuff is just relitigating the blocksiz=
e war, but doing it under the cover(?) of undermining a foundational proper=
ty of Bitcoin: that bitcoin was created to escape other people passing judg=
ement over which existing transactions are okay or not.=C2=A0 The Bitcoin p=
roject has never seen that to be its role.</div><div class=3D"gmail_quote">=
<br></div><div class=3D"gmail_quote">Prior to Bitcoin your ability to trans=
act &quot;could always be overridden by the admin based on his judgment cal=
l=20
weighing the principle [...] against other concerns, or at the=20
behest of his superiors.&quot;=C2=A0 If someone cares that someone else is =
using bitcoin for things they don&#39;t like, or that being outbid can dela=
y their transactions-- then they ought to be using something else.=C2=A0 Th=
is was settled long ago.</div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">That&#39;s the problem with all this filtering stuff:=C2=
=A0 It works better, to the extent it works at all, against sincere usage w=
hich lacks the flexibility of spam (or outright attacks).=C2=A0 Sincere usa=
ge cares that the network validates its rules, it has to spend specific coi=
ns, specific values, use specific fields.=C2=A0=C2=A0 Collateral usage (a t=
erm that I think better captures most of what people are calling spam)-- wh=
ere the goal of the transaction isn&#39;t really to move Bitcoins-- can do =
virtually *anything* with its transactions, it is far more flexible and so =
it is less vulnerable to attempts to filter it.</div><div class=3D"gmail_qu=
ote">=C2=A0</div></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/CAAS2fgT3gyra4BNN1zDVz%3Dn%3DtmteZLC4xuzTWSm_s0T6Rw2MJA%40mail.g=
mail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">http=
s://groups.google.com/d/msgid/bitcoindev/CAAS2fgT3gyra4BNN1zDVz%3Dn%3DtmteZ=
LC4xuzTWSm_s0T6Rw2MJA%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/CAAANnUzBbzHcL_dajefUi5T57qvUeexPijAUBGVxywvRuosF4w%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAAANnUzBbzHcL_dajefUi5T57qvUeexPijAUBGVxywvRuosF4w%40mail.g=
mail.com</a>.<br />

--000000000000c6774d0636c47ada--