Delivery-date: Thu, 25 Sep 2025 19:47:11 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::233 as permitted sender) client-ip=2a00:1450:4864:20::233;
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>
 <CAOSz24SdZeV=1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg@mail.gmail.com>
 <CAAS2fgSXX5_TU86r=QOQAvg84tpRa7o9ha5=En3tPmTUBrrqhw@mail.gmail.com>
 <CAL5BAw2E2nupsgrZE6z2T2Fd4VWnF-NvPOZXXaOtbOLHSTWi-g@mail.gmail.com> <CAOSz24SZ9x_c=3eXY0McxQbivbG5zHOfTiaZjR+=uAju4+pC3Q@mail.gmail.com>
In-Reply-To: <CAOSz24SZ9x_c=3eXY0McxQbivbG5zHOfTiaZjR+=uAju4+pC3Q@mail.gmail.com>
From: Chris Riley <criley@gmail.com>
Date: Thu, 25 Sep 2025 22:28:28 -0400
Message-ID: <CAL5BAw2RYHkUj4iREYL+Nca_CYP-BwLB5pZg3xY8=4-sf0ompg@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
To: Aiden McClelland <me@drbonez.dev>
Cc: Greg Maxwell <gmaxwell@gmail.com>, yes_please <caucasianjazz12@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000002a0c63063fab0b8e"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

Hi,
I'd think things like propagation effectiveness (e.g. if your filters are
too different from everyone else's, you won't relay what others will and
your own transactions may fail to propagate), convenience (e.g. most people
are going to just pick a pack of filters vs picking ones so you'll have a
handful of curated packages of filters), miner incentives (e.g. if a large
miner picks on those preferences could trickle down), reputation and
liability fears (e.g. if you are an outlier you may worry about accusations
of relaying "bad" transactions so you'd be pressured to standardize with
regulated entities, and network effects so that your not in the divergent
mempool.  Would it be a feedback loop?  Maybe,   There probably are others
too, but that was just a quick thought.  :-)

On Thu, Sep 25, 2025 at 10:17=E2=80=AFPM Aiden McClelland <me@drbonez.dev> =
wrote:

> Chris,
>
> Can you elaborate further on what economic incentives there would be
> towards filter standardization?
>
> Thanks,
> *Aiden McClelland*
>
> On Thu, Sep 25, 2025, 8:06=E2=80=AFPM Chris Riley <criley@gmail.com> wrot=
e:
>
>> One concern is that even if filter scripts are local and opt-in
>> initially, social or economic pressure will push them toward
>> "standardization"=E2=80=94and from there toward implicit coercion=E2=80=
=94so the risk of
>> soft censorship increases over time. If relay policies start drifting, t=
he
>> mempool ceases to reflect miner behavior and fragments into incompatible
>> local views, undermining its role as a shared substrate. Instead of
>> decentralizing control, filter modules may simply externalize it: those =
who
>> author =E2=80=9Cpopular=E2=80=9D (perhaps through demagoguery) filters g=
ain outsized
>> influence over what the rest see. The path to robustness is not more pol=
icy
>> layers, but maintaining a minimal, common relay system.
>>
>> On Thu, Sep 25, 2025 at 6:29=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com=
> wrote:
>>
>>> "There are levels of survival we are prepared to accept."
>>>
>>> Black and white thinking is not very helpful here particularly because
>>> the goals of pro-filtering and anti-censorship aren't exact opposites.
>>>
>>> A widely censored world would greatly degrade the value of
>>> Bitcoin, particularly if the censors managed to enlist significant mine=
rs.
>>> It would be routed around at great cost, and with much less freedom
>>> provided for the world.  But just like people continue to buy racy
>>> magazines or other completely lawful targets of operation chokepoint wi=
th
>>> USD, people would still route around Bitcoin censorship.   But why even=
 use
>>> Bitcoin if it's in a similar space of your transactions being capriciou=
sly
>>> blocks, your funds frozen, etc. as exists with legacy infrastructure?
>>>
>>> But the irony is that the traffic that people most desperately want to
>>> stop would be among the least impeded-- already today the spam traffic
>>> exists at all because it's well funded (or really existed a year ago, w=
e
>>> are long past the huge spam floods-- they were depleted by costs and
>>> fizzled as predicted-- and Ocean Mining is fighting yesterday's battle.=
 But
>>> what exists exists because its well funded).  Meanwhile joe blow sendin=
g
>>> funds p2p to friends or family in far off places doesn't have the funds=
 or
