From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 ; 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: <4BA2B86E-3E4B-416B-9237-AFD66FC4E37A@sprovoost.nl> In-Reply-To: From: Chris Guida Date: Wed, 4 Jun 2025 14:00:19 -0600 X-Gm-Features: AX0GCFu7QjAhVTU0EKO2doY2no9fdw3l4B34SKLJGb9cKHbVftuOfQG8MtCfad8 Message-ID: Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out the garbage(man) To: Greg Maxwell Cc: Sjors Provoost , 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 w= rote: > On Tue, Jun 3, 2025 at 8:00=E2=80=AFAM Sjors Provoost 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 > > . > --=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
Hey Greg -

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

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's m= onetary function so expensive and inconvenient that bitcoin simply ceases t= o be money. Avoiding the latter catastrophe does not involve "censorsh= ip" at all. It involves rate-limiting spam.

&= 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.

Can you el= aborate on why you see this as a threat? Again, I don'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?

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

Again, can you elaborate o= n 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 cen= sorship infrastructure" 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 censorship. You are = using that term incorrectly.

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

How does t= his 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 thi= s could realistically be enforced.

>Could they = still get their transactions through?=C2=A0 Probably but at much greater co= sts and delays, creating a significant harm.

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 = censorship, if that's what's occurring. I completely agree w= ith 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 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.

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's place currently, and I think it is a terrible idea not 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's monetary function is just as deadly= to bitcoin as censorship would be.

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

I agree that b= uilding a "censorship infrastructure" 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.

>A world that, sure, s= ometimes has higher transaction fees due to waves=20 of well funded spam--- but that'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.

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've created economic demand where previously the= re was very little.

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

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

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's point of view= , because bitcoin is money, and this simply reflects that it is work= ing properly. There are no threats to bitcoin's culture if such a thing= happens. Everyone simply goes on thinking that bitcoin is money, and peopl= e who can'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 non-monetary activity, then this undermines bitcoin's e= ntire identity and purpose as money and corrupts its culture into no lo= nger 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&= #39;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 ab= ility to transact "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."=C2=A0 If someone cares that someone else is = using=20 bitcoin for things they don'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.

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 th= an Ethereum. So there are two 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.

>That= 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'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.

I don= 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

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

Kind regards,<= /div>

--Chris

On Tue, Jun= 3, 2025 at 12:29=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> wrote:
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, y= ou didn't rate limit anything and you made mining more centralised.

That'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.

=
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).

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.

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 'good' purposes) and instead building anti-censorship infrastruc= ture 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 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'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.
=
Prior to Bitcoin your ability to trans= act "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."=C2=A0 If someone cares that someone else is = using bitcoin for things they don'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.

That'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'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.
=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit http= s://groups.google.com/d/msgid/bitcoindev/CAAS2fgT3gyra4BNN1zDVz%3Dn%3DtmteZ= LC4xuzTWSm_s0T6Rw2MJA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/CAAANnUzBbzHcL_dajefUi5T57qvUeexPijAUBGVxywvRuosF4w%40mail.g= mail.com.
--000000000000c6774d0636c47ada--