path: root/a0/b829b5a413967d4a522cdb35245368586d5871

Delivery-date: Thu, 25 Sep 2025 15:29:44 -0700
Received: from mail-oo1-f56.google.com ([209.85.161.56])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCJNLJPWXAIBBTEE27DAMGQEJETHY3Y@googlegroups.com>)
	id 1v1uT8-00056i-L2
	for bitcoindev@gnusha.org; Thu, 25 Sep 2025 15:29:44 -0700
Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6234905c106sf921936eaf.1
        for <bitcoindev@gnusha.org>; Thu, 25 Sep 2025 15:29:42 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1758839376; cv=pass;
        d=google.com; s=arc-20240605;
        b=WtZogPEW2wYdvj6Y0mLPFHK6XTSWNij7BFp2hAaGgLE9oRdgZvaLWA7XJvCkMng/H9
         yf4V5IpRXK2Gg8TxB7LDfRC9iDie6XGWqZLk21HkORKvlMX2xZd0Sfuash4z/FCew99D
         fN+ZTs+p1a8pj7cfLQ8V9gJ8BtDVu6PyPNFtre5QjKZG3P9h7hbitU0S8T62DhC88/yB
         vh039doDxYd4p9Z65WsJLrblcZbdbXBT5Z/Ycj8uaQay3wR7jpuQvDeUhU5rhRBknnP8
         zF7zE3494g99MHtvI5xJbD49XQG4fqfOKlZhQzGL3ozRxfpzVmqAD/pzjdjhH5hBW+87
         50cA==
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=rwD+19GWLV2IfyDG7uotoahQ5AWhNzM76l/lnYR7mp8=;
        fh=IG0kdS56r1rMEFYkwJz3PhscNPT8seqsNKl4PSkuoGs=;
        b=G7K7anso9GhpkSQX9kJc8QEed6UrCiyA/BqKJzGDhKSeyGdzAA4Gt7qb3NC7FPydrK
         MrKq5Vps6IZcL9Mnp5A3MCuWiXyPpi5TRc0VcXdHsOXpQQt6Wc9MZGcLs1eFGHpstBGF
         nTQDEjeXo+OjDi0i6xsvc60iw3yVsLJkW6VVoRUnr24b1iKZtDnCf+xKKjhkScTToOz9
         NDxoQ150vmZn7U2/8sjM3bw7xjlBSKmK/Vig4Kyj4xEbm+K6EdomauHmFlzK8UqFQuMd
         t9LzbMiGQ2nz9/lmcJ08pBtcRALDt9hOC5bHMcpHNeqIenZ8sFGIGzQlgAvtAnKzTVKS
         JtRg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=RUK3D9zX;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=gmaxwell@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=1758839376; x=1759444176; 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=rwD+19GWLV2IfyDG7uotoahQ5AWhNzM76l/lnYR7mp8=;
        b=ke6lPEwc97K6aS6zSWgFjidQ4wo0Dw/mut/Yf13xd3GV9eAWizDK2uZbtVzsybHA8q
         lnHgoRdA/WfLeBQOwc2z3JaLNoVFwOdy9WpeXFyF9xK7dsXbRJ4RCLDhKN5UQWVH8X2e
         vVkP1xo8JPQ+L+0zRYfqklyf2drRVCEenXp52LdoQAIpCum3pu/56I8HqDLi05KBFjzA
         AdgNEhWoogcOl7qszx1+wjqzlm3OmY8BK1UZiuS/2yXV5vqzIXw2wwVDWWDSKOfL6Gpq
         l+IKrcgo8MHz2rVviye46h8SZMR4DK7tLbI+o0CpRIIUD0M3JwAe33BIFURJ06TayYIi
         SNpQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758839376; x=1759444176; 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=rwD+19GWLV2IfyDG7uotoahQ5AWhNzM76l/lnYR7mp8=;
        b=gifDJR6gLJnUOEvJSDwzyebEQKTFr9iMHmucWS6xhzFH9DEQbEoub2yoipKjWslEjO
         oRlGsP/nH26bmdfN61HNMrToMydtHYHyu+UzIXtuQ0emfFEFcXiq929CsjT5PCjrRfwB
         /vNhV3ezifCLro8f0F3zrNhgxCz1Q8uKd1axamSvVa923fUXDxfYgyVVmIDZNgUoxyYP
         oABe2ujjexr3I6QdYhb/TKHkemtFTIU7o9ytj/3Q/zFrS10wFLLAh30K4S1sm0G0EnoR
         pTTaWaGIRDNPVx4w88XmpZSiLbcjaZ/uWEA32LpLx2cU6r7aroV6vlQrEma+76iTR9tk
         663w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758839376; x=1759444176;
        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=rwD+19GWLV2IfyDG7uotoahQ5AWhNzM76l/lnYR7mp8=;
        b=Iw4xccSB0wNnnjl4m/YwdFJP8Ag1qT04Sjwg0758F03AOeo9hlHleZXU2W24PPFnzv
         8muo+mQ2nrM2iG+XgWa4OhuT4fykGKzHbGQJfZsov2dmQWQ5qeC5D28W++uHz1OdfRIn
         sFT1Xn0PeYnLpvn+Zhh5QqBdsziSFrO5E5KGCS37OmdsiGMZLyoV0cY75fxm0qQN27Lg
         /0GktEYQ7btGAYcDp/Gt3Izx99RtkwelEc2inuBm7IaVaE4fKNx+mhJG9+p02xhEYBKu
         LZP9QCjYxPfYD3klfAfwTeOHNkhTBpijeGZzpKSInpNmouidxUbWnjvoqU/zWa4Ykznp
         J0JA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWIy4HLcL15DK4dSJFKpb695ixs7y/j8mlpdEnSxvySv5u9QZ4XO+LPbfLU1a8LmjfzPnL+Qc4PwGy1@gnusha.org