>>> technical acumen to deal with censorship potentially targeting him, his
>>> activities, or his payees.  The effect of censorship is basically to
>>> require people to learn how to be money launderers to freely transact, =
and
>>> those who don't suffer.
>>>
>>> The case is even stronger re: the recently filtering arguments because
>>> unlike some consensus rule anyone can just mine a block (rent hashpower=
,
>>> you don't have to own it) or even more so the stuff like op_return limi=
ts
>>> have long been bypassed by major miners.  So the policy restriction was
>>> already not working.   So in some sense there are arguments getting
>>> conflated:  The op_return policy limit has already failed.  So when peo=
ple
>>> point out that it doesn't work it's just a statement of fact rather tha=
n
>>> speculation.  But basically the 'bad' traffic has a lot easier time tha=
n
>>> more innocent traffic, which is part of why filters can be both ineffec=
tive
>>> and dangerous.  It's also the case that existing filter efforts are not
>>> backed by civil litigation or state mandates, but building infrastructu=
re
>>> creates an obvious stepping stone to that (in part because of the
>>> insufficient effectiveness of filtering)-- it's just a bad road that wi=
ll
>>> almost inevitably lead to more escalations.   Bitcoin is just better of
>>> adopting the position that other people's transactions aren't our busin=
ess,
>>> even if they're stupid or drive fees up a bit for some periods and crea=
te
>>> annoyances, because the alternative is easily much worse.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McClelland <me@drbonez.de=
v> wrote:
>>>
>>>> >I have no idea what you're referring to there.
>>>>
>>>> It's something I inferred from your primary argument that seems to be
>>>> that user-configurable filters are bad because they would cause censor=
ship.
>>>> But it also sounds like you're saying such filters are completely
>>>> ineffective at any sort of censorship at all. I don't really understan=
d 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=
> wrote:
>>>>
>>>>> 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 develope=
d the
>>>>> technical concepts required to get nearly 100% tx coverage even if al=
most
>>>>> 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 law=
suits
>>>>> as a cost for their support of Bitcoin)... I expect if censoring actu=
ally
>>>>> 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 be=
have
>>>>> in arbitrary ways, at ant time.  It's been a lower priority because t=
here
>>>>> 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 aft=
er
>>>>> consideration you don't think censorship wouldn't be very bad, then r=
eally
>>>>> 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 a=
bandon
>>>>> 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 e=
xact
>>>>> relay policy there is there is plenty of tradeoffs but from the start=
 of
