path: root/6e/76b62a2bda330955bf464608c014f8b35c813d

Delivery-date: Wed, 01 Oct 2025 12:57:50 -0700
Received: from mail-qt1-f185.google.com ([209.85.160.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC2JVH7GSAMBBKUP63DAMGQEFXQVVNY@googlegroups.com>)
	id 1v42xO-0000op-5b
	for bitcoindev@gnusha.org; Wed, 01 Oct 2025 12:57:50 -0700
Received: by mail-qt1-f185.google.com with SMTP id d75a77b69052e-4e1015c48c8sf27862921cf.1
        for <bitcoindev@gnusha.org>; Wed, 01 Oct 2025 12:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1759348654; x=1759953454; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :from:to:cc:subject:date:message-id:reply-to;
        bh=zJQ6pmGZYlRuZmchHszg5a5ewEufYYcSm3PleYg9UDw=;
        b=Zm71vAY2ewMh/Oc452/dftum06p7TM9K8zDHupDHqw5r6BjCDfnc2HBgM+JSDR0WN9
         n9Sgv6+dcYQtbT0kzLeRureInawnpNMSCFffuPztkmqJBNWVdcnaVACt2hRuMqfjQGIV
         BXB+Ttf0YG+TmSqhGb8deZbZBdekVn1P6BDcEHN95utYpFpJFVEaS6r/490tgzZAESpp
         HW4dZIqIdFgKtSrPuhU2QL9hyY26bmuGBMfUA5n9iOu6CDAb4d4LiNnwXfFW5JTCMfej
         +XglfJOD3/dJ7vA7wjkBzdgNdWT52P15sFxlI41GIXKNWpSHREoDvCX6T6JKBgrJ6iEG
         U0zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759348654; x=1759953454;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=zJQ6pmGZYlRuZmchHszg5a5ewEufYYcSm3PleYg9UDw=;
        b=VFGNHNoFZmDbh1LHLruf6WVuQg6C2/3UijLUOBxIreXt0/8g7uZtalXREdGEGXGR0q
         pj6qFgDaMQNJqWgN8ePWssd0I13OQOhGKgz9+Fx5MUhmKLfL4qOjBFX02xYCce1hJwWJ
         RQpUqfA1PsYobQnixv7PuQ+cFDscl12GugZknWjA0Pmed1/hCmoN0aKPiAJOmjJnC4vW
         k3/NiMcDmlgAG8ySxpbNGvw+Yp6LHcCPwVaF6pW2tkQFIHdV0ypaCesBXtWv5a6lkXUj
         qhh31AS+kaQhXVwJC6re1yKK9OSaIlg8XFyS20VfcuxKdEYai9vJmpyOqc408JnPrxGo
         XVGw==
X-Forwarded-Encrypted: i=1; AJvYcCWhitIlShGTuIDuk2nvDYKFmMRz2yW/ixF1555J2d9kY2ExQHaKHpYxrbECJ4JkYZ+JAmzX/ZYzC6k0@gnusha.org
X-Gm-Message-State: AOJu0YyEGNHom8qorzvbg4k+tnExzVnY7zPp+tpv0czW9kLfJ4i7TCKG
	gmqo5tGOJKM8MsxvxMsyssgka85nw75eBE436i4pua24EOrVAAbpLfte
X-Google-Smtp-Source: AGHT+IGqCZg3ZTFIZsCCt4g0MQr63dd5X21YpVUWjFtvcbP7CU+g4S8xLz9TK9fJqbZdiJ/nLzd7eg==
X-Received: by 2002:a05:622a:48c:b0:4d2:a1a7:2145 with SMTP id d75a77b69052e-4e5629a2ff3mr14381641cf.35.1759348653590;
        Wed, 01 Oct 2025 12:57:33 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd7RiRu9xnKSnCpUiNyo1lvP6XS5WwgwZuyhaaGyCc87uw=="
Received: by 2002:a05:622a:d15:b0:4b7:a98b:51db with SMTP id
 d75a77b69052e-4e55b4244afls7402081cf.2.-pod-prod-03-us; Wed, 01 Oct 2025
 12:57:30 -0700 (PDT)
X-Received: by 2002:ac8:42c3:0:b0:4dd:1a2f:4889 with SMTP id d75a77b69052e-4e5020fea56mr24200901cf.76.1759348650151;
        Wed, 01 Oct 2025 12:57:30 -0700 (PDT)
Received: by 2002:a81:f10e:0:b0:741:b7fe:46f4 with SMTP id 00721157ae682-76bc66ec1e9ms7b3;
        Fri, 26 Sep 2025 18:30:30 -0700 (PDT)
X-Received: by 2002:a05:690c:4d0a:b0:73c:3bfe:30cf with SMTP id 00721157ae682-763fc4c9021mr107010737b3.13.1758936629587;
        Fri, 26 Sep 2025 18:30:29 -0700 (PDT)
Date: Fri, 26 Sep 2025 18:30:29 -0700 (PDT)
From: "'Aiden McClelland' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <4968c87a-ab0a-47a7-9d38-e53fdae1630bn@googlegroups.com>
In-Reply-To: <CAAS2fgSXX5_TU86r=QOQAvg84tpRa7o9ha5=En3tPmTUBrrqhw@mail.gmail.com>
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>
 <CAAS2fgSXX5_TU86r=QOQAvg84tpRa7o9ha5=En3tPmTUBrrqhw@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_85518_1014478515.1758936629148"
X-Original-Sender: me@drbonez.dev
X-Original-From: Aiden McClelland <me@drbonez.dev>
Reply-To: Aiden McClelland <me@drbonez.dev>
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: -1.0 (-)

------=_Part_85518_1014478515.1758936629148
Content-Type: multipart/alternative; 
	boundary="----=_Part_85519_174257906.1758936629148"

------=_Part_85519_174257906.1758936629148
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Greg,=20

You've made some very compelling points. I really appreciate you taking the=
=20
time to explain your position, and I sympathize with it. I'm still not sure=
=20
I agree that there is no compromise here, or that allowing users to set=20
their own relay policy will result in significant censorship of real=20
transactions, but I'm not sure there's a way to prove who's right about=20
that until if/when it happens.=20

At the end of the day, users must be trusted with the ability to choose=20
what code they want to run, in bitcoin and otherwise. I will, as always, do=
=20
what I can to enable even the less technical among them to be able to do so=
=20
in the safest way possible. For now this seems to be helping some of them=
=20
run Knots. If you ever see a path forward for getting these users back onto=
=20
Core, I'm happy to collaborate.=20

Best,=20
Aiden McClelland


On Thursday, September 25, 2025 at 4:29:36=E2=80=AFPM UTC-6 Greg Maxwell wr=
ote:

> "There are levels of survival we are prepared to accept."
>
> Black and white thinking is not very helpful here particularly because th=
e=20
> goals of pro-filtering and anti-censorship aren't exact opposites.
>
> A widely censored world would greatly degrade the value of=20
> Bitcoin, particularly if the censors managed to enlist significant miners=
. =20
> It would be routed around at great cost, and with much less freedom=20
> provided for the world.  But just like people continue to buy racy=20
> magazines or other completely lawful targets of operation chokepoint with=
=20
> USD, people would still route around Bitcoin censorship.   But why even u=
se=20
> Bitcoin if it's in a similar space of your transactions being capriciousl=
y=20
> blocks, your funds frozen, etc. as exists with legacy infrastructure?
>
> But the irony is that the traffic that people most desperately want to=20
> stop would be among the least impeded-- already today the spam traffic=20
> exists at all because it's well funded (or really existed a year ago, we=
=20
> are long past the huge spam floods-- they were depleted by costs and=20
> fizzled as predicted-- and Ocean Mining is fighting yesterday's battle. B=
ut=20
> what exists exists because its well funded).  Meanwhile joe blow sending=
=20
> funds p2p to friends or family in far off places doesn't have the funds o=
r=20
> technical acumen to deal with censorship potentially targeting him, his=
=20
> activities, or his payees.  The effect of censorship is basically to=20
> require people to learn how to be money launderers to freely transact, an=
d=20
> those who don't suffer.
>
> The case is even stronger re: the recently filtering arguments because=20
> unlike some consensus rule anyone can just mine a block (rent hashpower,=
=20
> you don't have to own it) or even more so the stuff like op_return limits=
=20
> have long been bypassed by major miners.  So the policy restriction was=
=20
> already not working.   So in some sense there are arguments getting=20
> conflated:  The op_return policy limit has already failed.  So when peopl=
e=20
> point out that it doesn't work it's just a statement of fact rather than=
=20
> speculation.  But basically the 'bad' traffic has a lot easier time than=
=20
> more innocent traffic, which is part of why filters can be both ineffecti=
ve=20
> and dangerous.  It's also the case that existing filter efforts are not=
=20
> backed by civil litigation or state mandates, but building infrastructure=
=20
> creates an obvious stepping stone to that (in part because of the=20
> insufficient effectiveness of filtering)-- it's just a bad road that will=
=20
> almost inevitably lead to more escalations.   Bitcoin is just better of=
=20
> adopting the position that other people's transactions aren't our busines=
s,=20
> even if they're stupid or drive fees up a bit for some periods and create=
=20
> annoyances, because the alternative is easily much worse.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  =20
>
>
>
>
> On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McClelland <m...@drbonez.de=
v> wrote:
>
>> >I have no idea what you're referring to there.
>>
>> It's something I inferred from your primary argument that seems to be=20
>> that user-configurable filters are bad because they would cause censorsh=
ip.=20
>> But it also sounds like you're saying such filters are completely=20
>> ineffective at any sort of censorship at all. I don't really understand =
how=20
>> 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 <gmax...@gmail.com> w=
rote:
>>
>>> I am not a core developer. I have not been for some eight years now.  =
=20
>>>
>>> > 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=
=20
>>> nodes that screw up propagation they'll be routed around.  I developed =
the=20
>>> technical concepts required to get nearly 100% tx coverage even if almo=
st=20
>>> all nodes are blocking them quite a few years ago (=20
>>> https://arxiv.org/pdf/1905.10518 ), but deployment of the=20
>>> implementation has gone slow due to other factors (you know, such as th=
e=20
>>> most experienced developers being hit with billions of dollars in lawsu=
its=20
>>> as a cost for their support of Bitcoin)... I expect if censoring actual=
ly=20
>>> becomes widespread that technological improvements which further moot i=
t=20
>>> will be developed.
>>>
>>> These are just vulnerabilities that should be closed anyways-- after al=
l=20
>>> anyone at any time can just spin up any number of "nodes" that behave i=
n=20
>>> arbitrary ways, at ant time.  It's been a lower priority because there =
are=20
>>> other countermeasures (addnode-a-friend, manually setbanning bad peers,=
=20
>>> etc.) and aforementione distractions.
>>>
>>> > censorship due to widespread use of transaction filters is a bad thin=
g=20
>>> (I'm not really taking a stance on that right now).
>>>
>>> I would point you to the history of discussion on Bitcoin starting back=
=20
>>> with Satoshi's earliest announcements, and perhaps to help you understa=
nd=20
>>> that if you want that what you want isn't bitcoin.  If after considerat=
ion=20
>>> you don't think censorship wouldn't be very bad, then really you and I =
have=20
>>> nothing further to discuss.
>>>
>>> > are you willing to work with and compromise with people who are=20
>>> looking for a solution like this? Or are you going to force them to aba=
ndon=20
>>> the Core project entirely
>>>
>>> I don't really think there is any space to compromise with people who=
=20
>>> think it's okay to add censorship to Bitcoin-- I mean sure whatever exa=
ct=20
>>> relay policy there is there is plenty of tradeoffs but from the start o=
f=20
>>> this new filter debate the filter proponents have immediately come out =
with=20
>>> vile insults accusing developers of promoting child sexual abuse and=20
>>> shitcoins and what not----  that isn't some attempt to navigate a=20
>>> technical/political trademark, it's an effort to villify and destory th=
e=20
>>> opposition.   And unambiguously so as luke has said outright that his g=
oal=20
>>> is to destroy Bitcoin Core.  So what's the compromise there? =20
>>>
>>> > Or even worse still, felt compelled to coordinate a UASF to block=20
>>> these transactions entirely?
>>>
>>> I very much think people should do that-- they should actually make som=
e=20
>>> consensus rules for their filters to fork off and we can see what the=
=20
>>> market thinks.  -- And also even if the market prefers censored Bitcoin=
,=20
>>> that's also fine with me, in the sense in my view Bitcoin was created t=
o be=20
>>> money as largely free from human judgement as possible.  When it was=20
>>> created most of the world was doing something else and didn't know they=
=20
>>> needed freedom money.  If it's still the case that most of the world=20
>>> doesn't want freedom money that would be no shock. They should be free =
to=20
>>> have what they want and people who want freedom money should be free to=
=20
>>> have what they want.  I got into bitcoin before it was worth practicall=
y=20
>>> anything because of the freedom it provides, and I think that's paramou=
nt.
>>>
>>> Perhaps you should consider why they *don't* do that?  I'd say it's=20
>>> because (1) it won't work, and (2) it's not actually what the world wan=
ts--=20
>>> an outspoken influence campaign is not necessarily all that reflective =
of=20
>>> much of anything.  Particularly given how inaccurate and emotionally=20
>>> pandering the filter advocacy has been.   But, hey, I've been wrong=20
>>> before. =20
>>>
>>>
>>>
>>> On Thu, Sep 25, 2025 at 8:51=E2=80=AFPM Aiden McClelland <m...@drbonez.=
dev>=20
>>> wrote:
>>>
>>>> Greg,=20
>>>>
>>>> Let me assume for a minute, for the sake of argument, that I agree tha=
t=20
>>>> transaction censorship due to widespread use of transaction filters is=
 a=20
>>>> bad thing (I'm not really taking a stance on that right now). It is an=
=20
>>>> irrefutable fact that a very large portion of the user base wants to f=
ilter=20
>>>> transactions. So many so, that you yourself are worried they will reac=
h the=20
>>>> 80% needed to prevent certain types of transactions from propogating.=
=20
>>>> Wouldn't it then be *worse* if these 80% of users went and ran an=20
>>>> alternative implementation, most likely written by it's most radical=
=20
>>>> supporters? Or even worse still, felt compelled to coordinate a UASF t=
o=20
>>>> block these transactions entirely?
>>>>
>>>> I at no point intended to insinuate that you or any other core=20
>>>> contributer be compelled to implement a proposal like this. It's up to=
 its=20
>>>> supporters to do so. The real question is, are you willing to work wit=
h and=20
>>>> compromise with people who are looking for a solution like this? Or ar=
e you=20
>>>> 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 <gmax...@gmail.com>=
 wrote:
>>>>
>>>>> > 1) Allowing node
>>>>>
>>>>> Who said anything about allowing?  Everyone is allowed to do whatever=
=20
>>>>> they want.  Drill a hole in your head if you like, not my concern.  N=
one of=20
>>>>> this thread is about what people are allowed to do-- that's off the t=
able. =20
>>>>> The design and licensing of Bitcoin is such that no one gets to stop =
anyone=20
>>>>> else from what they want to do anyways (which is, in fact, a big part=
 of=20
>>>>> the issue here).   To think otherwise is to be stuck in a kind of ser=
f=20
>>>>> thinking where you can only do what other people allow you to do.  Th=
at has=20
>>>>> never been what Bitcoin was about.
>>>>>
>>>>> Rather, the question is should people who care about Bitcoin spend=20
>>>>> their time and money developing infrastructure that would be useful, =
even=20
>>>>> primarily useful, for censorship.  I say no.  Especially because any =
time=20
>>>>> spent on it is time away from anti-censorship pro-privacy tools and b=
ecause=20
>>>>> the effort spent doing so would undermine anti-censorship and pro-pri=
vacy=20
>>>>> efforts because they would inevitably moot the efforts expected getti=
ng=20
>>>>> into peoples business and filtering their transactions.
>>>>>
>>>>> You don't have to agree, and you're free to do your own thing just as=
=20
>>>>> I'm free to say that I think it's a bad direction.  From the very beg=
inning=20
>>>>> Bitcoin has stood against the freedom to transact being overridden by=
=20
>>>>> some admin based on their judgment call weighing principles against o=
ther=20
>>>>> concerns, or at the behest of their superiors.  So many Bitcoiner wil=
l=20
>>>>> stand against, route around, and do what they can do to make ineffect=
ual=20
>>>>> the blocking of consensual transactions.  It might not seem as many a=
t the=20
>>>>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a=
 paid=20
>>>>> PR and influence campaign,  but it also doesn't matter so much becaus=
e=20
>>>>> Bitcoin takes advantage of the nature of information being easy to sp=
read=20
>>>>> and hard to stifel and it doesn't that that huge an effort to route a=
round=20
>>>>> censorship efforts.
>>>>>
>>>>> There are elements of anti-censorship in Bitcoin that have been so fa=
r=20
>>>>> underdeveloped.  It's unfortunate that their further development migh=
t be=20
>>>>> forced at a time when efforts are needed on other areas.  But perhaps=
 they=20
>>>>> wouldn't get done without a concrete motivation. Such is life.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 25, 2025 at 9:21=E2=80=AFAM yes_please <caucasi...@gmail.=
com>=20
>>>>> wrote:
>>>>>
>>>>>> Sorry Greg, could you please elaborate further on your ideas? Some=
=20
>>>>>> are not exactly clear:
>>>>>>
>>>>>> 1) Allowing node runners to configure their node as they please and=
=20
>>>>>> refuse to relay some txs is considered authoritarian, censorship, an=
d an=20
>>>>>> attempt to regulate third parties conduct. On the other hand, forcin=
g nodes=20
>>>>>> to merge towards a single shared configuration (by preventing them t=
o block=20
>>>>>> txs) is not considered authoritarian because this imposition does no=
t=20
>>>>>> discriminate towards any txs and is thus non-authoritarian? Did I ge=
t the=20
>>>>>> reasoning correctly here?
>>>>>>
>>>>>> 2) If the aim is to have a homogenous mempool state and to model=20
>>>>>> what will get mined, shouldn=E2=80=99t we reach this state through d=
istributed=20
>>>>>> independent nodes who decide independently on what they prefer this=
=20
>>>>>> homogenous state to be? If we don=E2=80=99t reach this state through=
 this=20
>>>>>> distributed/independent mechanism, then how are we to reach this sta=
te? Who=20
>>>>>> gets to decide and steer the direction so that we all converge towar=
ds this=20
>>>>>> homogenous state?  One of the strongest aspects of bitcoin is the fa=
ct that=20
>>>>>> no single party can force a change/direction, and the network has to=
=20
>>>>>> somehow reach a shared agreement through independent decision makers=
 who=20
>>>>>> act in what manner they think is best. The proposed BIP seems to be =
aligned=20
>>>>>> with such a principle, I fail to see any authoritarian aspect here.=
=20
>>>>>>
>>>>>> 3) I share your sentiment and the aim to have a homogenous mempool=
=20
>>>>>> state, but I am skeptical of the manner in which we are to achieve t=
his=20
>>>>>> according to the ideas you have here expressed (namely not through a=
=20
>>>>>> distributed independent organic manner)
>>>>>>
>>>>>>
>>>>>> Respectfully, yes_please  =20
>>>>>>
>>>>>> On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell <gmax...@gmail=
.com>=20
>>>>>> wrote:
>>>>>>
>>>>>>> So that when the "consistent state" changes as a result of some=20
>>>>>>> issue you can update configs instead of having to update software--=
 which=20
