Delivery-date: Thu, 25 Sep 2025 14:29:41 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) client-ip=2607:f8b0:4864:20::630;
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>
In-Reply-To: <CAPDT2SRyVY4rh=HegG+kk5nnDf6qzYuRkUyxCC8iE-ydsh63ew@mail.gmail.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Thu, 25 Sep 2025 20:03:09 +0000
Message-ID: <CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
To: yes_please <caucasianjazz12@gmail.com>
Cc: Aiden McClelland <me@drbonez.dev>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000041896e063fa5a994"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

> 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 table.  The
design and licensing of Bitcoin is such that no one gets to stop anyone
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 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-privacy
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 other
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 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 spread
and hard to stifel and it doesn't that that huge an effort to route around
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@gmail.c=
om>
wrote:

> Sorry Greg, could you please elaborate further on your ideas? Some are no=
t
> 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 nod=
es
> to merge towards a single shared configuration (by preventing them to blo=
ck
> 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 distributed
> 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 state? W=
ho
> gets to decide and steer the direction so that we all converge towards th=
is
> homogenous state?  One of the strongest aspects of bitcoin is the fact th=
at
> 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 align=
ed
> 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 accordin=
g
> 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 issue yo=
u
>> can update configs instead of having to update software-- which has
>> 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.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 Maxw=
ell wrote:
>>>
>>>> This appears to substantially misunderstands the purpose of the mempoo=
l
>>>> 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.  What
>>>> marginal benefits might be provided do not justify building and deploy=
ing
>>>> 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 point=
less
>>>> direction.
>>>>
>>>>
>>>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@drbonez=
.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 n=
ode
>>>>> 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 Google
>>>>> Groups "Bitcoin Development Mailing List" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d
>>>>> an email to bitcoindev+...@googlegroups.com.
>>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-=
6c68c6554f56n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0=
-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, send
>>> an email to bitcoindev+unsubscribe@googlegroups.com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-b4=
8664babbfcn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-b=
48664babbfcn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQ=
nL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDi=
QnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com?utm_medium=3Demail&utm_source=3D=
footer>
>> .
>>
>

--=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/=
CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w%40mail.gmail.com.

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

<div dir=3D"ltr"><div>&gt;=C2=A0<span lang=3D"EN-US">1)=C2=A0</span><span l=
ang=3D"EN-US">Allowing node</span></div><div><span lang=3D"EN-US"><br></spa=
n></div><div><span lang=3D"EN-US">Who said anything about allowing?=C2=A0 E=
veryone is allowed to do whatever they want.=C2=A0 Drill a hole in your hea=
d if you like, not my concern.=C2=A0 None of this thread is about what peop=
le are allowed to do-- that&#39;s off the table.=C2=A0 The design and licen=
sing of Bitcoin is such that no one gets to stop anyone else from what they=
=C2=A0want to do anyways (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 w=
here you can only do what other people allow you to do.=C2=A0 That has neve=
r 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 infrastructure=
 that would be useful, even primarily useful, for censorship.=C2=A0 I say n=
o.=C2=A0 Especially because any time spent on it is time away from anti-cen=
sorship pro-privacy tools and because the effort spent doing so would under=
mine anti-censorship and pro-privacy efforts because they would inevitably=
=C2=A0moot the efforts=C2=A0expected getting into peoples business and filt=
ering 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 stood aga=
inst the freedom to transact being=C2=A0</span>overridden by some admin bas=
ed 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=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 matter so mu=
ch because Bitcoin takes 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 censorship efforts.</div><div><br></div><div>There are elemen=
ts of anti-censorship in Bitcoin that have been so far underdeveloped.=C2=
=A0 It&#39;s unfortunate that their further development might be forced at =
a time when efforts are needed on other areas.=C2=A0 But perhaps they would=
n&#39;t get done without 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 gmail_quote_container"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Thu, Sep 25, 2025 at 9:21=E2=80=AFAM yes_please &lt;<a href=3D"m=
ailto:caucasianjazz12@gmail.com">caucasianjazz12@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">=
<p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDraft,Hel=
vetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-US">Sorry Greg, co=
uld 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,Robo=
toDraft,Helvetica,Arial,sans-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 refuse to relay some txs is considered authoritaria=
n, censorship, and an attempt to regulate third parties conduct. On the oth=
er hand, forcing nodes to merge towards a single shared configuration (by p=
reventing them to block txs) is not considered authoritarian because this i=
mposition does not discriminate towards any txs and is thus non-authoritari=
an? Did I get the reasoning correctly here?</span></p><p style=3D"color:rgb=
a(232,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-ser=
if;font-size:14px"><span lang=3D"EN-US">2) I</span><span>f the aim is to ha=
ve a homogenous mempool state and to model what will get mined, shouldn=E2=
=80=99t we reach this state through distributed independent nodes who decid=
e=C2=A0independently on what they prefer this homogenous state to be? If we=
 don=E2=80=99t reach this state through this distributed/independent mechan=
ism, 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 can fo=
rce a change/direction, and the network has to somehow reach a shared agree=
ment through independent decision makers 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 here.=C2=A0</span></p><p style=3D"color:rg=
ba(232,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-se=
rif;font-size:14px"><span>3)=C2=A0</span><span>I share your sentiment and t=
he 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 expre=
ssed (namely not through a distributed independent organic manner)</span></=
p><p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDraft,H=
elvetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-US"><br></span><=
/p><p style=3D"color:rgba(232,230,227,0.87);font-family:Roboto,RobotoDraft,=
Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"EN-US">Respectfull=
y, yes_please=C2=A0=C2=A0=C2=A0</span></p></div><br><div class=3D"gmail_quo=
te"><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" target=3D"_=
blank">gmaxwell@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"><div>So that when the &quot;consi=
stent state&quot; changes as a result of some issue you can update configs =
instead of having to update software-- which has considerable more costs an=
d risks, especially if you&#39;re carrying local customizations as many min=
ers 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" target=3D"_blank">me@drbo=
nez.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-lef=
t:1ex">If mempool consistency across the network is all that is important, =
why allow any configuration of mempool relay policies at all?<br><br><div c=
lass=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Wednesday, S=
eptember 24, 2025 at 12:47:28=E2=80=AFPM UTC-6 Greg Maxwell 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>Th=
is 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 promo=
te centralization=C2=A0and fail to achieve a useful purpose in any case.=C2=
=A0 What marginal benefits might be provided do not justify=C2=A0building a=
nd deploying the technological=C2=A0infrastructure=C2=A0for massive censors=
hip.</div><div><br></div><div>If you think this is important, I advise you =
to select another cryptocurrency which is compatible with such authoritaria=
n=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 cla=
ss=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 &l=
t;<a rel=3D"nofollow">m...@drbonez.dev</a>&gt; wrote:<br></div></div><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
>Hi all,</div><div><br></div><div>I&#39;d like to share for discussion a dr=
aft BIP to allow for a modular mempool/relay policy: <a href=3D"https://git=
hub.com/bitcoin/bips/pull/1985" rel=3D"nofollow" target=3D"_blank">https://=
github.com/bitcoin/bips/pull/1985</a><br><br></div><div>I think it could po=
tentially reduce conflict within the community around relay policy, as an a=
lternative to running lots of different node implementations/forks when the=
re 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 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><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">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" target=3D"_blank">htt=
ps://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554=
f56n%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" 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" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegrou=
ps.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" 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" target=3D"_blank">https://=
groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzf=
sJ7w4GztWVeNA%40mail.gmail.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">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w%40mail.g=
mail.com</a>.<br />

--00000000000041896e063fa5a994--