>>>>> this new filter debate the filter proponents have immediately come ou=
t 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 wha=
t the
>>>>> market thinks.  -- And also even if the market prefers censored Bitco=
in,
>>>>> 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 th=
ey
>>>>> 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 fre=
e 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 practica=
lly
>>>>> anything because of the freedom it provides, and I think that's param=
ount.
>>>>>
>>>>> 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 w=
ants--
>>>>> an outspoken influence campaign is not necessarily all that reflectiv=
e 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 fil=
ters is
>>>>>> a bad thing (I'm not really taking a stance on that right now). It i=
s an
>>>>>> irrefutable fact that a very large portion of the user base wants to=
 filter
>>>>>> transactions. So many so, that you yourself are worried they will re=
ach 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 its
>>>>>> supporters to do so. The real question is, are you willing to work w=
ith 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.c=
om>
>>>>>> 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.  None of this thread is about what people are allowed to d=
o--
>>>>>>> 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 (whi=
ch 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 an=
y time
>>>>>>> spent on it is time away from anti-censorship pro-privacy tools and=
 because
>>>>>>> the effort spent doing so would undermine anti-censorship and pro-p=
rivacy
>>>>>>> efforts because they would inevitably moot the efforts expected get=
ting
>>>>>>> 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 ver=
y
>>>>>>> beginning Bitcoin has stood against the freedom to transact being o=
verridden
>>>>>>> by some admin based on their judgment call weighing principles agai=
nst
>>>>>>> other concerns, or at the behest of their superiors.  So many Bitco=
iner
>>>>>>> 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 t=
o route
>>>>>>> around censorship efforts.
>>>>>>>
>>>>>>> There are elements of anti-censorship in Bitcoin that have been so
>>>>>>> far underdeveloped.  It's unfortunate that their further developmen=
t might
>>>>>>> be forced at a time when efforts are needed on other areas.  But pe=
rhaps
>>>>>>> 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.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, censorsh=
ip, and
>>>>>>>> an attempt to regulate third parties conduct. On the other hand, f=
orcing
>>>>>>>> nodes to merge towards a single shared configuration (by preventin=
g 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=
 distributed
>>>>>>>> independent nodes who decide independently on what they prefer thi=
s
>>>>>>>> homogenous state to be? If we don=E2=80=99t reach this state throu=
gh this
>>>>>>>> distributed/independent mechanism, then how are we to reach this s=
tate? Who
>>>>>>>> gets to decide and steer the direction so that we all converge tow=
ards 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 make=
rs who
>>>>>>>> act in what manner they think is best. The proposed BIP seems to b=
e aligned
>>>>>>>> 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@gm=
ail.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
>>>>>>>>> has considerable more costs and risks, especially if you're carry=
ing local
>>>>>>>>> customizations as many miners do.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland <me@drbo=
nez.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 Gr=
eg
>>>>>>>>>> Maxwell 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 o=
nly.
>>>>>>>>>>> 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=
 deploying
>>>>>>>>>>> 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 lean=
ings.  --
>>>>>>>>>>> though I am unsure if any exist since it is such a transparentl=
y pointless
>>>>>>>>>>> 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 lo=
ts of
>>>>>>>>>>>> different node implementations/forks when there are disagreeme=
nts.
>>>>>>>>>>>>
>>>>>>>>>>>> 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, send an email to bitcoindev+...@googlegroups.com.
>>>>>>>>>>>> To view this discussion visit
>>>>>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c=
9-80f0-6c68c6554f56n%40googlegroups.com
>>>>>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44=
c9-80f0-6c68c6554f56n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> 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=
-a895-b48664babbfcn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfoot=
er>
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Googl=
e
>>>>>>>>> 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/CAAS2fgRABqRe1j6xzW0=
uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
>>>>>>>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW=
0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com?utm_medium=3Demail&utm_so=
urce=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/CAAS2fgSXX5_TU86r%3DQOQAvg=
84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAv=
g84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com?utm_medium=3Demail&utm_sour=
ce=3Dfooter>
>>> .
>>>
>>

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

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

<div dir=3D"ltr">Hi,<div>I&#39;d think things like propagation=C2=A0effecti=
veness (e.g. if your filters are too different from everyone else&#39;s, yo=
u won&#39;t relay what others will and your own transactions may fail to pr=
opagate), convenience (e.g. most people are going to just pick a pack of fi=
lters vs picking ones so you&#39;ll have a handful of curated packages of f=
ilters), miner incentives (e.g. if a large miner picks on those preferences=
 could trickle down), reputation and liability fears (e.g. if you are an ou=
tlier you may worry about accusations of relaying &quot;bad&quot; transacti=
ons so you&#39;d be pressured to standardize with regulated entities, and n=
etwork effects so that your not in the divergent mempool.=C2=A0 Would it be=
 a feedback loop?=C2=A0 Maybe, =C2=A0 There probably are others too, but th=
at was just a quick thought. =C2=A0:-)=C2=A0</div></div><br><div class=3D"g=
mail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On =
Thu, Sep 25, 2025 at 10:17=E2=80=AFPM Aiden McClelland &lt;<a href=3D"mailt=
o:me@drbonez.dev">me@drbonez.dev</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"auto"><div>Chris,=C2=A0</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Can you elaborate further on what economic incentives there wou=
ld be towards filter standardization?</div><div><br></div><div dir=3D"auto"=
>Thanks,</div><div><font face=3D"courier new, monospace"><b>Aiden McClellan=
d</b></font></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Thu, Sep 25, 2025, 8:06=E2=80=AFPM Chris Riley &lt;<a =
href=3D"mailto:criley@gmail.com" target=3D"_blank">criley@gmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr">One concern is that even=
 if filter scripts are local and opt-in initially, social or economic press=
ure will push them toward &quot;standardization&quot;=E2=80=94and from ther=
e toward implicit coercion=E2=80=94so the risk of soft censorship increases=
 over time. If relay policies start drifting, the mempool ceases to reflect=
 miner behavior and fragments into incompatible local views, undermining it=
s role as a shared substrate. Instead of decentralizing control, filter mod=
ules may simply externalize it: those who author =E2=80=9Cpopular=E2=80=9D =
(perhaps through demagoguery) filters gain outsized influence over what the=
 rest see. The path to robustness is not more policy layers, but maintainin=
g a minimal, common relay system.<div><div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 25, 2025 at 6:29=E2=80=AFP=
M Greg Maxwell &lt;<a href=3D"mailto:gmaxwell@gmail.com" rel=3D"noreferrer"=
 target=3D"_blank">gmaxwell@gmail.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>&quot;There are levels of survival we are prepare=
d to accept.&quot;</div><div><br></div><div>Black and white thinking is not=
 very helpful=C2=A0here particularly because the goals of pro-filtering and=
 anti-censorship aren&#39;t exact opposites.</div><div><br></div><div>A wid=
ely censored world would greatly degrade the value of Bitcoin,=C2=A0particu=
larly if the censors managed to enlist significant miners.=C2=A0 It would b=
e routed around at great cost, and with much less freedom provided for the =
world.=C2=A0 But just like people continue to buy racy magazines or other c=
ompletely lawful targets of operation chokepoint=C2=A0with USD, people woul=
d still route around Bitcoin censorship.=C2=A0 =C2=A0But why even use Bitco=
in if it&#39;s in a similar space of your transactions being capriciously b=
locks, your funds frozen, etc. as exists with legacy infrastructure?</div><=
div><br></div><div>But the irony is that the traffic that people most despe=
rately want to stop would be among the least impeded-- already today the sp=
am traffic exists at all because it&#39;s well funded (or really existed a =
year ago, we are long past the huge spam floods-- they were depleted by cos=
ts and fizzled as predicted--=C2=A0and Ocean Mining is fighting yesterday&#=
39;s battle. But what exists exists because its well funded).=C2=A0 Meanwhi=
le joe blow sending funds p2p to friends or family in far off places doesn&=
#39;t have the funds or technical acumen=C2=A0to deal with censorship poten=
tially targeting him, his activities, or his payees.=C2=A0 The effect of ce=
nsorship is basically to require people to learn how to be money launderers=
 to freely transact, and those who don&#39;t suffer.</div><div><br></div><d=
iv>The case is even stronger re: the recently filtering arguments because u=
nlike some consensus rule anyone can just mine a block (rent hashpower, you=
 don&#39;t have to own it) or even more so the stuff like op_return limits =
have long been bypassed by major miners.=C2=A0 So the policy restriction wa=
s already not working.=C2=A0 =C2=A0So in some sense there are arguments get=
ting conflated:=C2=A0 The op_return policy limit has already failed.=C2=A0 =
So when people point out that it doesn&#39;t work it&#39;s just a statement=
 of fact rather than speculation.=C2=A0 But basically the &#39;bad&#39; tra=
ffic has a lot easier time than more innocent traffic, which is part of why=
 filters can be both ineffective and dangerous.=C2=A0 It&#39;s also the cas=
e that existing filter efforts are not backed by civil litigation or state =
mandates, but building infrastructure creates an obvious stepping stone to =
that (in part because of the insufficient effectiveness of filtering)-- it&=
#39;s just a bad road that will almost inevitably lead to more escalations.=
=C2=A0 =C2=A0Bitcoin is just better of adopting the position that other peo=
ple&#39;s transactions aren&#39;t our business, even if they&#39;re stupid =
or drive fees up a bit for some periods and create annoyances, because the =
alternative is easily much worse.</div><div><br></div><div><br></div><div><=
br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><=
br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><=
br></div><div><br></div><div>=C2=A0=C2=A0</div><div><br></div><div><br></di=
v><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McClelland &=
lt;<a href=3D"mailto:me@drbonez.dev" rel=3D"noreferrer" target=3D"_blank">m=
e@drbonez.dev</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><d=
iv>&gt;I have no idea what you&#39;re referring to there.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">It&#39;s something I inferred from your p=
rimary argument that seems to be that user-configurable filters are bad bec=
ause they would cause censorship. But it also sounds like 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><font face=3D"courier new, monospace"><b>Aiden McClelland</b></fon=
t></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell &lt;<a href=3D"m=
ailto:gmaxwell@gmail.com" rel=3D"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-width:1px;border-left-style:solid;borde=
r-left-color: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" rel=3D"noreferrer noreferrer" target=3D"_blank">https://arxiv.org/=
pdf/1905.10518</a> ), but deployment of the implementation has gone slow du=
e 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 techn=
ological improvements which further moot it will be developed.</div><div><b=
r></div><div>These are just vulnerabilities that should be closed anyways--=
 after all anyone at any time can just spin up any number of &quot;nodes&qu=
ot; that behave in arbitrary=C2=A0ways, at ant time.=C2=A0 It&#39;s been a =
lower priority because there are other countermeasures (addnode-a-friend, m=
anually setbanning=C2=A0bad peers, etc.) and aforementione distractions.</d=
iv><div><br></div><div>&gt;=C2=A0censorship due to widespread use of transa=
ction filters is a bad thing (I&#39;m not really taking a stance on that ri=
ght now).</div><div><br></div><div>I would point you to the history of disc=
ussion on Bitcoin 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 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 dis=
cuss.</div><div><br></div><div>&gt;=C2=A0are you willing to work with and c=
ompromise 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"><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" rel=3D"noreferrer n=
oreferrer" target=3D"_blank">me@drbonez.dev</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"auto"><div>Greg,=C2=A0</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Let me assume for a minute, for the sake of argument, =
that I agree that transaction censorship due to widespread use of transacti=
on 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 portion of the user base=
 wants to filter transactions. So many so, that you yourself are worried th=
ey will reach the 80% needed to prevent certain types of transactions from =
propogating. Wouldn&#39;t it then be <i>worse</i> if these 80% of users wen=
t and ran an alternative implementation, most likely written by it&#39;s mo=
st radical supporters? Or even worse still, felt compelled 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 insinuate that you or any othe=
r core contributer be compelled to implement a proposal like this. It&#39;s=
 up to its supporters to do so. The real question is, are you willing to wo=
rk 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?</div=
><div><br></div><div dir=3D"auto">Best,</div><div><font face=3D"courier new=
, monospace"><b>Aiden McClelland</b></font></div></div><br><div class=3D"gm=
ail_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:gmaxwell@gmail.com" rel=3D"n=
oreferrer noreferrer noreferrer" target=3D"_blank">gmaxwell@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>&gt;=C2=A0<span l=
ang=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 s=
aid 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 No=
ne of this thread is about what people are allowed to do-- that&#39;s off t=
he table.=C2=A0 The design and licensing of Bitcoin is such that no one get=
s 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 b=
e 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 was about.</span></=
div><div><span lang=3D"EN-US"><br></span></div><div><span lang=3D"EN-US">Ra=
ther, the question is should people who care about Bitcoin spend their time=
 and money developing infrastructure that would be useful, even primarily u=
seful, for censorship.=C2=A0 I say no.=C2=A0 Especially because any time sp=
ent on it is time away from anti-censorship pro-privacy tools and because t=
he effort spent doing so would undermine anti-censorship and pro-privacy ef=
forts because they would inevitably=C2=A0moot the efforts=C2=A0expected get=
ting into peoples business and filtering their transactions.</span></div><d=
iv><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 v=
ery beginning Bitcoin has stood against the freedom to transact being=C2=A0=
</span>overridden by some admin based on their judgment call weighing princ=
iples 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 t=
o make ineffectual the blocking of consensual=C2=A0transactions.=C2=A0 It m=
ight not seem as many at the moment, but the pro-privacy and anti-censorshi=
p &#39;side&#39; doesn&#39;t have a paid PR and influence campaign,=C2=A0 b=
ut it also doesn&#39;t matter so much because Bitcoin takes advantage of th=
e nature of information being easy to spread and hard to stifel and it does=
n&#39;t that that huge an effort to route around censorship efforts.</div><=
div><br></div><div>There are elements of anti-censorship in Bitcoin that ha=
ve been so far underdeveloped.=C2=A0 It&#39;s unfortunate that their furthe=
r development might be forced at a time when efforts are needed on other ar=
eas.=C2=A0 But perhaps they wouldn&#39;t get done without a concrete motiva=
tion. Such is life.</div><div><br></div><div><span lang=3D"EN-US"><br></spa=
n></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" cl=
ass=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"noreferrer noreferrer 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-width:1px;border-left-style:solid;border-left-color: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,Helvetica,Arial,sans-serif;fon=
t-size:14px"><span lang=3D"EN-US">Sorry Greg, could you please elaborate fu=
rther on your ideas? Some are not exactly clear:</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">1)=C2=A0</span><span lang=3D"E=
N-US">Allowing node runners to configure their node as they please and refu=
se to relay some txs is considered authoritarian, censorship, and an attemp=
t to regulate third parties conduct. On the other hand, forcing nodes to me=
rge towards a single shared configuration (by preventing them to block txs)=
 is not considered authoritarian because this imposition does not discrimin=
ate towards any txs and is thus non-authoritarian? Did I get the reasoning =
correctly here?</span></p><p style=3D"color:rgba(232,230,227,0.87);font-fam=
ily:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span lan=
g=3D"EN-US">2) I</span><span>f the aim is to have a homogenous mempool stat=
e and to model what will get mined, shouldn=E2=80=99t we reach this state t=
hrough distributed independent nodes who decide=C2=A0independently on what =
they prefer this homogenous state to be? If we don=E2=80=99t reach this sta=
te through this distributed/independent mechanism, then how are we to reach=
 this state? Who gets to decide and steer the direction so that we all conv=
erge towards this homogenous state?=C2=A0 One of the strongest aspects of b=
itcoin is the fact that no single party can force a change/direction, and t=
he network has to somehow reach a shared agreement through independent deci=
sion makers who act in what manner they think is best. The proposed BIP see=
ms to be aligned with such a principle, I fail to see any authoritarian asp=
ect here.=C2=A0</span></p><p style=3D"color:rgba(232,230,227,0.87);font-fam=
ily:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:14px"><span>3)=
=C2=A0</span><span>I share your sentiment and the aim to have a homogenous =
mempool state, but I am skeptical of the manner in which we are to achieve =
this according to the ideas you have here expressed (namely not through a d=
istributed independent organic manner)</span></p><p style=3D"color:rgba(232=
,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;fo=
nt-size:14px"><span lang=3D"EN-US"><br></span></p><p style=3D"color:rgba(23=
2,230,227,0.87);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;f=
ont-size:14px"><span lang=3D"EN-US">Respectfully, 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"noreferrer noreferrer noreferre=
r 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div>So that when the &quot;consistent st=
ate&quot; changes as a result of some issue you can update configs instead =
of having to update software-- which has considerable more costs and risks,=
 especially if you&#39;re carrying local customizations as many miners do.<=
/div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClellan=
d &lt;<a href=3D"mailto:me@drbonez.dev" rel=3D"noreferrer noreferrer norefe=
rrer 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-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">If mempool consistency across the network is all that is im=
portant, 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 Wed=
nesday, September 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.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div>This appears to substantia=
lly=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=A0discre=
pancies=C2=A0are harmful to the system and promote 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 and deploying the technologi=
cal=C2=A0infrastructure=C2=A0for massive censorship.</div><div><br></div><d=
iv>If you think this is important, I advise you to select another cryptocur=
rency which is compatible with such authoritarian=C2=A0leanings.=C2=A0 -- t=
hough I am unsure if any exist since it is such a transparently pointless d=
irection.</div><div><br></div></div><br><div class=3D"gmail_quote"></div><d=
iv 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 norefer=
rer noreferrer noreferrer noreferrer">m...@drbonez.dev</a>&gt; wrote:<br></=
div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div>Hi all,</div><di=
v><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/b=
ips/pull/1985" rel=3D"nofollow noreferrer noreferrer noreferrer noreferrer"=
 target=3D"_blank">https://github.com/bitcoin/bips/pull/1985</a><br><br></d=
iv><div>I think it could potentially reduce conflict within the community a=
round relay policy, as an alternative to running lots of different node imp=
lementations/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 go=
ing and I&#39;m sure doesn&#39;t follow best-practices. Once it&#39;s worki=
ng, 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-width:1px;border-=
left-style:solid;border-left-color: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 noreferrer">bit=
coindev+...@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 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 noreferrer" target=3D"_blank">bitcoindev+un=
subscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferrer noreferre=
r noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoinde=
v/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 noreferrer" target=3D"_blank">bitcoindev+un=
subscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail=
.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer noreferr=
er noreferrer noreferrer" target=3D"_blank">https://groups.google.com/d/msg=
id/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gm=
ail.com</a>.<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.g=
mail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer" tar=
get=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU8=
6r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com</a>.<br>
</blockquote></div></div></div></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/CAL5BAw2RYHkUj4iREYL%2BNca_CYP-BwLB5pZg3xY8%3D4-sf0ompg%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAL5BAw2RYHkUj4iREYL%2BNca_CYP-BwLB5pZg3xY8%3D4-sf0ompg%=
40mail.gmail.com</a>.<br />

--0000000000002a0c63063fab0b8e--