>>>>>>> has considerable more costs and risks, especially if you're carryin=
g local=20
>>>>>>> customizations as many miners do.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland <m...@drbo=
nez.dev>=20
>>>>>>> wrote:
>>>>>>>
>>>>>>>> If mempool consistency across the network is all that is important=
,=20
>>>>>>>> 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=20
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> This appears to substantially misunderstands the purpose of the=
=20
>>>>>>>>> mempool broadly in the network-- it's purpose is to model what wi=
ll get=20
>>>>>>>>> mined.  If you're not doing that you might as well set blocks onl=
y. =20
>>>>>>>>> Significant discrepancies are harmful to the system and promote=
=20
>>>>>>>>> centralization and fail to achieve a useful purpose in any case. =
 What=20
>>>>>>>>> marginal benefits might be provided do not justify building and d=
eploying=20
>>>>>>>>> the technological infrastructure for massive censorship.
>>>>>>>>>
>>>>>>>>> If you think this is important, I advise you to select another=20
>>>>>>>>> cryptocurrency which is compatible with such authoritarian leanin=
gs.  --=20
>>>>>>>>> though I am unsure if any exist since it is such a transparently =
pointless=20
>>>>>>>>> direction.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@dr=
bonez.dev>=20
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I'd like to share for discussion a draft BIP to allow for a=20
>>>>>>>>>> modular mempool/relay policy:=20
>>>>>>>>>> https://github.com/bitcoin/bips/pull/1985
>>>>>>>>>>
>>>>>>>>>> I think it could potentially reduce conflict within the communit=
y=20
>>>>>>>>>> around relay policy, as an alternative to running lots of differ=
ent node=20
>>>>>>>>>> implementations/forks when there are disagreements.
>>>>>>>>>>
>>>>>>>>>> I am working on a reference implementation using Bellard's=20
>>>>>>>>>> QuickJS, but it has been almost a decade since I've written C++,=
 so it's=20
