Delivery-date: Thu, 25 Sep 2025 15:29:41 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of gagglehoof@gmail.com designates 209.85.218.42 as permitted sender) client-ip=209.85.218.42;
MIME-Version: 1.0
References: <cbdab6fa-93bc-44c9-80f0-6c68c6554f56n@googlegroups.com>
 <CAAS2fgRFP+BJUZR7h01=7=qamD5qEW6OYJikTMR=5RkxTCEMZg@mail.gmail.com>
 <de4dae19-86f4-4d7a-a895-b48664babbfcn@googlegroups.com> <CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA@mail.gmail.com>
 <CAPDT2SRyVY4rh=HegG+kk5nnDf6qzYuRkUyxCC8iE-ydsh63ew@mail.gmail.com>
 <CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w@mail.gmail.com>
 <CAOSz24TJU-4Q76MtzL+oYYFpXQvrOay5XtdrR0DxVBUAFz=5og@mail.gmail.com> <CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ@mail.gmail.com>
In-Reply-To: <CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ@mail.gmail.com>
From: Aiden McClelland <me@drbonez.dev>
Date: Thu, 25 Sep 2025 15:25:46 -0600
Message-ID: <CAOSz24SdZeV=1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: yes_please <caucasianjazz12@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000b5074f063fa6d00f"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

>I have no idea what you're referring to there.

It's something I inferred from your primary argument that seems to be that
user-configurable filters are bad because they would cause censorship. But
it also sounds like you're saying such filters are completely ineffective
at any sort of censorship at all. I don't really understand how these two
viewpoints can coexist. What am I missing here?

Best,
*Aiden McClelland*

On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> wro=
te:

> 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 th=
e
> 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 ar=
e
> 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 consideratio=
n
> you don't think censorship wouldn't be very bad, then really you and I ha=
ve
> 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 wi=
th
> 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 goa=
l
> 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>=
 wrote:
>
>> Greg,
>>
>> Let me assume for a minute, for the sake of argument, that I agree that
>> transaction censorship due to widespread use of transaction filters is a
>> bad thing (I'm not really taking a stance on that right now). It is an
>> irrefutable fact that a very large portion of the user base wants to fil=
ter
>> transactions. So many so, that you yourself are worried they will reach =
the
>> 80% needed to prevent certain types of transactions from propogating.
>> Wouldn't it then be *worse* if these 80% of users went and ran an
>> alternative implementation, most likely written by it's most radical
>> supporters? Or even worse still, felt compelled to coordinate a UASF to
>> block these transactions entirely?
>>
>> I at no point intended to insinuate that you or any other core
>> contributer be compelled to implement a proposal like this. It's up to i=
ts
>> supporters to do so. The real question is, are you willing to work with =
and
>> compromise with people who are looking for a solution like this? Or are =
you
>> going to force them to abandon the Core project entirely?
>>
>> Best,
>> *Aiden McClelland*
>>
>> On Thu, Sep 25, 2025, 2:03=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> =
wrote:
>>
>>> > 1) Allowing node
>>>
>>> Who said anything about allowing?  Everyone is allowed to do whatever
>>> they want.  Drill a hole in your head if you like, not my concern.  Non=
e of
>>> this thread is about what people are allowed to do-- that's off the tab=
le.
>>> The design and licensing of Bitcoin is such that no one gets to stop an=
yone
>>> else from what they want to do anyways (which is, in fact, a big part o=
f
>>> 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 thei=
r
>>> time and money developing infrastructure that would be useful, even
>>> primarily useful, for censorship.  I say no.  Especially because any ti=
me
>>> spent on it is time away from anti-censorship pro-privacy tools and bec=
ause
>>> the effort spent doing so would undermine anti-censorship and pro-priva=
cy
>>> 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 begin=
ning
>>> Bitcoin has stood against the freedom to transact being overridden by
>>> some admin based on their judgment call weighing principles against oth=
er
>>> concerns, or at the behest of their superiors.  So many Bitcoiner will
>>> stand against, route around, and do what they can do to make ineffectua=
l
>>> 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 p=
aid
>>> PR and influence campaign,  but it also doesn't matter so much because
>>> Bitcoin takes advantage of the nature of information being easy to spre=
ad
>>> and hard to stifel and it doesn't that that huge an effort to route aro=
und
>>> 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 t=
hey
>>> 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@gma=
il.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 =
an
>>>> attempt to regulate third parties conduct. On the other hand, forcing =
nodes
>>>> to merge towards a single shared configuration (by preventing them to =
block
>>>> txs) is not considered authoritarian because this imposition does not
>>>> discriminate towards any txs and is thus non-authoritarian? Did I get =
the
>>>> reasoning correctly here?
>>>>
>>>> 2) If the aim is to have a homogenous mempool state and to model what
>>>> will get mined, shouldn=E2=80=99t we reach this state through distribu=
ted
>>>> independent nodes who decide independently on what they prefer this
>>>> homogenous state to be? If we don=E2=80=99t reach this state through t=
his
>>>> 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 w=
ho
>>>> act in what manner they think is best. The proposed BIP seems to be al=
igned
>>>> 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 thi=
s
>>>> according to the ideas you have here expressed (namely not through a
>>>> distributed independent organic manner)
>>>>
>>>>
>>>> Respectfully, yes_please
>>>>
>>>> On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell <gmaxwell@gmail.=
com>
>>>> wrote:
>>>>
>>>>> So that when the "consistent state" changes as a result of some issue
>>>>> you can update configs instead of having to update software-- which h=
as
>>>>> considerable more costs and risks, especially if you're carrying loca=
l
>>>>> 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 M=
axwell
>>>>>> 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.  W=
hat
>>>>>>> marginal benefits might be provided do not justify building and dep=
loying
>>>>>>> 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 po=
intless
>>>>>>> direction.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@drbo=
nez.dev>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I'd like to share for discussion a draft BIP to allow for a modula=
r
>>>>>>>> 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 differen=
t 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 sl=
ow 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-80=
f0-6c68c6554f56n%40googlegroups.com
>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-8=
0f0-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=
-b48664babbfcn%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a89=
5-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, sen=
d
>>>>> an email to bitcoindev+unsubscribe@googlegroups.com.
>>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVr=
DiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhV=
rDiQnL6x1X6ALzfsJ7w4GztWVeNA%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/=
CAOSz24SdZeV%3D1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg%40mail.gmail.com.

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

