path: root/ef/b7c32e017ba7363f4a16bb780fc95a00d1dd92

Delivery-date: Sat, 27 Sep 2025 10:30:45 -0700
Received: from mail-oi1-f191.google.com ([209.85.167.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDOYBLGOTUDRBOV64DDAMGQEH24FG7Y@googlegroups.com>)
	id 1v2Yku-00029j-Ok
	for bitcoindev@gnusha.org; Sat, 27 Sep 2025 10:30:45 -0700
Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-435de7f86aesf2989928b6e.2
        for <bitcoindev@gnusha.org>; Sat, 27 Sep 2025 10:30:44 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1758994238; cv=pass;
        d=google.com; s=arc-20240605;
        b=VQXsxJVkYzo8uwvGNN9R73c71rhaa0NqiRFdgHdIANkyZHBYK+4KfgOpBcHiJQTYwi
         h2VJBJmbOfHekAQ7RA5O0MbxFoYzAd47sSfDzi8fJ7Ff0A6UNMKLiV3Q4gFAZLNslfK9
         t5IDEP4dRf7m3F8mJT3egWWvFEQ6jYcrO8ErcJfnrODg+IBBN3ZLPWgHDcwqBlMpFACE
         oj+Ve+o/+m0HaOXQhQpZKlv23AypPaVlLbbaVzADHGclJl362HUUyr9dGEnbgyXQzmJa
         rwN+IOcmOKBev7C7SvrjEYtPA3yVGpMQ2FGOAw1tMuUEYYO17F7iIwAVVHiOaLiWBlNJ
         Fn/g==
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:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=jNijCv+efhjonFgM3M0UP+S5QnfXkoZ1H5DbG5Lj9PQ=;
        fh=E0SrtS4YROgUk0deBgzo+dXPVO87c3CMH6/HOgTlMLs=;
        b=CYXgpIBQBcvnF2zvts+qSubeTOr+gdkt/Paaf6+QwX6GhL29n1KG4YgDr32HQqHzpm
         W+Ek/q8MK/1qsfWyKOMf52NOUbJf20Qlsu6zI3LW/vgcWPuMY+yG+aVExs0wtvSe8Uvu
         9Dj3JVgegUGCkMIOC+Kr8tYcPA0ncZJWJnyJaoNurgis8nQHSXO6ehTvqniY5FGk0a3N
         DmDpefcuYvHXJWLia6TS3EhA77cJL+yOXy1U5iiRnNoyO/f+c0TcbQTVOQHjZraYql7W
         Ec+1W8cRTDJplUmN9y7KE26xIhVCohMSEk+TJH8Qq3mMi79PxmEzUQxZGTKAEQX6qkVj
         hGPA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=dZdOS7GX;
       spf=pass (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=kanzure@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=1758994238; x=1759599038; 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:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=jNijCv+efhjonFgM3M0UP+S5QnfXkoZ1H5DbG5Lj9PQ=;
        b=GQIOY0qdIebev1a0rlRTyvXuWOA8wMUXHCRuzdrUvKW9cU9x3h0BTPlzv2wLrVq1IN
         4IM7XDYUjf7pTyAlaKfHYdpJ+CX4vyAWNTSDvlWlc/ejq6oqtXknM022qwoGu4jrcbVh
         WawvPWaVyBaEwysQ+88/iPYdGzhoqUWQc5viSmgktr1gmgl5ugs7ZLsOI6jccKay7W5z
         mA1/ylV0lpMRz5EJQ6hYxelrgc0YgCdVjSnRYtV/aWsnWYUBa7XwBDO2Tkf0uKl5EKO9
         rwfWy7S1uBx/POzAyESzHPLzziGzG3KZcXzmj2OnIqkTVLbKhYZ+lmPtFmR6inSZNG2p
         kAjg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758994238; x=1759599038; 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:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=jNijCv+efhjonFgM3M0UP+S5QnfXkoZ1H5DbG5Lj9PQ=;
        b=JD3tspcH9tfgfkp8A4GYGGUK7gzraxxuN1psKtfhvyO+xmh6vbVcQ3H5N7NSE9OUSL
         DiAzfdlCBnNaDTYpRrEQnw5RcimKAxIM3TrJq1p2h556CFdLX0poDUPFdddC0zI1lAM4
         z5KDzVdelqxa4iJwMNVEcewh6JA63NuoNLuMEG7DFiN4wh21xa3tq9Lq13m/VL/kBLAk
         xRLnAufEcjmQLXqVJXVdEfq+c1j2JoJ3BGV0a+5JK8ftfR1AuQOdD99U7cPkiKEkt4u8
         RHeInPlP/wI36H6iIv3boeLqWloQNJzxJyDQT2hj1Gwhnz6RWiQdQpKXE6IpDuuQr3go
         V1Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758994238; x=1759599038;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc: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=jNijCv+efhjonFgM3M0UP+S5QnfXkoZ1H5DbG5Lj9PQ=;
        b=xItH1p9fmi5whXeRU46UTnJL3uNnhcbi4FMHS7z3kNgADw+o//zwT2tth0oDmZeAer
         aeUxOUscWvmRhbnMEDb3IJV6ZZ5ehmU2ONHriYstGhx/64sAuoS+EYO5HtpypO6WTZ24
         sQEZjzZ26WwmrrfY0SZP4RmR87LNDJPTPs9HZXR6ULthFtIqle2INOBb5OSFhmR2ChKx
         7zQPA96ZOK2JOCxUrnyoFtCamo7mgwZDXDAsU5NpBClGpl1vBTu2NX/Gvr8dpCYuqf5B
         3cd0JfDL+F9Kuw+EClfVXaYDGrnDtwZfSwcNXo5eTtM4j4h1ZJ+8D0MVvwvobNSyoIO+
         mOzw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW8ss2z70D8FU08W70DCM/qRu3nccGosoM4Gx2YIZtlgLMumjbxeLd4rDMUKuE/3/8trXJqJuG1e0o3@gnusha.org
X-Gm-Message-State: AOJu0YyC6cmCJ/pyqQ+tyxFkvWjA+RVxD/mB3XZQf5TqCy/hsyciZYT6
	7BmdEv43EZrv1/lkUaDAj+5IS9aduXZGjMf5If43Ja41nS+2A4yT7reo
X-Google-Smtp-Source: AGHT+IEDL1sCZgvrTqoFlrd2Vw/JFrr10hZ+QqNWHmQsyDa+J3SL/0gBeR0JvZq4U82p3PWgve6TrA==
X-Received: by 2002:a05:6808:398b:b0:43f:1c66:bb94 with SMTP id 5614622812f47-43f4d01e931mr4693539b6e.47.1758994238036;
        Sat, 27 Sep 2025 10:30:38 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd79TSntXkSYhtCtCVwJvx1JrHOJFpg104kV7JjIW9Ew0w=="
Received: by 2002:a05:6820:c08a:10b0:61d:a119:bc4f with SMTP id
 006d021491bc7-63a7533e53als1395065eaf.1.-pod-prod-07-us; Sat, 27 Sep 2025
 10:30:34 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCX3GEGP17cARsUr38ma9aeUPw0qQFjiedUyk4sFk1ijHcUj4wsFcu7lIIvr2PQlonZ4m6nmnHRO7FWm@googlegroups.com
X-Received: by 2002:a05:6808:6707:b0:43f:2642:5c5a with SMTP id 5614622812f47-43f4ccf361fmr5079120b6e.8.1758994234250;
        Sat, 27 Sep 2025 10:30:34 -0700 (PDT)
Received: by 2002:a05:6504:604b:b0:2c0:aeab:e1f7 with SMTP id a1c4a302cd1d6-2c8266c4d25msc7a;
        Sat, 27 Sep 2025 09:49:45 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCWgV6tZ/TVDXUrGQgEecJa/xiTrJPll9zTM04hF8PBMrPUce63G8zW2cOz3PWBXC2jyLj1DYfm69zO2@googlegroups.com
X-Received: by 2002:a05:6512:61af:b0:55f:701f:933 with SMTP id 2adb3069b0e04-582d3114babmr3760558e87.41.1758991782353;
        Sat, 27 Sep 2025 09:49:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1758991782; cv=none;
        d=google.com; s=arc-20240605;
        b=E+3Tbu5OVwJ8uTwbFCRMAqTBdYj0i94XsZ8/uYe4ICs0J7K0z0lKS0h+0ZEVtiqIgm
         O/yfoicLh78oyqrSwuCmn2pdPQCM7arjqyoVcwQjZctDCApHtVTxO1L8K/Uw2be+ivOO
         H+fKFE3qr+7WVKAfgHl2aJzxzs6vH1QUPrM9PnPiYakPUktHPr4I1JbHTzmSeET9BRH4
         mCX1XaOyU5Eg8LE1hTw1yxnwUAPKW1MVFsZi/9YuvyLnEhBVyIxMe5tmg5RT0vglAnjy
         1p1c+0fdm2DZ34VbIMIffzOunCgAj+XD33PCIynjasO5bHMcqG/9pbJ3miyrb0NjpapA
         JbZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:subject:message-id:date:from:in-reply-to:references:mime-version
         :dkim-signature;
        bh=Mnz1TeL54ELiznlQCWRdSI0B4wMkN0ItewxIuuvBumQ=;
        fh=MfeKzpPU1r7h5zgu/sjLce1Y4LV7HicCO7HK0bYZq9U=;
        b=QpVZ90fQv0dO5jvrlcFBAe25hn0rD06MhbODE6dFsewptDsXNi7jkOc7ye5nlBdy36
         HbBPqZOrieNwdncfx6D1iU/KmFb9FaSWDMecVbhz1hqfK2JQ4ecnCFvtD6bvpgd6S4y+
         KKTbUde5lxE3Nv6PF9YZLAY1h9u9RBKllb6oXfggjJSFE3f4hLAY3v/WGGHYt6cKynj4
         3+eR40XxQEPHUHn/xJfNZT0O8Bofna25YNMWJACYjLxjQyb65DpFpCbe1HCS5glxS/tc
         mZvVE6AhuRbSv7731fHvF9x5ablwf6X++l2SA/TGvPRazBT1dK93OzwUyKILGM8tOlU5
         ZVTw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=dZdOS7GX;
       spf=pass (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=kanzure@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com. [2a00:1450:4864:20::532])
        by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-58316c1d316si132656e87.6.2025.09.27.09.49.42
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Sat, 27 Sep 2025 09:49:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) client-ip=2a00:1450:4864:20::532;
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-61a8c134533so6074470a12.3
        for <bitcoindev@googlegroups.com>; Sat, 27 Sep 2025 09:49:42 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCWiOKzsrQqNBNEKZGXv7VJPIsZCAoqRUYMXOUU1mFfc18gy3+4aupTazIsvuZmv6gUgdHSyHA0z0cqH@googlegroups.com
X-Gm-Gg: ASbGncsrdsEk26dGLSYK8er0Vle46zHH5s0sNb4EeYYs9t59YK85ofJ61LdFIUxOC1Z
	hqkeGNL/HgblXFkZhMq85jQLnq7fCuXLYSXxsYhzKAZNNO10QBTwT/BTc8SfBIc6vfcYsObDjLm
	wSLyMom1Tx3E6yQYYI5n0L/LlPToLajEtFuWBarKnwrY5ztSlkMDNP4l4Io/bNohPSDtJMMEdPp
	rh/JVM6oO8vbMjyW2MA8JcJNDCjVdDVrvvfG1IOcg==
X-Received: by 2002:aa7:d4d3:0:b0:633:54f4:6af8 with SMTP id
 4fb4d7f45d1cf-6349f9f00d7mt7759830a12.13.1758991781259; Sat, 27 Sep 2025
 09:49:41 -0700 (PDT)
MIME-Version: 1.0
References: <cbdab6fa-93bc-44c9-80f0-6c68c6554f56n@googlegroups.com>
 <CAAS2fgRFP+BJUZR7h01=7=qamD5qEW6OYJikTMR=5RkxTCEMZg@mail.gmail.com>
 <de4dae19-86f4-4d7a-a895-b48664babbfcn@googlegroups.com> <CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA@mail.gmail.com>
 <CAAANnUxBTRzE1PLe9oJU_ukmp3a_y799W_7Ez4rOUOYPhdu26A@mail.gmail.com>
 <aNXRSd7ygh6NqE1V@mail.wpsoftware.net> <CAN7kyNgxnKoX7OBLOiHZWLg+9rvisbpmEMrs9RsSMDfeT-sw3w@mail.gmail.com>
 <Rr9InzRLdLOAtNdtSzmgBmCX634eSgDHEPS4fW-0WCCA31XHfbTSWQ1tweH0GeNhH9BhCREn_2sU5AR2SmXXgOm8SpkkVwciq7ql8K7yBiE=@proton.me>
In-Reply-To: <Rr9InzRLdLOAtNdtSzmgBmCX634eSgDHEPS4fW-0WCCA31XHfbTSWQ1tweH0GeNhH9BhCREn_2sU5AR2SmXXgOm8SpkkVwciq7ql8K7yBiE=@proton.me>
From: Bryan Bishop <kanzure@gmail.com>
Date: Sat, 27 Sep 2025 11:49:30 -0500
X-Gm-Features: AS18NWCzRIMc3Az1DkF7CUsH2NGZD2eziJmyMDQgHvrsk-F84e_Fy-2bT1wPqb8
Message-ID: <CABaSBaywaebTUgoVKnNfnhy7psd-=08GnePCbBJmF1WvcZqkYw@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
Cc: Andrew Poelstra <apoelstra@wpsoftware.net>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>, Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000004a4f71063fcb303e"
X-Original-Sender: kanzure@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=dZdOS7GX;       spf=pass
 (google.com: domain of kanzure@gmail.com designates 2a00:1450:4864:20::532 as
 permitted sender) smtp.mailfrom=kanzure@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.4 (/)

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

It's rich to see someone lecturing andytoshi about the benefits of
replacing block content with succinct proofs. To be clear, pruning is not
the same thing as replacing blocks with proofs. Schemes like mimblewimble
or whatever else came after that he worked on are not SPV style abandonment
of verification. Or maybe we have forgotten?

Anyway, let's keep in mind that nobody is saying you cannot run a filter or
install one yourself. Anyone can run any software on their machine they
want. But you cannot force others to run it... or at least developers
around here won't go along with trying to force unremovable auto updates
etc.

The question at hand isn't the existence or possibility of filters, nor of
existence of bitcoin p2p protocol users that choose to filter, it's instead
about pressuring Bitcoin Core developers to release and endorse software
that includes certain filters--- which sets bad precedent against bitcoin
ethos (by which I mean "these transactions are argued to be harmful to
bitcoin so Core should do something even more harmful to bitcoin" is bad
precedent), also these people either don't want to do it or don't agree
with doing so and have been refusing to go along with the demands; going
along with the demands is itself another way to set a bad precedent. Such
pressure should first before all else be unilaterally rejected, as there is
no obligation expressed or implied, not to mention the coercive nature of
trying to force someone to act against their personal judgement or
values....

My reply below.

On Sat, Sep 27, 2025, 10:22=E2=80=AFAM 'OJ' via Bitcoin Development Mailing=
 List <
bitcoindev@googlegroups.com> wrote:

> I fail to understand how we come from "filters do not work" to "filters
> adopted by a majority is censorship".
>
If the goal of your mempool transaction filters is to prohibit certain
content on your node, then filters do not work because filters are not
applied to received blocks. You might not want to run bitcoin at all, even
in blocksonly mode + pruning, if you don't want bitcoin data on your
machine, actually.

If the goal of your filters is to prohibit content in other people's
mempools, then your local filters cannot achieve that because anyone can
put anything they want into their mempool even without your knowledge. This
is even true if a Bitcoin Core release was to ship new, overbearing default
filters etc.

Yes, even with a Core release, still developers around the world cannot
dictate what software or rules the protocol users choose to run themselves,
nor the contents of their mempools.

For those purposes it is clear that your filters do not work. They don't
achieve those goals, in answer to your question.

If you want to run a mempool with filters, then you have not been unable to
do that. If you want to run a node that does not gossip transactions or run
a mempool, then you are again not restricted from doing so. Use blocksonly,
use pruning, or even write your own software and place it on a webpage for
others to voluntarily download. For people who want to extra filter this
should be fantastic news because if they previously believed filters must
be distributed by a Core release, then now they are free from the burden of
that false belief and should feel relieved.

Even if relay filters are adopted by a majority of the p2p network, it
still doesn't work to stop the transactions because the transactions get
encoded into blocks, and then you receive blocks....  unless you don't
download blocks or run bitcoin.


As for the censorship question, perhaps instead ask what the purpose and
function of a mempool is. Why might a node have a mempool? After all, if
what you want is to see or have a history of transactions, then you have
the blocks of executed transactions. What then is the purpose of a node
having a mempool? It should seem absurd to you.

Maybe even the answers to these questions might help us to understand the
motivations or goals of developers as to what is included or not in the
software they write?

It's a possibility.

There seems to be a confusion too regarding filtering arbitrary data and
> censorship of consensus valid tx, like OFAC compliant block. Those two ar=
e
> different.
>
They aren't different; anyone is free to filter just as anyone is free to
mine your-so-called compliance block, which by the way leaves valuable fees
to others.

> Also the thinking that miners control the network is also bad as its
>
Who has argued that? What does control even mean here?

> miners are the one that should take notice of what the relay network
> homogeneous mempool is.
>

What?

> This BIP proposal move in the right direction in regards to finding a
> compromise while not disparaging anyones right as a free agent node runne=
r.
>
If you honestly believe that, then I have very good news for you: you don't
need a BIP or Core release: users can simply download, write or use
whatever software with whatever filters they want. Mom compromise is
needed, because the bitcoin status quo already enables the
freedom-nondisparagement you seek. In fact, I would argue that you should
prefer that it does not need to be a default or a BIP, because enabling the
coordination and distribution of the tools of censorship seems contrary to
the purpose and goals of bitcoin.


- Bryan
https://x.com/kanzure




>
> -------- Original Message --------
> On 9/26/25 2:03 PM, Garlo Nicon wrote:
>
> > You cannot pick and choose which parts of a block you like and which
> parts are "abusive".
>
> In the current implementation, yes. But if you accept a proof, that a
> block is valid, instead of accepting a block in plaintext, then you can
> land on the same chain. Because after all, pruned nodes care only about t=
he
> last 288 blocks, or something like that. If they can update their UTXO se=
t,
> and always land on a valid chain, then they don't need transaction data i=
n
> plaintext. They just need to update their UTXO database in a way, where
> attacking it would require breaking ECDSA, SHA-256, or similar things (a
> proof-based system, which would not weaken existing cryptographic
> assumptions, would be sufficient).
>
> And the same is true about Initial Blockchain Download. Only today, you
> have to download hundreds of GBs, to synchronize the new node from scratc=
h.
> But it can be changed, and as the size of the whole chain will grow, peop=
le
> will be pushed, to start deploying some optimizations. Otherwise, there
> will be even less nodes, if node operators will decide to trust centraliz=
ed
> solutions instead, or do things, which already happened in some altcoins,
> where people passed around an already synced node data, and trusted, that
> it is valid (especially in CPU-mined coins, where verifying thousands
> blocks required similar effort, than mining a new block).
>
> pt., 26 wrz 2025 o 02:25 Andrew Poelstra <apoelstra@wpsoftware.net>
> napisa=C5=82(a):
>
>> On Thu, Sep 25, 2025 at 11:52:02AM -0600, Chris Guida wrote:
>> >
>> > Anyway, forcing users to relay transactions they consider abusive if
>> they
>> > want to relay any transactions at all does not seem in keeping with
>> > bitcoin's ethos, not to mention that it obviously would never work.
>> >
>>
>> Once a transaction is in a block, you need to relay the transaction if
>> you want to relay a block. You cannot pick and choose which parts of a
>> block you like and which parts are "abusive". This is what it means for
>> something to be a consensus system.
>>
>> The purpose of the mempool is to approximate the contents of blocks,
>> both to help individual node operators (who would otherwise get large
>> quantities of "surprise transactions" with every block) and to help the
>> network (which would otherwise have poor propagation properties).
>>
>> Any sort of filtering beyond that done by miners is contrary to this
>> purpose of the mempool. This is a technical fact. It has nothing to do
>> with "bitcoin's ethos", except its ethos as a consensus system, which
>> directly contradicts your point.
>>
>> --
>> Andrew Poelstra
>> Director, Blockstream Research
>> Email: apoelstra at wpsoftware.net
>> Web:   https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>>     -Justin Lewis-Webster
>>
>

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

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

<div dir=3D"auto"><div><div>It&#39;s rich to see someone lecturing andytosh=
i about the benefits of replacing block content with succinct proofs. To be=
 clear, pruning is not the same thing as replacing blocks with proofs. Sche=
mes like mimblewimble or whatever else came after that he worked on are not=
 SPV style abandonment of verification. Or maybe we have forgotten?</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Anyway, let&#39;s keep in mind =
that nobody is saying you cannot run a filter or install one yourself. Anyo=
ne can run any software on their machine they want. But you cannot force ot=
hers to run it... or at least developers around here won&#39;t go along wit=
h trying to force unremovable auto updates etc.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">The question at hand isn&#39;t the existence or pos=
sibility of filters, nor of existence of bitcoin p2p protocol users that ch=
oose to filter, it&#39;s instead about pressuring Bitcoin Core developers t=
o release and endorse software that includes certain filters--- which sets =
bad precedent against bitcoin ethos (by which I mean &quot;these transactio=
ns are argued to be harmful to bitcoin so Core should do something even mor=
e harmful to bitcoin&quot; is bad precedent), also these people either don&=
#39;t want to do it or don&#39;t agree with doing so and have been refusing=
 to go along with the demands; going along with the demands is itself anoth=
er way to set a bad precedent. Such pressure should first before all else b=
e unilaterally rejected, as there is no obligation expressed or implied, no=
t to mention the coercive nature of trying to force someone to act against =
their personal judgement or values....</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">My reply below.</div><div data-smartmail=3D"gmail_signature"=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Sat, Sep 27, 2025, 10:22=E2=80=AFAM &#39;OJ&#39; via Bitcoin Developmen=
t Mailing List &lt;<a href=3D"mailto:bitcoindev@googlegroups.com" target=3D=
"_blank" rel=3D"noreferrer">bitcoindev@googlegroups.com</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir=3D"ltr">I fai=
l to understand how we come from &quot;filters do not work&quot; to &quot;f=
ilters adopted by a majority is censorship&quot;.</p></blockquote></div></d=
iv><div dir=3D"auto"></div><div dir=3D"auto"></div><div dir=3D"auto">If the=
 goal of your mempool transaction filters is to prohibit certain content on=
 your node, then filters do not work because filters are not applied to rec=
eived blocks. You might not want to run bitcoin at all, even in blocksonly =
mode + pruning, if you don&#39;t want bitcoin data on your machine, actuall=
y.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If the goal of your f=
ilters is to prohibit content in other people&#39;s mempools, then your loc=
al filters cannot achieve that because anyone can put anything they want in=
to their mempool even without your knowledge. This is even true if a Bitcoi=
n Core release was to ship new, overbearing default filters etc.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Yes, even with a Core release, sti=
ll developers around the world cannot dictate what software or rules the pr=
otocol users choose to run themselves, nor the contents of their mempools.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">For those purposes it is=
 clear that your filters do not work. They don&#39;t achieve those goals, i=
n answer to your question.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">If you want to run a mempool with filters, then you have not been unable=
 to do that. If you want to run a node that does not gossip transactions or=
 run a mempool, then you are again not restricted from doing so. Use blocks=
only, use pruning, or even write your own software and place it on a webpag=
e for others to voluntarily download. For people who want to extra filter t=
his should be fantastic news because if they previously believed filters mu=
st be distributed by a Core release, then now they are free from the burden=
 of that false belief and should feel relieved.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Even if relay filters are adopted by a majority of =
the p2p network, it still doesn&#39;t work to stop the transactions because=
 the transactions get encoded into blocks, and then you receive blocks....=
=C2=A0 unless you don&#39;t download blocks or run bitcoin.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">As for th=
e censorship question, perhaps instead ask what the purpose and function of=
 a mempool is. Why might a node have a mempool? After all, if what you want=
 is to see or have a history of transactions, then you have the blocks of e=
xecuted transactions. What then is the purpose of a node having a mempool? =
It should seem absurd to you.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Maybe even the answers to these questions might help us to understand=
 the motivations or goals of developers as to what is included or not in th=
e software they write?</div><div dir=3D"auto"><br></div><div dir=3D"auto">I=
t&#39;s a possibility.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
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"=
><p dir=3D"ltr"> There seems to be a confusion too regarding filtering arbi=
trary data and censorship of consensus valid tx, like OFAC compliant block.=
 Those two are different.</p></blockquote></div></div><div dir=3D"auto">The=
y aren&#39;t different; anyone is free to filter just as anyone is free to =
mine your-so-called compliance block, which by the way leaves valuable fees=
 to others.</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><p dir=3D"ltr">Also the thinking that =
miners control the network is also bad as its</p></blockquote></div></div><=
div dir=3D"auto">Who has argued that? What does control even mean here?</di=
v><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><p dir=3D"ltr">miners are the one that should take no=
tice of what the relay network homogeneous mempool is.</p></blockquote></di=
v></div><div dir=3D"auto"><br></div><div dir=3D"auto"></div><div dir=3D"aut=
o">What?</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><p dir=3D"ltr">This BIP proposal move in =
the right direction in regards to finding a compromise while not disparagin=
g anyones right as a free agent node runner.</p></blockquote></div></div><d=
iv dir=3D"auto">If you honestly believe that, then I have very good news fo=
r you: you don&#39;t need a BIP or Core release: users can simply download,=
 write or use whatever software with whatever filters they want. Mom compro=
mise is needed, because the bitcoin status quo already enables the freedom-=
nondisparagement you seek. In fact, I would argue that you should prefer th=
at it does not need to be a default or a BIP, because enabling the coordina=
tion and distribution of the tools of censorship seems contrary to the purp=
ose and goals of bitcoin.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">- Bryan</div><div dir=3D"auto"><a href=3D"htt=
ps://x.com/kanzure" target=3D"_blank" rel=3D"noreferrer">https://x.com/kanz=
ure</a></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
<div><br><br>-------- Original Message --------<br>On 9/26/25 2:03 PM, Garl=
o Nicon <u></u> wrote:<br><blockquote><div dir=3D"ltr">&gt; You cannot pick=
 and choose which parts of a block you like and which parts are &quot;abusi=
ve&quot;.<br><br>In the current implementation, yes. But if you accept a pr=
oof, that a block is valid, instead of accepting a block in plaintext, then=
 you can land on the same chain. Because after all, pruned nodes care only =
about the last 288 blocks, or something like that. If they can update their=
 UTXO set, and always land on a valid chain, then they don&#39;t need trans=
action data in plaintext. They just need to update their UTXO database in a=
 way, where attacking it would require breaking ECDSA, SHA-256, or similar =
things (a proof-based system, which would not weaken existing cryptographic=
 assumptions, would be sufficient).<br><br>And the same is true about Initi=
al Blockchain Download. Only today, you have to download hundreds of GBs, t=
o synchronize the new node from scratch. But it can be changed, and as the =
size of the whole chain will grow, people will be pushed, to start deployin=
g some optimizations. Otherwise, there will be even less nodes, if node ope=
rators will decide to trust centralized solutions instead, or do things, wh=
ich already happened in some altcoins, where people passed around an alread=
y synced node data, and trusted, that it is valid (especially in CPU-mined =
coins, where verifying thousands blocks required similar effort, than minin=
g a new block).</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">pt., 26 wrz 2025 o 02:25=C2=A0Andrew Poelstra &lt;<a href=
=3D"mailto:apoelstra@wpsoftware.net" rel=3D"noreferrer noreferrer" target=
=3D"_blank">apoelstra@wpsoftware.net</a>&gt; napisa=C5=82(a):<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 25, 2025 at 11:52=
:02AM -0600, Chris Guida wrote:<br>
&gt; <br>
&gt; Anyway, forcing users to relay transactions they consider abusive if t=
hey<br>
&gt; want to relay any transactions at all does not seem in keeping with<br=
>
&gt; bitcoin&#39;s ethos, not to mention that it obviously would never work=
.<br>
&gt;<br>
<br>
Once a transaction is in a block, you need to relay the transaction if<br>
you want to relay a block. You cannot pick and choose which parts of a<br>
block you like and which parts are &quot;abusive&quot;. This is what it mea=
ns for<br>
something to be a consensus system.<br>
<br>
The purpose of the mempool is to approximate the contents of blocks,<br>
both to help individual node operators (who would otherwise get large<br>
quantities of &quot;surprise transactions&quot; with every block) and to he=
lp the<br>
network (which would otherwise have poor propagation properties).<br>
<br>
Any sort of filtering beyond that done by miners is contrary to this<br>
purpose of the mempool. This is a technical fact. It has nothing to do<br>
with &quot;bitcoin&#39;s ethos&quot;, except its ethos as a consensus syste=
m, which<br>
directly contradicts your point.<br>
<br>
-- <br>
Andrew Poelstra<br>
Director, Blockstream Research<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer nor=
eferrer noreferrer" target=3D"_blank">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer noreferrer noreferrer" target=3D"_blank">https://www.wpsoftware.net/a=
ndrew</a><br>
<br>
The sun is always shining in space<br>
=C2=A0 =C2=A0 -Justin Lewis-Webster<br></blockquote></div></blockquote></di=
v>
</blockquote></div></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">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CABaSBaywaebTUgoVKnNfnhy7psd-%3D08GnePCbBJmF1WvcZqkYw%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CABaSBaywaebTUgoVKnNfnhy7psd-%3D08GnePCbBJmF1WvcZqkYw%40ma=
il.gmail.com</a>.<br />

--0000000000004a4f71063fcb303e--