>>>>>>>>>> slow going and I'm sure doesn't follow best-practices. Once it's=
 working,=20
>>>>>>>>>> it can be cleaned up.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Aiden McClelland
>>>>>>>>>>
>>>>>>>>>> --=20
>>>>>>>>>> You received this message because you are subscribed to the=20
>>>>>>>>>> Google Groups "Bitcoin Development Mailing List" group.
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it=
,=20
>>>>>>>>>> send an email to bitcoindev+...@googlegroups.com.
>>>>>>>>>> To view this discussion visit=20
>>>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-=
80f0-6c68c6554f56n%40googlegroups.com=20
>>>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9=
-80f0-6c68c6554f56n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfoot=
er>
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>> --=20
>>>>>>>> You received this message because you are subscribed to the Google=
=20
>>>>>>>> Groups "Bitcoin Development Mailing List" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,=
=20
>>>>>>>> send an email to bitcoindev+...@googlegroups.com.
>>>>>>>> To view this discussion visit=20
>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a8=
95-b48664babbfcn%40googlegroups.com=20
>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a=
895-b48664babbfcn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter=
>
>>>>>>>> .
>>>>>>>>
>>>>>>> --=20
>>>>>>> You received this message because you are subscribed to the Google=
=20
>>>>>>> Groups "Bitcoin Development Mailing List" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,=
=20
>>>>>>> send an email to bitcoindev+...@googlegroups.com.
>>>>>>> To view this discussion visit=20
>>>>>>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uh=
VrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com=20
>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0u=
hVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com?utm_medium=3Demail&utm_sour=
ce=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/=
4968c87a-ab0a-47a7-9d38-e53fdae1630bn%40googlegroups.com.

