Delivery-date: Thu, 25 Sep 2025 14:27:33 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62c as permitted sender) client-ip=2607:f8b0:4864:20::62c;
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>
In-Reply-To: <CAOSz24TJU-4Q76MtzL+oYYFpXQvrOay5XtdrR0DxVBUAFz=5og@mail.gmail.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Thu, 25 Sep 2025 21:14:11 +0000
Message-ID: <CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ@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="0000000000003ade04063fa6a7f8"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

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 the
technical concepts required to get nearly 100% tx coverage even if almost
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 are
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 understand
that if you want that what you want isn't bitcoin.  If after consideration
you don't think censorship wouldn't be very bad, then really you and I have
nothing further to discuss.

> 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

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 exact 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 with 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 goal is to destroy
Bitcoin Core.  So what's the compromise there?

> Or even worse still, felt compelled to coordinate a UASF to block these
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 to
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 paramount.

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 wants-- an
outspoken influence campaign is not necessarily all that reflective of 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> w=
rote:

> 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 filt=
er
> transactions. So many so, that you yourself are worried they will reach t=
he
> 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 contribute=
r
> 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 compromi=
se
> 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> w=
rote:
>
>> > 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.  None=
 of
>> this thread is about what people are allowed to do-- that's off the tabl=
e.
>> The design and licensing of Bitcoin is such that no one gets to stop any=
one
>> 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.  That =
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, even
>> primarily useful, for censorship.  I say no.  Especially because any tim=
e
>> spent on it is time away from anti-censorship pro-privacy tools and beca=
use
>> the effort spent doing so would undermine anti-censorship and pro-privac=
y
>> efforts because they would inevitably moot the efforts expected getting
>> 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 beginning
>> Bitcoin has stood against the freedom to transact being overridden by
>> some admin based on their judgment call weighing principles against othe=
r
>> concerns, or at the behest of their superiors.  So many Bitcoiner will
>> stand against, route around, and do what they can do to make ineffectual
>> the blocking of consensual transactions.  It might not seem as many at t=
he
>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a pa=
id
>> PR and influence campaign,  but it also doesn't matter so much because
>> Bitcoin takes advantage of the nature of information being easy to sprea=
d
>> and hard to stifel and it doesn't that that huge an effort to route arou=
nd
>> censorship efforts.
>>
>> There are elements of anti-censorship in Bitcoin that have been so far
>> underdeveloped.  It's unfortunate that their further development might b=
e
>> forced at a time when efforts are needed on other areas.  But perhaps th=
ey
>> 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@gmai=
l.com>
>> wrote:
>>
>>> Sorry Greg, could you please elaborate further on your ideas? Some are
>>> 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 a=
n
>>> attempt to regulate third parties conduct. On the other hand, forcing n=
odes
>>> to merge towards a single shared configuration (by preventing them to b=
lock
>>> txs) is not considered authoritarian because this imposition does not
>>> discriminate towards any txs and is thus non-authoritarian? Did I get t=
he
>>> 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 distribut=
ed
>>> independent nodes who decide independently on what they prefer this
>>> homogenous state to be? If we don=E2=80=99t reach this state through th=
is
>>> distributed/independent mechanism, then how are we to reach this state?=
 Who
>>> gets to decide and steer the direction so that we all converge towards =
this
>>> homogenous state?  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 decision makers wh=
o
>>> act in what manner they think is best. The proposed BIP seems to be ali=
gned
>>> 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 this
>>> 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.c=
om>
>>> wrote:
>>>
>>>> So that when the "consistent state" changes as a result of some issue
>>>> you can update configs instead of having to update software-- which ha=
s
>>>> considerable more costs and risks, especially if you're carrying local
>>>> customizations as many miners do.
>>>>
>>>>
>>>> On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland <me@drbonez.d=
ev>
>>>> 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 Ma=
xwell
>>>>> wrote:
>>>>>
>>>>>> This appears to substantially misunderstands the purpose of the
>>>>>> mempool broadly in the network-- it's purpose is to model what will =
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.  Wh=
at
>>>>>> marginal benefits might be provided do not justify building and depl=
oying
>>>>>> 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 leanings.=
  --
>>>>>> though I am unsure if any exist since it is such a transparently poi=
ntless
>>>>>> direction.
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@drbon=
ez.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 different=
 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 slo=