X-Gm-Message-State: AOJu0YwR45F/vxzlskh8hDM0jrf49BY4IApjSav/wi6voFoS8Kr93pZ+
	+AQWc3X3dqpPDNNRr438TvYG+PogG85uq+hF8gyE/b1jElVZNJYwMpSb
X-Google-Smtp-Source: AGHT+IFqWJ5aQ3EQmFE3Cx93EWaNLbNnx0/g+auugU1WePAVivWpaXViyEkXzEcmpu8m/GtYhJhqSA==
X-Received: by 2002:a05:6870:569f:b0:315:60a6:c28f with SMTP id 586e51a60fabf-361fad104dcmr2442175fac.3.1758839375785;
        Thu, 25 Sep 2025 15:29:35 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6LVmhVfDmAj5fypcZI5CuSKi9chA7Eq831QrcNllJySg=="
Received: by 2002:a05:6871:285:b0:35d:3a1c:4779 with SMTP id
 586e51a60fabf-35ef16fd5c3ls926661fac.2.-pod-prod-00-us; Thu, 25 Sep 2025
 15:29:32 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCXnIW5aTzyMEo7jKey6mlMwpq1HKrrTbJ8BwTMH0u3oZf6m/9K6x1J5EkcEXZ8Z0W/IUs3bpazYLfqF@googlegroups.com
X-Received: by 2002:a05:6808:68d3:10b0:40b:a4ca:f7cb with SMTP id 5614622812f47-43f50329302mr1876510b6e.15.1758839372553;
        Thu, 25 Sep 2025 15:29:32 -0700 (PDT)
Received: by 2002:a05:6808:22c9:b0:438:241d:e72f with SMTP id 5614622812f47-43f5e412992msb6e;
        Thu, 25 Sep 2025 14:51:16 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCWqu1guQx4NZuwoIBRjIbjhlWQo3+Fq4NM4J/bG/Ew1tehI8zxf3VgF/PtwNHXMad9AsqMJQWGvASNQ@googlegroups.com
X-Received: by 2002:a17:90b:4c03:b0:32e:7ff6:6dbd with SMTP id 98e67ed59e1d1-3345218af15mr4130587a91.0.1758837074959;
        Thu, 25 Sep 2025 14:51:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1758837074; cv=none;
        d=google.com; s=arc-20240605;
        b=jNT2J1BCjD/QFK93wsup52EAXlhEvJkED5Ub1t9qRtjkofChwEvVNdomqpsDYCayPr
         Kdbj2XrOEpvSSdaszj8CViN6gL+7Sk8X07cT8hJqp3W2A2zkziW0cQkDZXeJmYGBRlbt
         N8Fcu6UtkEJHmBo/W6HHKA/XwzNRWdAeYA6vkXLiNubJJ3IoT4I7gK9huT1qYSN/1nsS
         AMwJRNKgGw/fQR8/D/s3NGJzT/xpPZt4u3TKDLvmmYgBFwMJnbE6wyfkPDRQhXTMoEMS
         vCbcZMsQF/bgeHv0wGGiI4r6Qq5Fy8FUd5yX39MV0hDeu7Cdkbn4u1HAL7qWy6zfgY1y
         LcoQ==
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=ASOUPBPTJsiVJKA5avXOQ+jnJFw5utpzh26hj5ppTlg=;
        fh=V1CZqBagEkGfFbEeIfPQ57VHdohDwPn4iXKxUwMuQFQ=;
        b=kaw0JW7SQa+hxX/NhJVZkG8KiNacKjsQ7Mcc93Y8FkPmW8SS9aJFMeiq62NDPIkB81
         Rr7wzIKTP39z4Bm9RlA5otwCQLvxMIdqu1i2awoF2wkV7QpWQo6+WcrH84XjFYH1rh4x
         2+o8HmeMWPZJZX/MH/adQ+jyOr24e/7nrYu7QWom7CvcRSb7LS4j6BcicgoHwocsLyy4
         tvymenrcwQZ5NJWRn9JXhC/hJ8ti1tvNskaObvLsBjwKkaD+1kXFBYngLaKktLIdk3dT
         xJ57JBKac7IjkRg616qxoOHYqcQMN430E5tvI2pt0hrPHFWV1pI1MOA78u/FuYoL9uqJ
         RhLQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=RUK3D9zX;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com. [2607:f8b0:4864:20::631])
        by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3341baae843si248970a91.0.2025.09.25.14.51.14
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 25 Sep 2025 14:51:14 -0700 (PDT)
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) client-ip=2607:f8b0:4864:20::631;
Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-279e2554b5fso13092215ad.1
        for <bitcoindev@googlegroups.com>; Thu, 25 Sep 2025 14:51:14 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCVwApXHo1+bO3WF8fyxsM5v6s8LhCzUOvKqXuo0gWyKhvSqjc2TU8NeOc7Ag5mVAOqzViLxd81/UWbh@googlegroups.com
X-Gm-Gg: ASbGncvcAAOhwjNmIDCx4hiwfHyO6U2mvGs1paGuqJOXz46BNvuBh5M3cE8ckIPzOmk
	QmaQzc1iw/sskHdlHjb9ZZjQEB9ral+YklENP0SiYeLMRN2vUJGQ2mxeMQ+hT/4Ntg+T5MDfrhT
	R50eQQdpH7Edf7bqbx/Q6E2o8l2aoodbJwdflrpzPW3EM9kV4kBKfZk96grBsQTj1B7/Hews3kj
	fRRHk3JDvjmNedfSA==