------=_Part_85519_174257906.1758936629148
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>Greg,=C2=A0</div><div dir=3D"auto"><br /></div><div dir=3D"auto">You'v=
e made=20
some very compelling points. I really appreciate you taking the time to=20
explain your position, and I sympathize with it. I'm still not sure I=20
agree that there is no compromise here, or that allowing users to set=20
their own relay policy will result in significant censorship of real=20
transactions, but I'm not sure there's a way to prove who's right about=20
that until if/when it happens.=C2=A0</div><div dir=3D"auto"><br /></div><di=
v dir=3D"auto">At
 the end of the day, users must be trusted with the ability to choose=20
what code they want to run, in bitcoin and otherwise. I will, as always,
 do what I can to enable even the less technical among them to be able=20
to do so in the safest way possible. For now this seems to be helping=20
some of them run Knots. If you ever see a path forward for getting these
 users back onto Core, I'm happy to collaborate.=C2=A0</div><div dir=3D"aut=
o"><br /></div><div dir=3D"auto">Best,=C2=A0</div><div dir=3D"auto">Aiden M=
cClelland</div><br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" cla=
ss=3D"gmail_attr">On Thursday, September 25, 2025 at 4:29:36=E2=80=AFPM UTC=
-6 Greg Maxwell wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>&quot;There are levels of survival we are p=
repared to accept.&quot;</div><div><br></div><div>Black and white thinking =
is not very helpful=C2=A0here particularly because the goals of pro-filteri=
ng and anti-censorship aren&#39;t exact opposites.</div><div><br></div><div=
>A widely censored world would greatly degrade the value of Bitcoin,=C2=A0p=
articularly if the censors managed to enlist significant miners.=C2=A0 It w=
ould be routed around at great cost, and with much less freedom provided fo=
r the world.=C2=A0 But just like people continue to buy racy magazines or o=
ther completely lawful targets of operation chokepoint=C2=A0with USD, peopl=
e would still route around Bitcoin censorship.=C2=A0 =C2=A0But why even use=
 Bitcoin if it&#39;s in a similar space of your transactions being capricio=