w going
>>>>>>> and I'm sure doesn't follow best-practices. Once it's working, it c=
an be
>>>>>>> cleaned up.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Aiden McClelland
>>>>>>>
>>>>>>> --
>>>>>>> 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+...@googlegroups.com.
>>>>>>> To view this discussion visit
>>>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f=
0-6c68c6554f56n%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80=
f0-6c68c6554f56n%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, sen=
d
>>>>> an email to bitcoindev+unsubscribe@googlegroups.com.
>>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-=
b48664babbfcn%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895=
-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/CAAS2fgRABqRe1j6xzW0uhVrD=
iQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVr=
DiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter>
>>>> .
>>>>
>>>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div>I am not a core developer. I have not been for some e=
ight years now.=C2=A0 =C2=A0</div><div><br></div><div>&gt;=C2=A0that you yo=
urself 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 people =
run nodes that screw up propagation they&#39;ll be routed around.=C2=A0 I d=
eveloped the technical concepts required to get nearly 100% tx coverage eve=
n if almost all nodes are blocking them quite a few years ago ( <a href=3D"=
https://arxiv.org/pdf/1905.10518">https://arxiv.org/pdf/1905.10518</a> ), b=
ut deployment of the implementation has gone slow due to other factors (you=
 know, such as the most experienced=C2=A0developers 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 w=
hich further moot it will be developed.</div><div><br></div><div>These are =
just vulnerabilities that should be closed anyways-- after all anyone at an=
y time can just spin up any number of &quot;nodes&quot; that behave in arbi=
trary=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><di=
v>&gt;=C2=A0censorship due to widespread use of transaction filters is a ba=
d 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 sta=
rting back with Satoshi&#39;s earliest announcements, and perhaps to help y=
ou understand that if you want that 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 nothing further to discuss.</div><div><br><=
/div><div>&gt;=C2=A0are you willing 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 gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25, 2=
025 at 8:51=E2=80=AFPM Aiden McClelland &lt;<a href=3D"mailto:me@drbonez.de=
v">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);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=3D"mailto:gmaxwell@gmail.com" r=
el=3D"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;bor=
der-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">Allowin=
g node</span></div><div><span lang=3D"EN-US"><br></span></div><div><span la=
ng=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 what people are allowed to do-=
- that&#39;s off the table.=C2=A0 The design and licensing of Bitcoin is su=
ch that no one gets to stop anyone else from what they=C2=A0want to do anyw=
ays (which is, in fact, a big part of the issue here).=C2=A0 =C2=A0To think=
 otherwise is to be stuck in a kind of serf thinking where you can only do =
what other people allow you to do.=C2=A0 That has never been what Bitcoin w=
as 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 Bitcoi=
n spend their time and money developing infrastructure that would be useful=
, even primarily useful, for censorship.=C2=A0 I say no.=C2=A0 Especially b=
ecause any time spent on it is time away from anti-censorship pro-privacy t=
ools and because the effort spent doing so would undermine anti-censorship =
and pro-privacy efforts because they would inevitably=C2=A0moot the efforts=
=C2=A0expected getting into peoples business and filtering their transactio=
ns.</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=A0directio=
n.=C2=A0 From the very beginning Bitcoin has stood against the freedom to t=
ransact being=C2=A0</span>overridden by some admin based on their judgment =
call weighing 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=A0trans=
actions.=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 influenc=
e campaign,=C2=A0 but it also doesn&#39;t matter so much because Bitcoin ta=
kes advantage 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 censors=
hip efforts.</div><div><br></div><div>There are elements of anti-censorship=
 in Bitcoin that have been so far underdeveloped.=C2=A0 It&#39;s unfortunat=
e that their 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 withou=
t a concrete 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 lang=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_please &lt;<a href=3D"mailto:caucasianjazz12@gmail.com" rel=3D"no=
referrer noreferrer" target=3D"_blank">caucasianjazz12@gmail.com</a>&gt; wr=
ote:<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"><p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDra=
ft,Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-US">Sorry Gr=
eg, 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:Robot=
o,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-U=
S">1)=C2=A0</span><span lang=3D"EN-US">Allowing node runners to configure t=
heir node as they please and refuse to relay some txs is considered authori=
tarian, censorship, and an attempt to regulate third parties conduct. On th=
e other hand, forcing nodes to merge towards a single shared configuration =
(by preventing them to block txs) is not considered authoritarian because t=
his imposition does not discriminate towards any txs and is thus non-author=
itarian? Did I get the reasoning correctly here?</span></p><p style=3D"colo=
r:rgba(232,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,san=
s-serif;font-size:14px"><span lang=3D"EN-US">2) I</span><span>f the aim is =
to have a homogenous mempool state and to model what will get mined, should=
n=E2=80=99t we reach this state through distributed independent nodes who d=
ecide=C2=A0independently on what they prefer this homogenous state to be? I=
f we don=E2=80=99t reach this state through this distributed/independent me=
chanism, then how are we to reach this state? Who gets to decide and steer =
the direction so that we all converge towards this homogenous state?=C2=A0 =
One of the strongest aspects of bitcoin is the fact that no single party ca=
n force a change/direction, and the network has to somehow reach a shared a=
greement through independent decision makers who act in what manner they th=
ink is best. The proposed BIP seems to be aligned with such a principle, I =
fail to see any authoritarian aspect here.=C2=A0</span></p><p style=3D"colo=
r:rgba(232,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,san=
s-serif;font-size:14px"><span>3)=C2=A0</span><span>I share your sentiment a=
nd the aim to have a homogenous mempool state, but I am skeptical of the ma=
nner in which we are to achieve this according to the ideas you have here e=
xpressed (namely not through a distributed independent organic manner)</spa=
n></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDra=
ft,Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-US"><br></sp=
an></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDr=
aft,Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-US">Respect=
fully, yes_please=C2=A0=C2=A0=C2=A0</span></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"n=
oreferrer noreferrer" target=3D"_blank">gmaxwell@gmail.com</a>&gt; wrote:<b=
r></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 state&quot; changes as a result of s=
ome issue you can update configs instead of having to update software-- whi=
ch 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 McClelland &lt;<a href=3D"mailto:me@drbonez=
.dev" rel=3D"noreferrer 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 memp=
ool consistency across 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, 2=
025 at 12:47:28=E2=80=AFPM UTC-6 Greg Maxwell wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><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 doing that you might as well set blocks only.=C2=A0 Significant=
=C2=A0discrepancies=C2=A0are harmful to the system and promote centralizati=
on=C2=A0and fail to achieve a useful purpose in any case.=C2=A0 What margin=
al benefits might be provided do not justify=C2=A0building and deploying th=
e technological=C2=A0infrastructure=C2=A0for massive censorship.</div><div>=
<br></div><div>If you think this is important, I advise you to select anoth=
er cryptocurrency which is compatible with such authoritarian=C2=A0leanings=
.=C2=A0 -- though I am unsure if any exist since it is such a transparently=
 pointless direction.</div><div><br></div></div><br><div class=3D"gmail_quo=
te"></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"nofo=
llow noreferrer noreferrer">m...@drbonez.dev</a>&gt; wrote:<br></div></div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div>Hi all,</div><div><br></div><div>I&#39;d like to share for discussio=
n a draft BIP to allow for a modular mempool/relay policy: <a href=3D"https=
://github.com/bitcoin/bips/pull/1985" rel=3D"nofollow noreferrer noreferrer=
" target=3D"_blank">https://github.com/bitcoin/bips/pull/1985</a><br><br></=
div><div>I think it could potentially reduce conflict within the community =
around relay policy, as an alternative to running lots of different node im=
plementations/forks when there are disagreements.</div><div><br></div><div>=
I am working on a reference implementation using Bellard&#39;s QuickJS, but=
 it has been almost a decade since I&#39;ve written C++, so it&#39;s slow g=
oing and I&#39;m sure doesn&#39;t follow best-practices. Once it&#39;s work=
ing, 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">bitcoindev+...@googlegrou=
ps.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"=
 target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93=
bc-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" target=3D"_blank">bitcoindev+unsubscribe@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" 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" target=3D"_blank">bitcoindev+unsubscribe@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" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/CAAS2fgR=
ABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com</a>.<br>
</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/CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ%40mail.g=
mail.com</a>.<br />

--0000000000003ade04063fa6a7f8--