Delivery-date: Thu, 25 Sep 2025 14:30:58 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v1tYH-0002tj-E4 for bitcoindev@gnusha.org; Thu, 25 Sep 2025 14:30:58 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-368e47ea3afsf1018740fac.1 for ; Thu, 25 Sep 2025 14:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1758835851; x=1759440651; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=8ZE//ykn0VCFhZ5ind02gMQ2qCCvm/CtmG6JQjtnYso=; b=m7nPwYnO+EXiUbNWu090eQJuP3dOd5HhfE6MsX+KTwl8noowF9BVYSeBa88+a3pa6s MD3ThA7iIXjpt3Le6GUIrrTsH7Av3cjU5bjY0BlOar+9JcEXQY1VVB15bS8t/BXm1tf8 vqhyQ+lMy/VORgNJPIOIlv1PItM9Q9qoqBHnuSiz0PcFqyqznLs/O6FneaRbyP2549ZM av6M0xwCCtgHzHT/zCblql5xlEjbunhA26lvnCRsRNJR2opnPvmEtNdSUKc97TrqznAd rXI89AUc1eq1/fHkMA555Ve0tk52O4L1bx7uI2cVfynTDcxvZVZC1r+MAb1U86omoI4M 6Rcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758835851; x=1759440651; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=8ZE//ykn0VCFhZ5ind02gMQ2qCCvm/CtmG6JQjtnYso=; b=iuUHVPrpVLJvlpkzKdJbjLjNlhrRyz85i8ok2DNa6Uj1E6bc8a6iBUdS4OhXNKWurl D/euDEsHx4QPSSdHGNogZ/LJ7zObkKViMi53bVd+A76CCcmM2fQt1TU7u8ukHvmTRmeB K0/58oKOanBmIcsRah8zpZfQmPSQCkizuX20l2eZJFaRYJf3uofaanycOINB87hQimLX eJ3FQLLAAFmhwTL0TgJaT5jeI7AJ6jkZDwPBJJuRlPcreu1kCe3h6k0K+rWrAHH/2MLl mP5r0lOsKtmYtzd0oG6Ed4MDCZbQhdB4OnhDuMYwxHpePzTl8toDGpptJj4HCDNzQvlb oJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758835851; x=1759440651; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=8ZE//ykn0VCFhZ5ind02gMQ2qCCvm/CtmG6JQjtnYso=; b=KGr9IFlTihSlNEhFYfNkgmngYzG5c6mt5DGNlln5eShYoSl70I5hVd5t2QEGFFGmVY vih83a3g5gi2yK5bfGDqscJFSWF/qtt0jgea8dFQwpEIQJpEcJLnLopEDRU7VnXvXVeu SQ0xOf8DdmEhwaF4wDARnuEBf0b2oRHjylPSBDnwUmFDuqNm3OxqKvqNVkXnISD5N2Bz 22Wpo2yDj8R4c26MIBUW6ueBLthCA36bBkn2Sq7USXfm4tZEsJXCVil6u2kqC4Vn4I9j oGYvsAlrcBKXGd58mxJ473HLbIAwJszt2lGM065GobYbmiJgF7zuS3uwoZ7IrAyqwQEn 9ohQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVv0BCy41nsMtUpdf9/3OJJz6TbGftuZhnt/TweFWIchcmkyIiJWiB+BbTeO3RVQtybyDPqVGnhx/qD@gnusha.org X-Gm-Message-State: AOJu0Yy9GJNCWS2RGqnKhoTcH1Ar2oq5Al8JsKBRckyWS9efAPjvmIwS bHFDtoqKqtWzjFgVeHaV5HFD4z+vzV18QR6oIOSgu4mrf84Ym7gBHlpa X-Google-Smtp-Source: AGHT+IEkPTgW+s03ABjKGL6KJFvq8nvSxCCMcRYm3ji4lROuGMfGj85j8BpNX6va69J/mJtcUkkVmQ== X-Received: by 2002:a05:6870:3313:b0:319:c278:4a6 with SMTP id 586e51a60fabf-35ef0d3f931mr2770302fac.44.1758835850786; Thu, 25 Sep 2025 14:30:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4lhfJTvlpod5FDqZOcg9P0VvAInz1y6RTMMAcAV1Uf4w==" Received: by 2002:a05:6871:3206:b0:34c:97cf:52e with SMTP id 586e51a60fabf-35ef1129798ls502089fac.2.-pod-prod-02-us; Thu, 25 Sep 2025 14:30:46 -0700 (PDT) X-Received: by 2002:a05:6808:11d1:b0:43f:285a:ee4c with SMTP id 5614622812f47-43f4cea1d5bmr2616348b6e.38.1758835846493; Thu, 25 Sep 2025 14:30:46 -0700 (PDT) Received: by 2002:a05:690c:4a05:b0:725:2535:e36 with SMTP id 00721157ae682-75e1de5491fms7b3; Wed, 24 Sep 2025 19:20:40 -0700 (PDT) X-Received: by 2002:a05:690c:5204:b0:762:772b:917d with SMTP id 00721157ae682-764081070f3mr11101287b3.49.1758766839337; Wed, 24 Sep 2025 19:20:39 -0700 (PDT) Date: Wed, 24 Sep 2025 19:20:38 -0700 (PDT) From: bigshiny To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5364_589186089.1758766838963" X-Original-Sender: bigshiny90@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_5364_589186089.1758766838963 Content-Type: multipart/alternative; boundary="----=_Part_5365_1715934081.1758766838963" ------=_Part_5365_1715934081.1758766838963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the proper framing of this situation is =E2=80=98distributed auto= nomy=E2=80=99=20 not =E2=80=98distributed authoritarianism=E2=80=99 - which is incredibly mi= sleading and=20 completely incorrect. Authoritarianism is about centralized imposed control. So if an individual makes a choice =E2=80=94 say, filtering, blocking, or s= etting=20 boundaries in a network =E2=80=94 that=E2=80=99s personal autonomy, not aut= horitarianism.=20 They=E2=80=99re exercising their own agency, not asserting control over eve= ryone=20 else. On Wednesday, September 24, 2025 at 4:47:07=E2=80=AFPM UTC-4 Greg Maxwell w= rote: > Because if you have a need to regulate traffic through your node there is= =20 > one, simple, perfectly effective way-- blocksonly. Any other way is=20 > ineffective (dramatically so if you wish to reduce traffic, as filtering= =20 > generally doesn't) and has collateral damage potential. > > From the discussion in public the motivation to do otherwise is an attemp= t=20 > to regulate the conduct of third parties. This is=20 > fundamentally authoritarian, it would still be authoritarian even if=20 > implemented in a distributed way. E.g. if a theocratic populist movement= =20 > acted to prohibit sex for any purpose except reproduction (as advocated b= y=20 > the most prominent filter propents) such as by public stonings of people= =20 > caught fornicating it would be just as authoritarian as if established by= a=20 > dictator. In my view the fundamental nature of authoritarianism is peopl= e=20 > who believe they know better to such an extent that they actively=20 > interfere with the consensual conduct of third parties. Historically mos= t=20 > authoritarianism has taken centralized forms, but this is partially just = an=20 > implementation detail similar to how cultures have adopted representative= =20 > democracy over direct democracy. Centralized authoritarianism is itself= =20 > normally via a group like a state government, but just one with restricte= d=20 > membership. Technology can enable distributed authoritarianism like the= =20 > cancel culture of filter proponents. > > More importantly, I disagree that there is any meaningful democratization= =20 > here-- to have any significant effects on the behavior of third parties,= =20 > some external mechanism must coordinate the content of filters. Were thi= s=20 > not the case, you could simply say "my filtering node software exists and= =20 > is available, problem solved!" -- but you're not doing that, because to= =20 > have any effect (to the limited extent that you can) you essentially need= =20 > to convince everyone or at least most people to apply the same restrictio= ns. > > The fact that a mechanism isn't proposed here just obscures the matter=20 > because one will arise out of necessity (or, alternatively, the proposal= =20 > would just not be used to a meaningful degree). In essence the proposal= =20 > (or ones like it like the one being developed in knots) are technological= =20 > instruments of authoritarian censorship. Sure they don't have all the=20 > components yet to complete their natural conclusion. > > > which is that the core maintainers decide all the defaults > > Defaults? well duh, yes any author of software decides its defaults and= =20 > that is unchanged in this proposal. Nor does it change persons own abili= ty=20 > to change their node behavior, as adjustments to policy are quite simple= =20 > and with the LLMs that power most filter advocates arguments even a=20 > non-programmer can adjust them. What it does accomplish over that is the= =20 > ability to take a live feed of censorship rules from a third party. > > Why doesn't core ship blocks only? Core attempts to model what will get= =20 > mined. My blocks only recommendation was for parties that prioritize=20 > conserving resources or avoiding various unconfirmed traffic over=20 > accurately modeling what will get mined. > > > > > > > > On Wed, Sep 24, 2025 at 7:16=E2=80=AFPM Chris Guida = wrote: > >> Hi Aiden -=20 >> >> This is a very interesting proposal! It certainly has the potential to= =20 >> reduce tension over mempool policy by removing decisions over mempool=20 >> policy from bitcoin core's maintainers, who, if I understand correctly, = are=20 >> not very interested in being the arbiters of policy over the bitcoin=20 >> network anyway. >> >> This seems like an excellent way to let users decide which transactions= =20 >> they will relay and which ones they won't, which core maintainers have n= o=20 >> control over anyway. >> >> I'm cautiously optimistic that this proposal can help break the logjam. >> >> Greg - >> >> I'm somewhat confused as to your reaction here. This proposal=20 >> democratizes access to filter authorship; it does not seem in any way=20 >> "authoritarian" to me. On the contrary, this proposal seems less=20 >> "authoritarian" than the current state of affairs, which is that the cor= e=20 >> maintainers decide all the defaults. >> >> >If you're not doing that you might as well set blocks only. >> >> Why is running blocksonly more beneficial than relaying some transaction= s=20 >> and not others? Why does bitcoin core not default to blocksonly (or no= =20 >> filters at all) if partial filtration is undesirable? >> >> Kind regards, >> >> --Chris Guida >> >> On Wed, Sep 24, 2025 at 12:47=E2=80=AFPM Greg Maxwell wrote: >> >>> This appears to substantially misunderstands the purpose of the mempool= =20 >>> broadly in the network-- it's purpose is to model what will get mined. = If=20 >>> you're not doing that you might as well set blocks only. =20 >>> Significant discrepancies are harmful to the system and promote=20 >>> centralization and fail to achieve a useful purpose in any case. What= =20 >>> marginal benefits might be provided do not justify building and deployi= ng=20 >>> the technological infrastructure for massive censorship. >>> >>> If you think this is important, I advise you to select another=20 >>> cryptocurrency which is compatible with such authoritarian leanings. -= -=20 >>> though I am unsure if any exist since it is such a transparently pointl= ess=20 >>> direction. >>> >>> >>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland =20 >>> wrote: >>> >>>> Hi all, >>>> >>>> I'd like to share for discussion a draft BIP to allow for a modular=20 >>>> mempool/relay policy: https://github.com/bitcoin/bips/pull/1985 >>>> >>>> I think it could potentially reduce conflict within the community=20 >>>> around relay policy, as an alternative to running lots of different no= de=20 >>>> implementations/forks when there are disagreements. >>>> >>>> I am working on a reference implementation using Bellard's QuickJS, bu= t=20 >>>> it has been almost a decade since I've written C++, so it's slow going= and=20 >>>> I'm sure doesn't follow best-practices. Once it's working, it can be= =20 >>>> cleaned up. >>>> >>>> Thanks, >>>> Aiden McClelland >>>> >>>> --=20 >>>> You received this message because you are subscribed to the Google=20 >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>>> an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit=20 >>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6= c68c6554f56n%40googlegroups.com=20 >>>> >>>> . >>>> >>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7= %3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com=20 >>> >>> . >>> >> --=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/= c26c2e30-3a74-4afa-b6b8-209c711b8167n%40googlegroups.com. ------=_Part_5365_1715934081.1758766838963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the proper framing of this situation is =E2=80=98distributed auto= nomy=E2=80=99 not =E2=80=98distributed authoritarianism=E2=80=99 - which is= incredibly misleading and completely incorrect.