usly blocks, your funds frozen, etc. as exists with legacy infrastructure?<=
/div><div><br></div><div>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&#39;s well funded (or really exis=
ted a year ago, we are long past the huge spam floods-- they were depleted =
by costs and fizzled as predicted--=C2=A0and Ocean Mining is fighting yeste=
rday&#39;s battle. But what exists exists because its well funded).=C2=A0 M=
eanwhile joe 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=
 potentially targeting him, his activities, or his payees.=C2=A0 The effect=
 of censorship is basically to require people to learn how to be money laun=
derers to freely transact, and those who don&#39;t suffer.</div><div><br></=
div><div>The case is even stronger re: the recently filtering arguments bec=
ause unlike some consensus rule anyone can just mine a block (rent hashpowe=
r, you don&#39;t have to own it) or even more so the stuff like op_return l=
imits have long been bypassed by major miners.=C2=A0 So the policy restrict=
ion was already not working.=C2=A0 =C2=A0So in some sense there are argumen=
ts getting conflated:=C2=A0 The op_return policy limit has already failed.=
=C2=A0 So when people point out that it doesn&#39;t work it&#39;s just a st=
atement 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 filters can be both ineffective and dangerous.=C2=A0 It&#39;s also =
the case that existing filter efforts are not backed by civil litigation or=
 state mandates, but building infrastructure creates an obvious stepping st=
one 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 escal=
ations.=C2=A0 =C2=A0Bitcoin is just better of adopting the position that ot=
her 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, becau=
se the alternative 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"><div dir=3D"lt=
r" class=3D"gmail_attr">On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McCle=
lland &lt;<a href data-email-masked rel=3D"nofollow">m...@drbonez.dev</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"auto"><div>&gt;I have no idea what you&#39;re referring to there.</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">It&#39;s something I inferr=
ed from your primary argument that seems to be that user-configurable filte=
rs are bad because they would cause censorship. But it also sounds like you=
&#39;re saying such filters are completely ineffective at any sort of censo=
rship at all. I don&#39;t really understand how these two viewpoints can co=
exist. 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 McCle=
lland</b></font></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell &l=
t;<a href data-email-masked rel=3D"nofollow">gmax...@gmail.com</a>&gt; wrot=
e:<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"><div dir=3D"l=
tr"><div>I am not a core developer. I have not been for some eight years no=
w.=C2=A0 =C2=A0</div><div><br></div><div>&gt;=C2=A0that you yourself are wo=
rried they will reach the 80% needed</div><div><br></div><div>I have no ide=
a what you&#39;re referring to there.=C2=A0 If lots of people run nodes tha=
t 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 a=
ll nodes are blocking them quite a few years ago ( <a href=3D"https://arxiv=
.org/pdf/1905.10518" rel=3D"noreferrer nofollow" target=3D"_blank" data-saf=
eredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://arxiv.or=
g/pdf/1905.10518&amp;source=3Dgmail&amp;ust=3D1759022911590000&amp;usg=3DAO=
vVaw18L2a9jXK83Pqi4z4QlKhY">https://arxiv.org/pdf/1905.10518</a> ), but dep=
loyment of the implementation has gone slow due to other factors (you know,=
 such as the most experienced=C2=A0developers being hit with billions of do=
llars in lawsuits as a cost for their support of Bitcoin)... I expect if ce=
nsoring actually becomes widespread that technological improvements which f=
urther moot it will be developed.</div><div><br></div><div>These are just v=
ulnerabilities that should be 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 aforementione distractions.</div><div><br></div><div>&gt;=
=C2=A0censorship due to widespread use of transaction filters is a bad thin=
g (I&#39;m not really taking a stance on that right now).</div><div><br></d=
iv><div>I would point you to the history of discussion on Bitcoin starting =
back with Satoshi&#39;s earliest announcements, and perhaps to help you und=
erstand that if you want that what you want isn&#39;t bitcoin.=C2=A0 If aft=
er consideration you don&#39;t think censorship wouldn&#39;t be very bad, t=
hen really you and I have nothing further to discuss.</div><div><br></div><=
div>&gt;=C2=A0are you willing to work with and compromise with people who a=
re 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 rel=3D"noreferrer nofollow" data-email-masked=
>m...@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);p=
adding-left:1ex"><div dir=3D"auto"><div>Greg,=C2=A0</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Let me assume for a minute, for the sake of arg=
ument, that I agree that transaction censorship due to widespread use of tr=
ansaction filters is a bad thing (I&#39;m not really taking a stance on tha=
t right now). It is an irrefutable fact that a very large portion of the us=
er base wants to filter transactions. So many so, that you yourself are wor=
ried they will reach the 80% needed to prevent certain types of transaction=
s from propogating. Wouldn&#39;t it then be <i>worse</i> if these 80% of us=
ers went and ran an alternative implementation, most likely written by it&#=
39;s most radical supporters? Or even worse still, felt compelled to coordi=
nate a UASF to block these transactions entirely?</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">I at no point intended to insinuate that you or a=
ny other core contributer be compelled to implement a proposal like this. I=
t&#39;s up to its supporters to do so. The real question is, are you willin=
g to work with and compromise with people who are looking for a solution li=
ke this? Or are you going to force them to abandon the Core project entirel=
y?</div><div><br></div><div dir=3D"auto">Best,</div><div><font face=3D"cour=
ier new, monospace"><b>Aiden McClelland</b></font></div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25, 202=
5, 2:03=E2=80=AFPM Greg Maxwell &lt;<a href rel=3D"noreferrer noreferrer no=
follow" data-email-masked>gmax...@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x 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</spa=
n></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 whateve=
r they want.=C2=A0 Drill a hole in your head if you like, not my concern.=
=C2=A0 None of this thread is about what people are allowed to do-- that&#3=
9;s off the table.=C2=A0 The design and licensing of Bitcoin is such that n=
o one gets to stop anyone else from what they=C2=A0want to do anyways (whic=
h is, in fact, a big part of the issue here).=C2=A0 =C2=A0To think otherwis=
e is to be stuck in a kind of serf thinking where you can only do what othe=
r 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 t=
heir time and money developing infrastructure that would be useful, even pr=
imarily useful, for censorship.=C2=A0 I say no.=C2=A0 Especially because an=
y time spent on it is time away from anti-censorship pro-privacy tools and =
because the effort spent doing so would undermine anti-censorship and pro-p=
rivacy efforts because they would inevitably=C2=A0moot the efforts=C2=A0exp=
ected getting into peoples business and 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 F=
rom the very beginning Bitcoin has stood against the freedom to transact be=
ing=C2=A0</span>overridden by some admin based on their judgment call weigh=
ing principles against other concerns, or at the behest of their superiors.=
=C2=A0 So many Bitcoiner will stand against, route around, and do what they=
 can do to make ineffectual the blocking of consensual=C2=A0transactions.=
=C2=A0 It might not seem as many at the moment, but the pro-privacy and ant=
i-censorship &#39;side&#39; doesn&#39;t have a paid PR and influence campai=
gn,=C2=A0 but it also doesn&#39;t matter so much because Bitcoin takes adva=
ntage of the nature of information being easy to spread and hard to stifel =
and it doesn&#39;t that that huge an effort to route around censorship effo=
rts.</div><div><br></div><div>There are elements of anti-censorship in Bitc=
oin that have been so far underdeveloped.=C2=A0 It&#39;s unfortunate that t=
heir further development might be forced at a time when efforts are needed =
on other areas.=C2=A0 But perhaps they wouldn&#39;t get done without a conc=
rete motivation. Such is life.</div><div><br></div><div><span lang=3D"EN-US=
"><br></span></div><div><span lang=3D"EN-US"><br></span></div><div><span la=
ng=3D"EN-US"><br></span></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25, 2025 at 9:21=E2=80=AFAM yes_p=
lease &lt;<a href rel=3D"noreferrer noreferrer noreferrer nofollow" data-em=
ail-masked>caucasi...@gmail.com</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"ltr"><p style=3D"color:rgba(23=
2,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;f=
ont-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"co=
lor:rgba(232,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,s=
ans-serif;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 re=
fuse to relay some txs is considered authoritarian, censorship, and an atte=
mpt to regulate third parties conduct. On the other hand, forcing nodes to =
merge towards a single shared configuration (by preventing them to block tx=
s) is not considered authoritarian because this imposition does not discrim=
inate towards any txs and is thus non-authoritarian? Did I get the reasonin=
g correctly here?</span></p><p style=3D"color:rgba(232,230,227,0.87);font-f=
amily:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span l=
ang=3D"EN-US">2) I</span><span>f the aim is to have a homogenous mempool st=
ate and to model what will get mined, shouldn=E2=80=99t we reach this state=
 through distributed independent nodes who decide=C2=A0independently on wha=
t they prefer this homogenous state to be? If we don=E2=80=99t reach this s=
tate through this distributed/independent mechanism, then how are we to rea=
ch this state? Who gets to decide and steer the direction so that we all co=
nverge towards 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 network has to somehow reach a shared agreement through independent de=
cision makers who act in what manner they think is best. The proposed BIP s=
eems to be aligned with such a principle, I fail to see any authoritarian a=
spect here.=C2=A0</span></p><p style=3D"color:rgba(232,230,227,0.87);font-f=
amily:Roboto,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 according to the ideas you have here expressed (namely not through a =
distributed independent organic manner)</span></p><p style=3D"color:rgba(23=
2,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;f=
ont-size:14px"><span lang=3D"EN-US"><br></span></p><p style=3D"color:rgba(2=
32,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;=
font-size:14px"><span lang=3D"EN-US">Respectfully, yes_please=C2=A0=C2=A0=
=C2=A0</span></p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell &lt;=
<a href rel=3D"noreferrer noreferrer noreferrer nofollow" data-email-masked=
>gmax...@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(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div>So that when the &quot;consistent s=
tate&quot; changes as a result of some issue you can update configs instead=
 of having to update software-- which has considerable more costs and risks=
, especially if you&#39;re carrying local customizations as many 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 Aiden McClella=
nd &lt;<a href rel=3D"noreferrer noreferrer noreferrer nofollow" data-email=
-masked>m...@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 across the network is all th=
at is important, why allow any configuration of mempool relay policies at a=
ll?<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 Maxwel=
l 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"><div di=
r=3D"ltr"><div>This appears to substantially=C2=A0misunderstands the purpos=
e 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 doing that you might as well set b=
locks only.=C2=A0 Significant=C2=A0discrepancies=C2=A0are harmful to the sy=
stem and promote centralization=C2=A0and fail to achieve a useful purpose i=
n any case.=C2=A0 What marginal benefits might 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 importan=
t, I advise you to select another cryptocurrency which is compatible with s=
uch authoritarian=C2=A0leanings.=C2=A0 -- though I am unsure if any exist s=
ince it is such a transparently pointless direction.</div><div><br></div></=
div><br><div class=3D"gmail_quote"></div><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aide=
n McClelland &lt;<a rel=3D"nofollow noreferrer noreferrer noreferrer">m...@=
drbonez.dev</a>&gt; wrote:<br></div></div><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div>Hi all,</div><div><br></di=
v><div>I&#39;d like to share for discussion a draft BIP to allow for a modu=
lar mempool/relay policy: <a href=3D"https://github.com/bitcoin/bips/pull/1=
985" rel=3D"nofollow noreferrer noreferrer noreferrer" target=3D"_blank" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gi=
thub.com/bitcoin/bips/pull/1985&amp;source=3Dgmail&amp;ust=3D17590229115910=
00&amp;usg=3DAOvVaw2sAdud--SMZDaEO7tcKmma">https://github.com/bitcoin/bips/=
pull/1985</a><br><br></div><div>I think it could potentially reduce conflic=
t within the community around relay policy, as an alternative to running lo=
ts of different node implementations/forks when there are disagreements.</d=
iv><div><br></div><div>I am working on a reference implementation using Bel=
lard&#39;s QuickJS, 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-practi=
ces. Once it&#39;s working, it can be cleaned up.</div><div><br></div><div>=
Thanks,</div><div>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" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/cbdab6fa=
-93bc-44c9-80f0-6c68c6554f56n%2540googlegroups.com?utm_medium%3Demail%26utm=
_source%3Dfooter&amp;source=3Dgmail&amp;ust=3D1759022911591000&amp;usg=3DAO=
vVaw1FQPPBepz_GLoIpM2Ck2ZP">https://groups.google.com/d/msgid/bitcoindev/cb=
dab6fa-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 rel=3D"noreferrer noreferrer noreferrer nofollow" data-emai=
l-masked>bitcoindev+...@googlegroups.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 nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/de4dae19=
-86f4-4d7a-a895-b48664babbfcn%2540googlegroups.com?utm_medium%3Demail%26utm=
_source%3Dfooter&amp;source=3Dgmail&amp;ust=3D1759022911591000&amp;usg=3DAO=
vVaw05coZpiV1dX42IY6BGkU8B">https://groups.google.com/d/msgid/bitcoindev/de=
4dae19-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 rel=3D"noreferrer noreferrer noreferrer nofollow" data-emai=
l-masked>bitcoindev+...@googlegroups.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 nofollow" target=3D"_blank" data-saferedirecturl=3D"https://w=
ww.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoin=
dev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%2540mail.gmail.com?=
utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgmail&amp;ust=3D17590=
22911591000&amp;usg=3DAOvVaw3yBV0IFecB0suXHBmjn0jP">https://groups.google.c=
om/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%4=
0mail.gmail.com</a>.<br>
</blockquote></div>
</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/4968c87a-ab0a-47a7-9d38-e53fdae1630bn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/4968c87a-ab0a-47a7-9d38-e53fdae1630bn%40googlegroups.com</a>.<br />

------=_Part_85519_174257906.1758936629148--

------=_Part_85518_1014478515.1758936629148--