X-Received: by 2002:a17:902:e745:b0:272:d27d:48de with SMTP id
 d9443c01a7336-27ed6e05744mr50376555ad.18.1758837074258; Thu, 25 Sep 2025
 14:51:14 -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>
 <CAPDT2SRyVY4rh=HegG+kk5nnDf6qzYuRkUyxCC8iE-ydsh63ew@mail.gmail.com>
 <CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w@mail.gmail.com>
 <CAOSz24TJU-4Q76MtzL+oYYFpXQvrOay5XtdrR0DxVBUAFz=5og@mail.gmail.com>
 <CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ@mail.gmail.com> <CAOSz24SdZeV=1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg@mail.gmail.com>
In-Reply-To: <CAOSz24SdZeV=1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg@mail.gmail.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Thu, 25 Sep 2025 21:51:02 +0000
X-Gm-Features: AS18NWA0iaO8s98KeooUWsKoYP4Xketa8BTdZdLHLCZQ4bIZ0QdN6cP12GvKKCA
Message-ID: <CAAS2fgSXX5_TU86r=QOQAvg84tpRa7o9ha5=En3tPmTUBrrqhw@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
To: Aiden McClelland <me@drbonez.dev>
Cc: yes_please <caucasianjazz12@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000077197063fa72b0f"
X-Original-Sender: gmaxwell@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=RUK3D9zX;       spf=pass
 (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::631
 as permitted sender) smtp.mailfrom=gmaxwell@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 (/)

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

"There are levels of survival we are prepared to accept."

Black and white thinking is not very helpful here particularly because the
goals of pro-filtering and anti-censorship aren't exact opposites.

A widely censored world would greatly degrade the value of
Bitcoin, particularly if the censors managed to enlist significant miners.
It would be routed around at great cost, and with much less freedom
provided for the world.  But just like people continue to buy racy
magazines or other completely lawful targets of operation chokepoint with
USD, people would still route around Bitcoin censorship.   But why even use
Bitcoin if it's in a similar space of your transactions being capriciously
blocks, your funds frozen, etc. as exists with legacy infrastructure?

But the irony is that the traffic that people most desperately want to stop
would be among the least impeded-- already today the spam traffic exists at
all because it's well funded (or really existed a year ago, we are long
past the huge spam floods-- they were depleted by costs and fizzled as
predicted-- and Ocean Mining is fighting yesterday's battle. But what
exists exists because its well funded).  Meanwhile joe blow sending funds
p2p to friends or family in far off places doesn't have the funds or
technical acumen to deal with censorship potentially targeting him, his
activities, or his payees.  The effect of censorship is basically to
require people to learn how to be money launderers to freely transact, and
those who don't suffer.

