Delivery-date: Thu, 25 Sep 2025 14:26:40 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::82a as permitted sender) client-ip=2607:f8b0:4864:20::82a;
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>
In-Reply-To: <CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA@mail.gmail.com>
From: Chris Guida <chrisguida@gmail.com>
Date: Thu, 25 Sep 2025 11:52:02 -0600
Message-ID: <CAAANnUxBTRzE1PLe9oJU_ukmp3a_y799W_7Ez4rOUOYPhdu26A@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Aiden McClelland <me@drbonez.dev>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000004a6611063fa3d407"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

Hi Greg -

I think it's worth pointing out that "just update configs instead of having
to update software" is exactly what this BIP is proposing, and it takes
this idea a step further by giving users the ability to update their filter
software without having to update their bitcoin node software.

For miners wanting to add customizations, a modular system like the one in
the BIP proposal is clearly a better experience than having to edit
hardcoded filters in bitcoind.

You seem to be arguing that miners should be able to change their local
policies but that non-mining nodes should have to update their policies to
match what miners are using, is that correct?

I don't see a problem with letting users relay (or refuse to relay)
whatever transactions they like. If a transaction format is not commonly
filtered, it will most likely get confirmed. Conversely, if a supermajority
of nodes filters it, it will probably not be confirmed. I very much doubt
that a supermajority of nodes would agree to filter something harmless. But
even if they do, there is always direct miner submission (additional work
is required to support small miners), so censorship is very unlikely.

As for your comments on "distributed authoritarianism"... it just seems
like you're saying "everyone might agree to do something core devs don't
want them to do, so we can't allow that". But perhaps I misunderstood?

Anyway, forcing users to relay transactions they consider abusive if they
want to relay any transactions at all does not seem in keeping with
bitcoin's ethos, not to mention that it obviously would never work.

Best regards,

--Chris Guida

On Wed, Sep 24, 2025 at 4:50=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> w=
rote:

> So that when the "consistent state" 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'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 Maxwe=
ll 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.  What
>>> marginal benefits might be provided do not justify building and deployi=
ng
>>> 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 pointl=
ess
>>> 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 no=
de
>>>> implementations/forks when there are disagreements.
>>>>
>>>> I am working on a reference implementation using Bellard's QuickJS, bu=
t
>>>> 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, send
>>>> an email to bitcoindev+...@googlegroups.com.
>>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6=
c68c6554f56n%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 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/de4dae19-86f4-4d7a-a895-b48=
664babbfcn%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-b4=
8664babbfcn%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/CAAS2fgRABqRe1j6xzW0uhVrDiQn=
L6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQ=
nL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter>
> .
>

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

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

<div dir=3D"ltr"><div>Hi Greg -</div><div><br></div><div>I think it&#39;s w=
orth pointing out that &quot;just update configs instead of having to updat=
e software&quot; is exactly what this BIP is proposing, and it takes this i=
dea a step further by giving users the ability to update their filter softw=
are without having to update their bitcoin node software.</div><div><br></d=
iv><div>For miners wanting to add customizations, a modular system like the=
 one in the BIP proposal is clearly a better experience than having to edit=
 hardcoded filters in bitcoind.</div><div><br></div><div>You seem to be arg=
uing that miners should be able to change their local policies but that non=
-mining nodes should have to update their policies to match what miners are=
 using, is that correct?</div><div><br></div><div>I don&#39;t see a problem=
 with letting users relay (or refuse to relay) whatever=20
transactions they like. If a transaction format is not commonly=20
filtered, it will most likely get confirmed. Conversely, if a=20
supermajority of nodes filters it, it will probably not be confirmed. I=20
very much doubt that a supermajority of nodes would agree to filter=20
something harmless. But even if they do, there is always direct miner=20
submission (additional work is required to support small miners), so censor=
ship is very unlikely.</div><div><br></div><div>As for your comments on &qu=
ot;distributed authoritarianism&quot;... it just seems like you&#39;re sayi=
ng &quot;everyone might agree to do something core devs don&#39;t want them=
 to do, so we can&#39;t allow that&quot;. But perhaps I misunderstood?</div=
><div><br></div><div>Anyway, forcing users to relay transactions they consi=
der abusive if they want to relay any transactions at all does not seem in =
keeping with bitcoin&#39;s ethos, not to mention that it obviously would ne=
ver work.<br></div><div><br></div><div>Best regards,</div><div><br></div><d=
iv>--Chris Guida<br></div></div><br><div class=3D"gmail_quote gmail_quote_c=
ontainer"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 24, 2025 at 4:5=
0=E2=80=AFPM Greg Maxwell &lt;<a href=3D"mailto:gmaxwell@gmail.com">gmaxwel=
l@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 state&qu=
ot; changes as a result of some issue you can update configs instead of hav=
ing to update software-- which has considerable more costs and risks, espec=
ially 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 &l=
t;<a href=3D"mailto:me@drbonez.dev" 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">m...@drbonez.dev</a>&gt; wrote:<br></div></div><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi all,</div><d=
iv><br></div><div>I&#39;d like to share for discussion a draft BIP to allow=
 for a modular mempool/relay policy: <a href=3D"https://github.com/bitcoin/=
bips/pull/1985" rel=3D"nofollow" target=3D"_blank">https://github.com/bitco=
in/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 ru=
nning lots of different node implementations/forks when there are disagreem=
ents.</div><div><br></div><div>I am working on a reference implementation u=
sing 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 bes=
t-practices. Once it&#39;s working, it can be cleaned up.</div><div><br></d=
iv><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>

<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/CAAANnUxBTRzE1PLe9oJU_ukmp3a_y799W_7Ez4rOUOYPhdu26A%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAAANnUxBTRzE1PLe9oJU_ukmp3a_y799W_7Ez4rOUOYPhdu26A%40mail.g=
mail.com</a>.<br />

--0000000000004a6611063fa3d407--