<div dir=3D"auto"><div>&gt;I have no idea what you&#39;re referring to ther=
e.</div><div dir=3D"auto"><br></div><div dir=3D"auto">It&#39;s something I =
inferred from your primary argument that seems to be that user-configurable=
 filters are bad because they would cause censorship. But it also sounds li=
ke you&#39;re saying such filters are completely ineffective at any sort of=
 censorship at all. I don&#39;t really understand how these two viewpoints =
can coexist. What am I missing here?</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Best,</div><div data-smartmail=3D"gmail_signature"><font face=
=3D"courier new, monospace"><b>Aiden McClelland</b></font></div></div><br><=
div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g=
mail_attr">On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell &lt;<a href=
=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I am=
 not a core developer. I have not been for some eight years now.=C2=A0 =C2=
=A0</div><div><br></div><div>&gt;=C2=A0that you yourself are worried they w=
ill 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 p=
ropagation they&#39;ll be routed around.=C2=A0 I developed the technical co=
ncepts required to get nearly 100% tx coverage even if almost all nodes are=
 blocking them quite a few years ago ( <a href=3D"https://arxiv.org/pdf/190=
5.10518" target=3D"_blank" rel=3D"noreferrer">https://arxiv.org/pdf/1905.10=
518</a> ), but deployment of the implementation has gone slow due to other =
factors (you know, such as the most experienced=C2=A0developers being hit w=
ith billions of dollars in lawsuits as a cost for their support of Bitcoin)=
... I expect if censoring actually becomes widespread that technological im=
provements which further moot it will be developed.</div><div><br></div><di=
v>These are just vulnerabilities that should be closed anyways-- after all =
anyone at any time can just spin up any number of &quot;nodes&quot; that be=
have in arbitrary=C2=A0ways, at ant time.=C2=A0 It&#39;s been a lower prior=
ity because there are other countermeasures (addnode-a-friend, manually set=
banning=C2=A0bad peers, etc.) and aforementione distractions.</div><div><br=
></div><div>&gt;=C2=A0censorship due to widespread use of transaction filte=
rs is a bad thing (I&#39;m not really taking a stance on that right now).</=
div><div><br></div><div>I would point you to the history of discussion on B=
itcoin starting back with Satoshi&#39;s earliest announcements, and perhaps=
 to help you understand that if you want that what you want isn&#39;t bitco=
in.=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 w=
ith people who are looking=20
for a solution like this? Or are you going to force them to abandon the=20
Core project entirely</div><div><br></div><div>I don&#39;t really think the=
re is any space to compromise with people who think it&#39;s okay to add ce=
nsorship to Bitcoin-- I mean sure whatever exact relay policy there is ther=
e is plenty of tradeoffs but from the start of this new filter debate the f=
ilter proponents have immediately come out with vile insults accusing devel=
opers of promoting child sexual abuse and shitcoins and what not----=C2=A0 =
that isn&#39;t some attempt to navigate a technical/political trademark, it=
&#39;s an effort to villify and destory the opposition.=C2=A0 =C2=A0And una=
mbiguously=C2=A0so as luke has said outright that his goal is to destroy Bi=
tcoin Core.=C2=A0 So what&#39;s the compromise there?=C2=A0=C2=A0</div><div=
><br></div><div>&gt;=C2=A0Or even worse still, felt compelled to coordinate=
 a UASF to block these transactions entirely?</div><div><br></div><div>I ve=
ry much think people should do that-- they should actually make some consen=
sus rules for their filters to fork off and we can see what the market thin=
ks.=C2=A0 -- And also even if the market prefers censored Bitcoin, that&#39=
;s also fine with me, in the sense in my view Bitcoin was created to be mon=
ey as largely free from human judgement as possible.=C2=A0 When it was crea=
ted most of the world was doing something else and didn&#39;t know they nee=
ded freedom money.=C2=A0 If it&#39;s still the case that most of the world =
doesn&#39;t want freedom money that would be no shock. They should be free =
to have what they want and people who want freedom money should be free to =
have what they want.=C2=A0 I got into bitcoin before it was worth practical=
ly anything because of the freedom it provides, and I think that&#39;s para=
mount.</div><div><br></div><div>Perhaps you should consider why they *don&#=
39;t* do that?=C2=A0 I&#39;d say it&#39;s because (1) it won&#39;t work, an=
d (2) it&#39;s not actually what the world wants-- an outspoken influence c=
ampaign is not necessarily all that reflective of much of anything.=C2=A0 P=
articularly given how inaccurate and emotionally pandering the filter advoc=
acy has been.=C2=A0 =C2=A0But, hey, I&#39;ve been wrong before.=C2=A0=C2=A0=
</div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25, 2025 at 8:51=E2=80=AFPM=
 Aiden McClelland &lt;<a href=3D"mailto:me@drbonez.dev" target=3D"_blank" r=
el=3D"noreferrer">me@drbonez.dev</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"auto"><div>Greg,=C2=A0</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Let me assume for a minute, for=
 the sake of argument, that I agree that transaction censorship due to wide=
spread use of transaction filters is a bad thing (I&#39;m not really taking=
 a stance on that right now). It is an irrefutable fact that a very large p=
ortion of the user base wants to filter transactions. So many so, that you =
yourself are worried they will reach the 80% needed to prevent certain type=
s of transactions from propogating. Wouldn&#39;t it then be <i>worse</i> if=
 these 80% of users went and ran an alternative implementation, most likely=
 written by it&#39;s most radical supporters? Or even worse still, felt com=
pelled to coordinate a UASF to block these transactions entirely?</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">I at no point intended to insinua=
te that you or any other core contributer be compelled to implement a propo=
sal like this. It&#39;s up to its supporters to do so. The real question is=
, are you willing to work with and compromise with people who are looking f=
or a solution like this? Or are you going to force them to abandon the Core=
 project entirely?</div><div><br></div><div dir=3D"auto">Best,</div><div><f=
ont face=3D"courier new, monospace"><b>Aiden McClelland</b></font></div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Thu, Sep 25, 2025, 2:03=E2=80=AFPM Greg Maxwell &lt;<a href=3D"mailto:gmaxw=
ell@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">gmaxwell@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div>&gt;=C2=A0<span lang=3D"EN-US">1)=C2=A0</span><=
span lang=3D"EN-US">Allowing node</span></div><div><span lang=3D"EN-US"><br=
></span></div><div><span lang=3D"EN-US">Who said anything about allowing?=
=C2=A0 Everyone is allowed to do whatever they want.=C2=A0 Drill a hole in =
your head if you like, not my concern.=C2=A0 None of this thread is about w=
hat people are allowed to do-- that&#39;s off the table.=C2=A0 The design a=
nd licensing of Bitcoin is such that no one gets to stop anyone else from w=
hat they=C2=A0want to do anyways (which is, in fact, a big part of the issu=
e here).=C2=A0 =C2=A0To think otherwise is to be stuck in a kind of serf th=
inking where you can only do what other people allow you to do.=C2=A0 That =
has never been what Bitcoin was about.</span></div><div><span lang=3D"EN-US=
"><br></span></div><div><span lang=3D"EN-US">Rather, the question is should=
 people who care about Bitcoin spend their time and money developing infras=
tructure that would be useful, even primarily useful, for censorship.=C2=A0=
 I say no.=C2=A0 Especially because any time spent on it is time away from =
anti-censorship pro-privacy tools and because the effort spent doing so wou=
ld undermine anti-censorship and pro-privacy efforts because they would ine=
vitably=C2=A0moot the efforts=C2=A0expected getting into peoples business a=
nd filtering their transactions.</span></div><div><span lang=3D"EN-US"><br>=
</span></div><div><span lang=3D"EN-US">You don&#39;t have to agree, and you=
&#39;re free to do your own thing just as I&#39;m free to say that I think =
it&#39;s a bad=C2=A0direction.=C2=A0 From the very beginning Bitcoin has st=
ood against the freedom to transact being=C2=A0</span>overridden by some ad=
min based on their judgment call weighing principles against other concerns=
, or at the behest of their superiors.=C2=A0 So many Bitcoiner will stand a=
gainst, route around, and do what they can do to make ineffectual the block=
ing of consensual=C2=A0transactions.=C2=A0 It might not seem as many at the=
 moment, but the pro-privacy and anti-censorship &#39;side&#39; doesn&#39;t=
 have a paid PR and influence campaign,=C2=A0 but it also doesn&#39;t matte=
r so much because Bitcoin takes advantage of the nature of information bein=
g easy to spread and hard to stifel and it doesn&#39;t that that huge an ef=
fort to route around censorship efforts.</div><div><br></div><div>There are=
 elements of anti-censorship in Bitcoin that have been so far underdevelope=
d.=C2=A0 It&#39;s unfortunate that their further development might be force=
d at a time when efforts are needed on other areas.=C2=A0 But perhaps they =
wouldn&#39;t get done without a concrete motivation. Such is life.</div><di=
v><br></div><div><span lang=3D"EN-US"><br></span></div><div><span lang=3D"E=
N-US"><br></span></div><div><span lang=3D"EN-US"><br></span></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, S=
ep 25, 2025 at 9:21=E2=80=AFAM yes_please &lt;<a href=3D"mailto:caucasianja=
zz12@gmail.com" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">=
caucasianjazz12@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><p style=3D"color:rgba(232,230,22=
7,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size=
:14px"><span lang=3D"EN-US">Sorry Greg, could you please elaborate further =
on your ideas? Some are not exactly clear:</span></p><p style=3D"color:rgba=
(232,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-seri=
f;font-size:14px"><span lang=3D"EN-US">1)=C2=A0</span><span lang=3D"EN-US">=
Allowing node runners to configure their node as they please and refuse to =
relay some txs is considered authoritarian, censorship, and an attempt to r=
egulate third parties conduct. On the other hand, forcing nodes to merge to=
wards a single shared configuration (by preventing them to block txs) is no=
t considered authoritarian because this imposition does not discriminate to=
wards any txs and is thus non-authoritarian? Did I get the reasoning correc=
tly here?</span></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Ro=
boto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span lang=3D"E=
N-US">2) I</span><span>f the aim is to have a homogenous mempool state and =
to model what will get mined, shouldn=E2=80=99t we reach this state through=
 distributed independent nodes who decide=C2=A0independently on what they p=
refer this homogenous state to be? If we don=E2=80=99t reach this state thr=
ough this distributed/independent mechanism, then how are we to reach this =
state? Who gets to decide and steer the direction so that we all converge t=
owards this homogenous state?=C2=A0 One of the strongest aspects of bitcoin=
 is the fact that no single party can force a change/direction, and the net=
work has to somehow reach a shared agreement through independent decision m=
akers who act in what manner they think is best. The proposed BIP seems to =
be aligned with such a principle, I fail to see any authoritarian aspect he=
re.=C2=A0</span></p><p style=3D"color:rgba(232,230,227,0.87);font-family:Ro=
boto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span>3)=C2=A0<=
/span><span>I share your sentiment and the aim to have a homogenous mempool=
 state, but I am skeptical of the manner in which we are to achieve this ac=
cording to the ideas you have here expressed (namely not through a distribu=
ted independent organic manner)</span></p><p style=3D"color:rgba(232,230,22=
7,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size=
:14px"><span lang=3D"EN-US"><br></span></p><p style=3D"color:rgba(232,230,2=
27,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-siz=
e:14px"><span lang=3D"EN-US">Respectfully, yes_please=C2=A0=C2=A0=C2=A0</sp=
an></p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell &lt;<a href=3D=
"mailto:gmaxwell@gmail.com" rel=3D"noreferrer noreferrer noreferrer" target=
=3D"_blank">gmaxwell@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>So that when the &quot;=
consistent state&quot; changes as a result of some issue you can update con=
figs instead of having to update software-- which has considerable more cos=
ts and risks, especially if you&#39;re carrying local customizations as man=
y miners do.</div><div><br></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Ai=
den McClelland &lt;<a href=3D"mailto:me@drbonez.dev" rel=3D"noreferrer nore=
ferrer noreferrer" target=3D"_blank">me@drbonez.dev</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">If mempool consistency a=
cross the network is all that is important, why allow any configuration of =
mempool relay policies at all?<br><br><div class=3D"gmail_quote"><div dir=
=3D"auto" class=3D"gmail_attr">On Wednesday, September 24, 2025 at 12:47:28=
=E2=80=AFPM UTC-6 Greg Maxwell wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>This appears to substantially=
=C2=A0misunderstands the purpose of the mempool broadly in the network-- it=
&#39;s purpose is to model what will get mined.=C2=A0 If you&#39;re not doi=
ng that you might as well set blocks only.=C2=A0 Significant=C2=A0discrepan=
cies=C2=A0are harmful to the system and promote centralization=C2=A0and fai=
l to achieve a useful purpose in any case.=C2=A0 What marginal benefits mig=
ht be provided do not justify=C2=A0building and deploying the technological=
=C2=A0infrastructure=C2=A0for massive censorship.</div><div><br></div><div>=
If you think this is important, I advise you to select another cryptocurren=
cy which is compatible with such authoritarian=C2=A0leanings.=C2=A0 -- thou=
gh I am unsure if any exist since it is such a transparently pointless dire=
ction.</div><div><br></div></div><br><div class=3D"gmail_quote"></div><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 24,=
 2025 at 6:30=E2=80=AFPM Aiden McClelland &lt;<a rel=3D"nofollow noreferrer=
 noreferrer noreferrer">m...@drbonez.dev</a>&gt; wrote:<br></div></div><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv>Hi all,</div><div><br></div><div>I&#39;d like to share for discussion a =
draft BIP to allow for a modular mempool/relay policy: <a href=3D"https://g=
ithub.com/bitcoin/bips/pull/1985" rel=3D"nofollow noreferrer noreferrer nor=
eferrer" target=3D"_blank">https://github.com/bitcoin/bips/pull/1985</a><br=
><br></div><div>I think it could potentially reduce conflict within the com=
munity around relay policy, as an alternative to running lots of different =
node implementations/forks when there are disagreements.</div><div><br></di=
v><div>I am working on a reference implementation using Bellard&#39;s Quick=
JS, but it has been almost a decade since I&#39;ve written C++, so it&#39;s=
 slow going and I&#39;m sure doesn&#39;t follow best-practices. Once it&#39=
;s working, it can be cleaned up.</div><div><br></div><div>Thanks,</div><di=
v>Aiden McClelland<br></div>

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

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow noreferrer noreferrer noreferrer">bitcoindev+...=
@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow noreferrer noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/=
cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer noreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@g=
ooglegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer noreferre=
r" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/de4dae19-=
86f4-4d7a-a895-b48664babbfcn%40googlegroups.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer noreferrer noreferrer" target=3D"_blank">bitcoindev+unsubscribe@g=
ooglegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail=
.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferr=
er noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoind=
ev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com</a>=
.<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>

<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/CAOSz24SdZeV%3D1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAOSz24SdZeV%3D1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg%40ma=
il.gmail.com</a>.<br />

--000000000000b5074f063fa6d00f--