The case is even stronger re: the recently filtering arguments because
unlike some consensus rule anyone can just mine a block (rent hashpower,
you don't have to own it) or even more so the stuff like op_return limits
have long been bypassed by major miners.  So the policy restriction was
already not working.   So in some sense there are arguments getting
conflated:  The op_return policy limit has already failed.  So when people
point out that it doesn't work it's just a statement of fact rather than
speculation.  But basically the 'bad' traffic has a lot easier time than
more innocent traffic, which is part of why filters can be both ineffective
and dangerous.  It's also the case that existing filter efforts are not
backed by civil litigation or state mandates, but building infrastructure
creates an obvious stepping stone to that (in part because of the
insufficient effectiveness of filtering)-- it's just a bad road that will
almost inevitably lead to more escalations.   Bitcoin is just better of
adopting the position that other people's transactions aren't our business,
even if they're stupid or drive fees up a bit for some periods and create
annoyances, because the alternative is easily much worse.



















On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McClelland <me@drbonez.dev> w=
rote:

> >I have no idea what you're referring to there.
>
> It's something I inferred from your primary argument that seems to be tha=
t
> user-configurable filters are bad because they would cause censorship. Bu=
t
> it also sounds like you're saying such filters are completely ineffective
> at any sort of censorship at all. I don't really understand how these two
> viewpoints can coexist. What am I missing here?
>
> Best,
> *Aiden McClelland*
>
> On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> w=
rote:
>
>> I am not a core developer. I have not been for some eight years now.
>>
>> > that you yourself are worried they will reach the 80% needed
>>
>> I have no idea what you're referring to there.  If lots of people run
>> nodes that screw up propagation they'll be routed around.  I developed t=
he
>> technical concepts required to get nearly 100% tx coverage even if almos=
t
>> all nodes are blocking them quite a few years ago (
>> https://arxiv.org/pdf/1905.10518 ), but deployment of the implementation
>> has gone slow due to other factors (you know, such as the most
>> experienced developers being hit with billions of dollars in lawsuits as=
 a
>> cost for their support of Bitcoin)... I expect if censoring actually
>> becomes widespread that technological improvements which further moot it
>> will be developed.
>>
>> These are just vulnerabilities that should be closed anyways-- after all
>> anyone at any time can just spin up any number of "nodes" that behave in
>> arbitrary ways, at ant time.  It's been a lower priority because there a=
re
>> other countermeasures (addnode-a-friend, manually setbanning bad peers,
>> etc.) and aforementione distractions.
>>
>> > censorship due to widespread use of transaction filters is a bad thing
>> (I'm not really taking a stance on that right now).
>>
>> I would point you to the history of discussion on Bitcoin starting back
>> with Satoshi's earliest announcements, and perhaps to help you understan=
d
>> that if you want that what you want isn't bitcoin.  If after considerati=
on
>> you don't think censorship wouldn't be very bad, then really you and I h=
ave
>> nothing further to discuss.
>>
>> > are you willing to work with and compromise with people who are lookin=
g
>> for a solution like this? Or are you going to force them to abandon the
>> Core project entirely
>>
>> I don't really think there is any space to compromise with people who
>> think it's okay to add censorship to Bitcoin-- I mean sure whatever exac=
t
>> relay policy there is there is plenty of tradeoffs but from the start of
>> this new filter debate the filter proponents have immediately come out w=
ith
>> vile insults accusing developers of promoting child sexual abuse and
>> shitcoins and what not----  that isn't some attempt to navigate a
>> technical/political trademark, it's an effort to villify and destory the
>> opposition.   And unambiguously so as luke has said outright that his go=
al
>> is to destroy Bitcoin Core.  So what's the compromise there?
>>
>> > Or even worse still, felt compelled to coordinate a UASF to block thes=
e
>> transactions entirely?
>>
>> I very much think people should do that-- they should actually make some
>> consensus rules for their filters to fork off and we can see what the
>> market thinks.  -- And also even if the market prefers censored Bitcoin,
>> that's also fine with me, in the sense in my view Bitcoin was created to=
 be
>> money as largely free from human judgement as possible.  When it was
>> created most of the world was doing something else and didn't know they
>> needed freedom money.  If it's still the case that most of the world
>> doesn't want freedom money that would be no shock. They should be free t=
o
>> have what they want and people who want freedom money should be free to
>> have what they want.  I got into bitcoin before it was worth practically
>> anything because of the freedom it provides, and I think that's paramoun=
t.
>>
>> Perhaps you should consider why they *don't* do that?  I'd say it's
>> because (1) it won't work, and (2) it's not actually what the world want=
s--
>> an outspoken influence campaign is not necessarily all that reflective o=
f
>> much of anything.  Particularly given how inaccurate and emotionally
>> pandering the filter advocacy has been.   But, hey, I've been wrong
>> before.
>>
>>
>>
>> On Thu, Sep 25, 2025 at 8:51=E2=80=AFPM Aiden McClelland <me@drbonez.dev=
> wrote:
>>
>>> Greg,
>>>
>>> Let me assume for a minute, for the sake of argument, that I agree that
>>> transaction censorship due to widespread use of transaction filters is =
a
>>> bad thing (I'm not really taking a stance on that right now). It is an
>>> irrefutable fact that a very large portion of the user base wants to fi=
lter
>>> transactions. So many so, that you yourself are worried they will reach=
 the
>>> 80% needed to prevent certain types of transactions from propogating.
>>> Wouldn't it then be *worse* if these 80% of users went and ran an
>>> alternative implementation, most likely written by it's most radical
>>> supporters? Or even worse still, felt compelled to coordinate a UASF to
>>> block these transactions entirely?
>>>
>>> I at no point intended to insinuate that you or any other core
>>> contributer be compelled to implement a proposal like this. It's up to =
its
>>> supporters to do so. The real question is, are you willing to work with=
 and
>>> compromise with people who are looking for a solution like this? Or are=
 you
>>> going to force them to abandon the Core project entirely?
>>>
>>> Best,
>>> *Aiden McClelland*
>>>
>>> On Thu, Sep 25, 2025, 2:03=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com>=
 wrote:
>>>
>>>> > 1) Allowing node
>>>>
>>>> Who said anything about allowing?  Everyone is allowed to do whatever
>>>> they want.  Drill a hole in your head if you like, not my concern.  No=
ne of
>>>> this thread is about what people are allowed to do-- that's off the ta=
ble.
>>>> The design and licensing of Bitcoin is such that no one gets to stop a=
nyone
>>>> else from what they want to do anyways (which is, in fact, a big part =
of
>>>> the issue here).   To think otherwise is to be stuck in a kind of serf
>>>> thinking where you can only do what other people allow you to do.  Tha=
t has
>>>> never been what Bitcoin was about.
>>>>
>>>> Rather, the question is should people who care about Bitcoin spend
>>>> their time and money developing infrastructure that would be useful, e=
ven
>>>> primarily useful, for censorship.  I say no.  Especially because any t=
ime
>>>> spent on it is time away from anti-censorship pro-privacy tools and be=
cause
>>>> the effort spent doing so would undermine anti-censorship and pro-priv=
acy
>>>> efforts because they would inevitably moot the efforts expected gettin=
g
>>>> into peoples business and filtering their transactions.
>>>>
>>>> You don't have to agree, and you're free to do your own thing just as
>>>> I'm free to say that I think it's a bad direction.  From the very begi=
nning
>>>> Bitcoin has stood against the freedom to transact being overridden by
>>>> some admin based on their judgment call weighing principles against ot=
her
>>>> concerns, or at the behest of their superiors.  So many Bitcoiner will
>>>> stand against, route around, and do what they can do to make ineffectu=
al
>>>> the blocking of consensual transactions.  It might not seem as many at=
 the
>>>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a =
paid
>>>> PR and influence campaign,  but it also doesn't matter so much because
>>>> Bitcoin takes advantage of the nature of information being easy to spr=
ead
>>>> and hard to stifel and it doesn't that that huge an effort to route ar=
ound
>>>> censorship efforts.
>>>>
>>>> There are elements of anti-censorship in Bitcoin that have been so far
>>>> underdeveloped.  It's unfortunate that their further development might=
 be
>>>> forced at a time when efforts are needed on other areas.  But perhaps =
they
>>>> wouldn't get done without a concrete motivation. Such is life.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 25, 2025 at 9:21=E2=80=AFAM yes_please <caucasianjazz12@gm=
ail.com>
>>>> wrote:
>>>>
>>>>> Sorry Greg, could you please elaborate further on your ideas? Some ar=
e
>>>>> not exactly clear:
>>>>>
>>>>> 1) Allowing node runners to configure their node as they please and
>>>>> refuse to relay some txs is considered authoritarian, censorship, and=
 an
>>>>> attempt to regulate third parties conduct. On the other hand, forcing=
 nodes
>>>>> to merge towards a single shared configuration (by preventing them to=
 block
>>>>> txs) is not considered authoritarian because this imposition does not
>>>>> discriminate towards any txs and is thus non-authoritarian? Did I get=
 the
>>>>> reasoning correctly here?
>>>>>
>>>>> 2) If the aim is to have a homogenous mempool state and to model what
>>>>> will get mined, shouldn=E2=80=99t we reach this state through distrib=
uted
>>>>> independent nodes who decide independently on what they prefer this
>>>>> homogenous state to be? If we don=E2=80=99t reach this state through =
this
>>>>> distributed/independent mechanism, then how are we to reach this stat=
e? Who
>>>>> gets to decide and steer the direction so that we all converge toward=
s this
>>>>> homogenous state?  One of the strongest aspects of bitcoin is the fac=
t that
>>>>> no single party can force a change/direction, and the network has to
>>>>> somehow reach a shared agreement through independent decision makers =
who
>>>>> act in what manner they think is best. The proposed BIP seems to be a=
ligned
>>>>> with such a principle, I fail to see any authoritarian aspect here.
>>>>>
>>>>> 3) I share your sentiment and the aim to have a homogenous mempool
>>>>> state, but I am skeptical of the manner in which we are to achieve th=
is
>>>>> according to the ideas you have here expressed (namely not through a
>>>>> distributed independent organic manner)
>>>>>
>>>>>
>>>>> Respectfully, yes_please
>>>>>
>>>>> On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell <gmaxwell@gmail=
.com>
>>>>> wrote:
>>>>>
>>>>>> So that when the "consistent state" changes as a result of some issu=
e
>>>>>> you can update configs instead of having to update software-- which =
has
>>>>>> considerable more costs and risks, especially if you're carrying loc=
al
>>>>>> customizations as many miners do.
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland <me@drbonez=
.dev>
>>>>>> wrote:
>>>>>>
>>>>>>> If mempool consistency across the network is all that is important,
>>>>>>> why allow any configuration of mempool relay policies at all?
>>>>>>>
>>>>>>> On Wednesday, September 24, 2025 at 12:47:28=E2=80=AFPM UTC-6 Greg =
Maxwell
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This appears to substantially misunderstands the purpose of the
>>>>>>>> mempool broadly in the network-- it's purpose is to model what wil=
l get
>>>>>>>> mined.  If you're not doing that you might as well set blocks only=
.
>>>>>>>> Significant discrepancies are harmful to the system and promote
>>>>>>>> centralization and fail to achieve a useful purpose in any case.  =
What
>>>>>>>> marginal benefits might be provided do not justify building and de=
ploying
>>>>>>>> the technological infrastructure for massive censorship.
>>>>>>>>
>>>>>>>> If you think this is important, I advise you to select another
>>>>>>>> cryptocurrency which is compatible with such authoritarian leaning=
s.  --
>>>>>>>> though I am unsure if any exist since it is such a transparently p=
ointless
>>>>>>>> direction.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@drb=
onez.dev>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I'd like to share for discussion a draft BIP to allow for a
>>>>>>>>> modular mempool/relay policy:
>>>>>>>>> https://github.com/bitcoin/bips/pull/1985
>>>>>>>>>
>>>>>>>>> I think it could potentially reduce conflict within the community
>>>>>>>>> around relay policy, as an alternative to running lots of differe=
nt node
>>>>>>>>> implementations/forks when there are disagreements.
>>>>>>>>>
>>>>>>>>> I am working on a reference implementation using Bellard's
>>>>>>>>> QuickJS, but it has been almost a decade since I've written C++, =
so it's
>>>>>>>>> slow going and I'm sure doesn't follow best-practices. Once it's =
working,
>>>>>>>>> it can be cleaned up.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Aiden McClelland
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Googl=
e
>>>>>>>>> Groups "Bitcoin Development Mailing List" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to bitcoindev+...@googlegroups.com.
>>>>>>>>> To view this discussion visit
>>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-8=
0f0-6c68c6554f56n%40googlegroups.com
>>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-=
80f0-6c68c6554f56n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfoote=
r>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> --
>>>>>>> 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/de4dae19-86f4-4d7a-a89=
5-b48664babbfcn%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a8=
95-b48664babbfcn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>>> 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/CAAS2fgRABqRe1j6xzW0uhV=
rDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uh=
VrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com?utm_medium=3Demail&utm_sourc=
e=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/=
CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com.

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