Autho= ritarianism is about centralized imposed control.

So = if an individual makes a choice =E2=80=94 say, filtering, blocking, or sett= ing boundaries in a network =E2=80=94 that=E2=80=99s personal autonomy, not= authoritarianism. They=E2=80=99re exercising their own agency, not asserti= ng control over everyone else.
On Wednesday, September 24, 2025 at 4:47:07=E2= =80=AFPM UTC-4 Greg Maxwell wrote:
Because if you have a need to r= egulate traffic through your node there is one, simple, perfectly effective= way-- blocksonly.=C2=A0 Any other way is ineffective (dramatically so if y= ou wish to reduce traffic, as filtering generally doesn't) and has coll= ateral damage potential.

From the discussion in pu= blic the motivation to do otherwise is an attempt to regulate the conduct o= f third parties. This is fundamentally=C2=A0authoritarian,=C2=A0it would st= ill be authoritarian even if implemented in a distributed way.=C2=A0 E.g. i= f a theocratic populist movement acted to prohibit sex for any purpose exce= pt reproduction (as advocated by the most prominent=C2=A0filter propents) s= uch as by public stonings of people caught fornicating it would be just as = authoritarian as if established by a dictator.=C2=A0 In my view the fundame= ntal=C2=A0nature of authoritarianism is people who believe they know better= to such an extent that they actively interfere=C2=A0with the consensual=C2= =A0conduct of third parties.=C2=A0 Historically most authoritarianism=C2=A0= has taken centralized forms, but this is partially just an implementation d= etail similar to how cultures have adopted representative democracy over di= rect democracy.=C2=A0 Centralized authoritarianism is itself normally via a= group like a state government, but just one with restricted membership.=C2= =A0 =C2=A0Technology can enable=C2=A0distributed authoritarianism=C2=A0like= the cancel culture of filter proponents.

More imp= ortantly, I disagree that there is any meaningful democratization here-- to= have any significant effects on the behavior of third parties, some extern= al mechanism must coordinate the content of filters.=C2=A0 Were this not th= e case, you could simply say "my filtering node software exists and is= available, problem solved!" -- but you're not doing that, because= to have any effect (to the limited extent that you can) you essentially ne= ed to convince everyone or at least most people to apply the same restricti= ons.

The fact that a mechanism isn't proposed = here just obscures the matter because one will arise out of necessity (or, = alternatively, the proposal would just not be used to a meaningful degree).= =C2=A0 In essence the proposal (or ones like it like the one being develope= d in knots) are technological instruments of authoritarian censorship.=C2= =A0 Sure they don't have all the components yet to complete their natur= al conclusion.

>=C2=A0wh= ich is that the core maintainers decide all the defaults

Defaults? well duh, yes any author of softwar= e decides its defaults and that is unchanged in this proposal.=C2=A0 Nor do= es it change persons own ability to change their node behavior, as adjustme= nts to policy are quite simple and with the LLMs that power most filter adv= ocates arguments even a non-programmer can adjust them.=C2=A0 What it does = accomplish over that is the ability to take a live feed of censorship rules= from a third party.

Why doesn't core ship blo= cks only?=C2=A0 Core attempts to model what will get mined.=C2=A0 My blocks= only recommendation was for parties that prioritize conserving resources o= r avoiding various unconfirmed traffic over accurately modeling=C2=A0what w= ill get mined.




<= /div>



On Wed, Sep 24, 2025 at 7:16=E2=80=AFPM = Chris Guida <chris...@gmail.c= om> wrote:
Hi Aiden -

This is a very= interesting proposal! It certainly has the potential to reduce tension ove= r mempool policy by removing decisions over mempool policy from bitcoin cor= e's maintainers, who, if I understand correctly, are not very intereste= d in being the arbiters of policy over the bitcoin network anyway.

This seems like an excellent way to let users decide which= transactions they will relay and which ones they won't, which core mai= ntainers have no control over anyway.

I'm caut= iously optimistic that this proposal can help break the logjam.

Greg -

I'm somewhat confused= as to your reaction here. This proposal democratizes access to filter auth= orship; it does not seem in any way "authoritarian" to me. On the= contrary, this proposal seems less "authoritarian" than the curr= ent state of affairs, which is that the core maintainers decide all the def= aults.

>If you're not doing that you mi= ght as well set blocks only.

Why is running blocks= only more beneficial than relaying some transactions and not others? Why do= es bitcoin core not default to blocksonly (or no filters at all) if partial= filtration is undesirable?

Kind regards,

--Chris Guida

On Wed, Sep 24, 2025 at 12:47=E2=80= =AFPM Greg Maxwell <gmax...@g= mail.com> wrote:
This appears to substantially=C2=A0misunderst= ands the purpose of the mempool broadly in the network-- it's purpose i= s to model what will get mined.=C2=A0 If you're not doing that you migh= t as well set blocks only.=C2=A0 Significant=C2=A0discrepancies=C2=A0are ha= rmful to the system and promote centralization=C2=A0and fail to achieve a u= seful purpose in any case.=C2=A0 What marginal benefits might be provided d= o not justify=C2=A0building and deploying the technological=C2=A0infrastruc= ture=C2=A0for massive censorship.

If you think thi= s is important, I advise you to select another cryptocurrency which is comp= atible with such authoritarian=C2=A0leanings.=C2=A0 -- though I am unsure i= f any exist since it is such a transparently pointless direction.


On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@drbonez.dev> wrote:
=
Hi all,
<= div>
I'd like to share for discussion a draft BIP to allo= w for a modular mempool/relay policy: https://github.com/bitcoin/bips/pull/1985

=
I think it could potentially reduce conflict within the communit= y around relay policy, as an alternative to running lots of different node = implementations/forks when there are disagreements.

I am working on a reference implementation using Bellard's QuickJS, b= ut 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 wo= rking, it can be cleaned up.

Thanks,
Aid= en McClelland

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f5= 6n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https://groups.google.com/d/msgi= d/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40= mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/c26c2e30-3a74-4afa-b6b8-209c711b8167n%40googlegroups.com.
------=_Part_5365_1715934081.1758766838963-- ------=_Part_5364_589186089.1758766838963--