<div dir=3D"ltr"><div>&quot;There are levels of survival we are prepared to=
 accept.&quot;</div><div><br></div><div>Black and white thinking is not ver=
y helpful=C2=A0here particularly because the goals of pro-filtering and ant=
i-censorship aren&#39;t exact opposites.</div><div><br></div><div>A widely =
censored world would greatly degrade the value of Bitcoin,=C2=A0particularl=
y if the censors managed to enlist significant miners.=C2=A0 It would be ro=
uted around at great cost, and with much less freedom provided for the worl=
d.=C2=A0 But just like people continue to buy racy magazines or other compl=
etely lawful targets of operation chokepoint=C2=A0with USD, people would st=
ill route around Bitcoin censorship.=C2=A0 =C2=A0But why even use Bitcoin i=
f it&#39;s in a similar space of your transactions being capriciously block=
s, your funds frozen, etc. as exists with legacy infrastructure?</div><div>=
<br></div><div>But the irony is that the traffic that people most desperate=
ly want to stop would be among the least impeded-- already today the spam t=
raffic exists at all because it&#39;s well funded (or really existed a year=
 ago, we are long past the huge spam floods-- they were depleted by costs a=
nd fizzled as predicted--=C2=A0and Ocean Mining is fighting yesterday&#39;s=
 battle. But what exists exists because its well funded).=C2=A0 Meanwhile j=
oe blow sending funds p2p to friends or family in far off places doesn&#39;=
t have the funds or technical acumen=C2=A0to deal with censorship potential=
ly targeting him, his activities, or his payees.=C2=A0 The effect of censor=
ship is basically to require people to learn how to be money launderers to =
freely transact, and those who don&#39;t suffer.</div><div><br></div><div>T=
he case is even stronger re: the recently filtering arguments because unlik=
e some consensus rule anyone can just mine a block (rent hashpower, you don=
&#39;t have to own it) or even more so the stuff like op_return limits have=
 long been bypassed by major miners.=C2=A0 So the policy restriction was al=
ready not working.=C2=A0 =C2=A0So in some sense there are arguments getting=
 conflated:=C2=A0 The op_return policy limit has already failed.=C2=A0 So w=
hen people point out that it doesn&#39;t work it&#39;s just a statement of =
fact rather than speculation.=C2=A0 But basically the &#39;bad&#39; traffic=
 has a lot easier time than more innocent traffic, which is part of why fil=
ters can be both ineffective and dangerous.=C2=A0 It&#39;s also the case th=
at existing filter efforts are not backed by civil litigation or state mand=
ates, but building infrastructure creates an obvious stepping stone to that=
 (in part because of the insufficient effectiveness of filtering)-- it&#39;=
s just a bad road that will almost inevitably lead to more escalations.=C2=
=A0 =C2=A0Bitcoin is just better of adopting the position that other people=
&#39;s transactions aren&#39;t our business, even if they&#39;re stupid or =
drive fees up a bit for some periods and create annoyances, because the alt=
ernative is easily much worse.</div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div>=C2=A0=C2=A0</div><div><br></div><div><br></div><=
div><br></div></div><br><div class=3D"gmail_quote gmail_quote_container"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM=
 Aiden McClelland &lt;<a href=3D"mailto:me@drbonez.dev">me@drbonez.dev</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"auto"><div>&gt;I have no idea what you&#39;re referring to there.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">It&#39;s something I infer=
red from your primary argument that seems to be that user-configurable filt=
ers are bad because they would cause censorship. But it also sounds like yo=
u&#39;re saying such filters are completely ineffective at any sort of cens=
orship at all. I don&#39;t really understand how these two viewpoints can c=
oexist. What am I missing here?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Best,</div><div><font face=3D"courier new, monospace"><b>Aiden Mc=
Clelland</b></font></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell=
 &lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>I am not a core developer. I have not been for so=
me eight years now.=C2=A0 =C2=A0</div><div><br></div><div>&gt;=C2=A0that yo=
u yourself are worried they will reach the 80% needed</div><div><br></div><=
div>I have no idea what you&#39;re referring to there.=C2=A0 If lots of peo=
ple run nodes that screw up propagation they&#39;ll be routed around.=C2=A0=
 I developed the technical concepts required to get nearly 100% tx coverage=
 even if almost all nodes are blocking them quite a few years ago ( <a href=
=3D"https://arxiv.org/pdf/1905.10518" rel=3D"noreferrer" target=3D"_blank">=
https://arxiv.org/pdf/1905.10518</a> ), but deployment of the implementatio=
n has gone slow due to other factors (you know, such as the most experience=
d=C2=A0developers being hit with billions of dollars in lawsuits as a cost =
for their support of Bitcoin)... I expect if censoring actually becomes wid=
espread that technological improvements which further moot it will be devel=
oped.</div><div><br></div><div>These are just vulnerabilities that should b=
e closed anyways-- after all anyone at any time can just spin up any number=
 of &quot;nodes&quot; that behave in arbitrary=C2=A0ways, at ant time.=C2=
=A0 It&#39;s been a lower priority because there are other countermeasures =
(addnode-a-friend, manually setbanning=C2=A0bad peers, etc.) and aforementi=
one distractions.</div><div><br></div><div>&gt;=C2=A0censorship due to wide=
spread use of transaction filters is a bad thing (I&#39;m not really taking=
 a stance on that right now).</div><div><br></div><div>I would point you to=
 the history of discussion on Bitcoin starting back with Satoshi&#39;s earl=
iest announcements, and perhaps to help you understand that if you want tha=
t what you want isn&#39;t bitcoin.=C2=A0 If after consideration you don&#39=
;t think censorship wouldn&#39;t be very bad, then really you and I have no=
thing further to discuss.</div><div><br></div><div>&gt;=C2=A0are you willin=
g to work with and compromise with people who are looking=20
for a solution like this? Or are you going to force them to abandon the=20
Core project entirely</div><div><br></div><div>I don&#39;t really think the=
re is any space to compromise with people who think it&#39;s okay to add ce=
nsorship to Bitcoin-- I mean sure whatever exact relay policy there is ther=
e is plenty of tradeoffs but from the start of this new filter debate the f=
ilter proponents have immediately come out with vile insults accusing devel=
opers of promoting child sexual abuse and shitcoins and what not----=C2=A0 =
that isn&#39;t some attempt to navigate a technical/political trademark, it=
&#39;s an effort to villify and destory the opposition.=C2=A0 =C2=A0And una=
mbiguously=C2=A0so as luke has said outright that his goal is to destroy Bi=
tcoin Core.=C2=A0 So what&#39;s the compromise there?=C2=A0=C2=A0</div><div=
><br></div><div>&gt;=C2=A0Or even worse still, felt compelled to coordinate=
 a UASF to block these transactions entirely?</div><div><br></div><div>I ve=
ry much think people should do that-- they should actually make some consen=
sus rules for their filters to fork off and we can see what the market thin=
ks.=C2=A0 -- And also even if the market prefers censored Bitcoin, that&#39=
;s also fine with me, in the sense in my view Bitcoin was created to be mon=
ey as largely free from human judgement as possible.=C2=A0 When it was crea=
ted most of the world was doing something else and didn&#39;t know they nee=
ded freedom money.=C2=A0 If it&#39;s still the case that most of the world =
doesn&#39;t want freedom money that would be no shock. They should be free =
to have what they want and people who want freedom money should be free to =
have what they want.=C2=A0 I got into bitcoin before it was worth practical=
ly anything because of the freedom it provides, and I think that&#39;s para=
mount.</div><div><br></div><div>Perhaps you should consider why they *don&#=
39;t* do that?=C2=A0 I&#39;d say it&#39;s because (1) it won&#39;t work, an=
d (2) it&#39;s not actually what the world wants-- an outspoken influence c=
ampaign is not necessarily all that reflective of much of anything.=C2=A0 P=
articularly given how inaccurate and emotionally pandering the filter advoc=
acy has been.=C2=A0 =C2=A0But, hey, I&#39;ve been wrong before.=C2=A0=C2=A0=
</div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25, 2025 at 8:51=E2=80=AFPM=
 Aiden McClelland &lt;<a href=3D"mailto:me@drbonez.dev" rel=3D"noreferrer" =
target=3D"_blank">me@drbonez.dev</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"auto"><div>Greg,=C2=A0</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Let me assume for a minute, for=
 the sake of argument, that I agree that transaction censorship due to wide=
spread use of transaction filters is a bad thing (I&#39;m not really taking=
 a stance on that right now). It is an irrefutable fact that a very large p=
ortion of the user base wants to filter transactions. So many so, that you =
yourself are worried they will reach the 80% needed to prevent certain type=
s of transactions from propogating. Wouldn&#39;t it then be <i>worse</i> if=
 these 80% of users went and ran an alternative implementation, most likely=
 written by it&#39;s most radical supporters? Or even worse still, felt com=
pelled to coordinate a UASF to block these transactions entirely?</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">I at no point intended to insinua=
te that you or any other core contributer be compelled to implement a propo=
sal like this. It&#39;s up to its supporters to do so. The real question is=
, are you willing to work with and compromise with people who are looking f=
or a solution like this? Or are you going to force them to abandon the Core=
 project entirely?</div><div><br></div><div dir=3D"auto">Best,</div><div><f=
ont face=3D"courier new, monospace"><b>Aiden McClelland</b></font></div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Thu, Sep 25, 2025, 2:03=E2=80=AFPM Greg Maxwell &lt;<a href=3D"mailto:gmaxw=
ell@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">gmaxwell@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div>&gt;=C2=A0<span lang=3D"EN-US">1)=C2=A0</span><=
span lang=3D"EN-US">Allowing node</span></div><div><span lang=3D"EN-US"><br=
></span></div><div><span lang=3D"EN-US">Who said anything about allowing?=
=C2=A0 Everyone is allowed to do whatever they want.=C2=A0 Drill a hole in =
your head if you like, not my concern.=C2=A0 None of this thread is about w=
hat people are allowed to do-- that&#39;s off the table.=C2=A0 The design a=
nd licensing of Bitcoin is such that no one gets to stop anyone else from w=
hat they=C2=A0want to do anyways (which is, in fact, a big part of the issu=
e here).=C2=A0 =C2=A0To think otherwise is to be stuck in a kind of serf th=
inking where you can only do what other people allow you to do.=C2=A0 That =
has never been what Bitcoin was about.</span></div><div><span lang=3D"EN-US=
"><br></span></div><div><span lang=3D"EN-US">Rather, the question is should=
 people who care about Bitcoin spend their time and money developing infras=
tructure that would be useful, even primarily useful, for censorship.=C2=A0=
 I say no.=C2=A0 Especially because any time spent on it is time away from =
anti-censorship pro-privacy tools and because the effort spent doing so wou=
ld undermine anti-censorship and pro-privacy efforts because they would ine=
vitably=C2=A0moot the efforts=C2=A0expected getting into peoples business a=
nd filtering their transactions.</span></div><div><span lang=3D"EN-US"><br>=
</span></div><div><span lang=3D"EN-US">You don&#39;t have to agree, and you=
&#39;re free to do your own thing just as I&#39;m free to say that I think =
it&#39;s a bad=C2=A0direction.=C2=A0 From the very beginning Bitcoin has st=
ood against the freedom to transact being=C2=A0</span>overridden by some ad=
min based on their judgment call weighing principles against other concerns=
, or at the behest of their superiors.=C2=A0 So many Bitcoiner will stand a=
gainst, route around, and do what they can do to make ineffectual the block=
ing of consensual=C2=A0transactions.=C2=A0 It might not seem as many at the=
 moment, but the pro-privacy and anti-censorship &#39;side&#39; doesn&#39;t=
 have a paid PR and influence campaign,=C2=A0 but it also doesn&#39;t matte=
r so much because Bitcoin takes advantage of the nature of information bein=
g easy to spread and hard to stifel and it doesn&#39;t that that huge an ef=
fort to route around censorship efforts.</div><div><br></div><div>There are=
 elements of anti-censorship in Bitcoin that have been so far underdevelope=
d.=C2=A0 It&#39;s unfortunate that their further development might be force=
d at a time when efforts are needed on other areas.=C2=A0 But perhaps they =
wouldn&#39;t get done without a concrete motivation. Such is life.</div><di=
v><br></div><div><span lang=3D"EN-US"><br></span></div><div><span lang=3D"E=
N-US"><br></span></div><div><span lang=3D"EN-US"><br></span></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, S=
ep 25, 2025 at 9:21=E2=80=AFAM yes_please &lt;<a href=3D"mailto:caucasianja=
zz12@gmail.com" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">=
caucasianjazz12@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><p style=3D"color:rgba(232,230,22=
7,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size=
:14px"><span lang=3D"EN-US">Sorry Greg, could you please elaborate further =
on your ideas? Some are not exactly clear:</span></p><p style=3D"color:rgba=
(232,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-seri=
f;font-size:14px"><span lang=3D"EN-US">1)=C2=A0</span><span lang=3D"EN-US">=
Allowing node runners to configure their node as they please and refuse to =
relay some txs is considered authoritarian, censorship, and an attempt to r=
egulate third parties conduct. On the other hand, forcing nodes to merge to=
wards a single shared configuration (by preventing them to block txs) is no=
t considered authoritarian because this imposition does not discriminate to=
wards any txs and is thus non-authoritarian? Did I get the reasoning correc=
tly here?</span></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Ro=
boto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"E=
N-US">2) I</span><span>f the aim is to have a homogenous mempool state and =
to model what will get mined, shouldn=E2=80=99t we reach this state through=
 distributed independent nodes who decide=C2=A0independently on what they p=
refer this homogenous state to be? If we don=E2=80=99t reach this state thr=
ough this distributed/independent mechanism, then how are we to reach this =
state? Who gets to decide and steer the direction so that we all converge t=
owards this homogenous state?=C2=A0 One of the strongest aspects of bitcoin=
 is the fact that no single party can force a change/direction, and the net=
work has to somehow reach a shared agreement through independent decision m=
akers who act in what manner they think is best. The proposed BIP seems to =
be aligned with such a principle, I fail to see any authoritarian aspect he=
re.=C2=A0</span></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Ro=
boto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span>3)=C2=A0<=
/span><span>I share your sentiment and the aim to have a homogenous mempool=
 state, but I am skeptical of the manner in which we are to achieve this ac=
cording to the ideas you have here expressed (namely not through a distribu=
ted independent organic manner)</span></p><p style=3D"color:rgba(232,230,22=
7,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size=
:14px"><span lang=3D"EN-US"><br></span></p><p style=3D"color:rgba(232,230,2=
27,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-siz=
e:14px"><span lang=3D"EN-US">Respectfully, yes_please=C2=A0=C2=A0=C2=A0</sp=
an></p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell &lt;<a href=3D=
"mailto:gmaxwell@gmail.com" rel=3D"noreferrer noreferrer noreferrer" target=
=3D"_blank">gmaxwell@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>So that when the &quot;=
consistent state&quot; changes as a result of some issue you can update con=
figs instead of having to update software-- which has considerable more cos=
ts and risks, especially if you&#39;re carrying local customizations as man=
y miners do.</div><div><br></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Ai=
den McClelland &lt;<a href=3D"mailto:me@drbonez.dev" rel=3D"noreferrer nore=
ferrer noreferrer" target=3D"_blank">me@drbonez.dev</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">If mempool consistency a=
cross the network is all that is important, why allow any configuration of =
mempool relay policies at all?<br><br><div class=3D"gmail_quote"><div dir=
=3D"auto" class=3D"gmail_attr">On Wednesday, September 24, 2025 at 12:47:28=
=E2=80=AFPM UTC-6 Greg Maxwell wrote:<br></div><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"><div dir=3D"ltr"><div>This appears to substantially=
=C2=A0misunderstands the purpose of the mempool broadly in the network-- it=
&#39;s purpose is to model what will get mined.=C2=A0 If you&#39;re not doi=
ng that you might as well set blocks only.=C2=A0 Significant=C2=A0discrepan=
cies=C2=A0are harmful to the system and promote centralization=C2=A0and fai=
l to achieve a useful purpose in any case.=C2=A0 What marginal benefits mig=
ht be provided do not justify=C2=A0building and deploying the technological=
=C2=A0infrastructure=C2=A0for massive censorship.</div><div><br></div><div>=
If you think this is important, I advise you to select another cryptocurren=
cy which is compatible with such authoritarian=C2=A0leanings.=C2=A0 -- thou=
gh I am unsure if any exist since it is such a transparently pointless dire=
ction.</div><div><br></div></div><br><div class=3D"gmail_quote"></div><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 24,=
 2025 at 6:30=E2=80=AFPM Aiden McClelland &lt;<a rel=3D"nofollow noreferrer=
 noreferrer noreferrer">m...@drbonez.dev</a>&gt; wrote:<br></div></div><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv>Hi all,</div><div><br></div><div>I&#39;d like to share for discussion a =
draft BIP to allow for a modular mempool/relay policy: <a href=3D"https://g=
ithub.com/bitcoin/bips/pull/1985" rel=3D"nofollow noreferrer noreferrer nor=
eferrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/1985</a><br=
><br></div><div>I think it could potentially reduce conflict within the com=
munity around relay policy, as an alternative to running lots of different =
node implementations/forks when there are disagreements.</div><div><br></di=
v><div>I am working on a reference implementation using Bellard&#39;s Quick=
JS, but it has been almost a decade since I&#39;ve written C++, so it&#39;s=
 slow going and I&#39;m sure doesn&#39;t follow best-practices. Once it&#39=
;s working, it can be cleaned up.</div><div><br></div><div>Thanks,</div><di=
v>Aiden McClelland<br></div>

<p></p></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">

-- <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 rel=3D"nofollow noreferrer noreferrer noreferrer">bitcoindev+...=
@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow noreferrer noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/=
cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com</a>.<br>
</blockquote></div>
</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" rel=3D"n=
oreferrer noreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@g=
ooglegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer noreferre=
r" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/de4dae19-=
86f4-4d7a-a895-b48664babbfcn%40googlegroups.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" rel=3D"n=
oreferrer noreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@g=
ooglegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail=
.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferr=
er noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoind=
ev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com</a>=
.<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</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/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%=
40mail.gmail.com</a>.<br />

--000000000000077197063fa72b0f--