Delivery-date: Wed, 01 Oct 2025 12:57:50 -0700 Received: from mail-qt1-f185.google.com ([209.85.160.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v42xO-0000op-5b for bitcoindev@gnusha.org; Wed, 01 Oct 2025 12:57:50 -0700 Received: by mail-qt1-f185.google.com with SMTP id d75a77b69052e-4e1015c48c8sf27862921cf.1 for ; Wed, 01 Oct 2025 12:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1759348654; x=1759953454; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=zJQ6pmGZYlRuZmchHszg5a5ewEufYYcSm3PleYg9UDw=; b=Zm71vAY2ewMh/Oc452/dftum06p7TM9K8zDHupDHqw5r6BjCDfnc2HBgM+JSDR0WN9 n9Sgv6+dcYQtbT0kzLeRureInawnpNMSCFffuPztkmqJBNWVdcnaVACt2hRuMqfjQGIV BXB+Ttf0YG+TmSqhGb8deZbZBdekVn1P6BDcEHN95utYpFpJFVEaS6r/490tgzZAESpp HW4dZIqIdFgKtSrPuhU2QL9hyY26bmuGBMfUA5n9iOu6CDAb4d4LiNnwXfFW5JTCMfej +XglfJOD3/dJ7vA7wjkBzdgNdWT52P15sFxlI41GIXKNWpSHREoDvCX6T6JKBgrJ6iEG U0zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759348654; x=1759953454; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zJQ6pmGZYlRuZmchHszg5a5ewEufYYcSm3PleYg9UDw=; b=VFGNHNoFZmDbh1LHLruf6WVuQg6C2/3UijLUOBxIreXt0/8g7uZtalXREdGEGXGR0q pj6qFgDaMQNJqWgN8ePWssd0I13OQOhGKgz9+Fx5MUhmKLfL4qOjBFX02xYCce1hJwWJ RQpUqfA1PsYobQnixv7PuQ+cFDscl12GugZknWjA0Pmed1/hCmoN0aKPiAJOmjJnC4vW k3/NiMcDmlgAG8ySxpbNGvw+Yp6LHcCPwVaF6pW2tkQFIHdV0ypaCesBXtWv5a6lkXUj qhh31AS+kaQhXVwJC6re1yKK9OSaIlg8XFyS20VfcuxKdEYai9vJmpyOqc408JnPrxGo XVGw== X-Forwarded-Encrypted: i=1; AJvYcCWhitIlShGTuIDuk2nvDYKFmMRz2yW/ixF1555J2d9kY2ExQHaKHpYxrbECJ4JkYZ+JAmzX/ZYzC6k0@gnusha.org X-Gm-Message-State: AOJu0YyEGNHom8qorzvbg4k+tnExzVnY7zPp+tpv0czW9kLfJ4i7TCKG gmqo5tGOJKM8MsxvxMsyssgka85nw75eBE436i4pua24EOrVAAbpLfte X-Google-Smtp-Source: AGHT+IGqCZg3ZTFIZsCCt4g0MQr63dd5X21YpVUWjFtvcbP7CU+g4S8xLz9TK9fJqbZdiJ/nLzd7eg== X-Received: by 2002:a05:622a:48c:b0:4d2:a1a7:2145 with SMTP id d75a77b69052e-4e5629a2ff3mr14381641cf.35.1759348653590; Wed, 01 Oct 2025 12:57:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd7RiRu9xnKSnCpUiNyo1lvP6XS5WwgwZuyhaaGyCc87uw==" Received: by 2002:a05:622a:d15:b0:4b7:a98b:51db with SMTP id d75a77b69052e-4e55b4244afls7402081cf.2.-pod-prod-03-us; Wed, 01 Oct 2025 12:57:30 -0700 (PDT) X-Received: by 2002:ac8:42c3:0:b0:4dd:1a2f:4889 with SMTP id d75a77b69052e-4e5020fea56mr24200901cf.76.1759348650151; Wed, 01 Oct 2025 12:57:30 -0700 (PDT) Received: by 2002:a81:f10e:0:b0:741:b7fe:46f4 with SMTP id 00721157ae682-76bc66ec1e9ms7b3; Fri, 26 Sep 2025 18:30:30 -0700 (PDT) X-Received: by 2002:a05:690c:4d0a:b0:73c:3bfe:30cf with SMTP id 00721157ae682-763fc4c9021mr107010737b3.13.1758936629587; Fri, 26 Sep 2025 18:30:29 -0700 (PDT) Date: Fri, 26 Sep 2025 18:30:29 -0700 (PDT) From: "'Aiden McClelland' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <4968c87a-ab0a-47a7-9d38-e53fdae1630bn@googlegroups.com> 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_85518_1014478515.1758936629148" X-Original-Sender: me@drbonez.dev X-Original-From: Aiden McClelland Reply-To: Aiden McClelland 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: -1.0 (-) ------=_Part_85518_1014478515.1758936629148 Content-Type: multipart/alternative; boundary="----=_Part_85519_174257906.1758936629148" ------=_Part_85519_174257906.1758936629148 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greg,=20 You've made some very compelling points. I really appreciate you taking the= =20 time to explain your position, and I sympathize with it. I'm still not sure= =20 I agree that there is no compromise here, or that allowing users to set=20 their own relay policy will result in significant censorship of real=20 transactions, but I'm not sure there's a way to prove who's right about=20 that until if/when it happens.=20 At the end of the day, users must be trusted with the ability to choose=20 what code they want to run, in bitcoin and otherwise. I will, as always, do= =20 what I can to enable even the less technical among them to be able to do so= =20 in the safest way possible. For now this seems to be helping some of them= =20 run Knots. If you ever see a path forward for getting these users back onto= =20 Core, I'm happy to collaborate.=20 Best,=20 Aiden McClelland On Thursday, September 25, 2025 at 4:29:36=E2=80=AFPM UTC-6 Greg Maxwell wr= ote: > "There are levels of survival we are prepared to accept." > > Black and white thinking is not very helpful here particularly because th= e=20 > goals of pro-filtering and anti-censorship aren't exact opposites. > > A widely censored world would greatly degrade the value of=20 > Bitcoin, particularly if the censors managed to enlist significant miners= . =20 > It would be routed around at great cost, and with much less freedom=20 > provided for the world. But just like people continue to buy racy=20 > magazines or other completely lawful targets of operation chokepoint with= =20 > USD, people would still route around Bitcoin censorship. But why even u= se=20 > Bitcoin if it's in a similar space of your transactions being capriciousl= y=20 > blocks, your funds frozen, etc. as exists with legacy infrastructure? > > But the irony is that the traffic that people most desperately want to=20 > stop would be among the least impeded-- already today the spam traffic=20 > exists at all because it's well funded (or really existed a year ago, we= =20 > are long past the huge spam floods-- they were depleted by costs and=20 > fizzled as predicted-- and Ocean Mining is fighting yesterday's battle. B= ut=20 > what exists exists because its well funded). Meanwhile joe blow sending= =20 > funds p2p to friends or family in far off places doesn't have the funds o= r=20 > technical acumen to deal with censorship potentially targeting him, his= =20 > activities, or his payees. The effect of censorship is basically to=20 > require people to learn how to be money launderers to freely transact, an= d=20 > those who don't suffer. > > The case is even stronger re: the recently filtering arguments because=20 > unlike some consensus rule anyone can just mine a block (rent hashpower,= =20 > you don't have to own it) or even more so the stuff like op_return limits= =20 > have long been bypassed by major miners. So the policy restriction was= =20 > already not working. So in some sense there are arguments getting=20 > conflated: The op_return policy limit has already failed. So when peopl= e=20 > point out that it doesn't work it's just a statement of fact rather than= =20 > speculation. But basically the 'bad' traffic has a lot easier time than= =20 > more innocent traffic, which is part of why filters can be both ineffecti= ve=20 > and dangerous. It's also the case that existing filter efforts are not= =20 > backed by civil litigation or state mandates, but building infrastructure= =20 > creates an obvious stepping stone to that (in part because of the=20 > insufficient effectiveness of filtering)-- it's just a bad road that will= =20 > almost inevitably lead to more escalations. Bitcoin is just better of= =20 > adopting the position that other people's transactions aren't our busines= s,=20 > even if they're stupid or drive fees up a bit for some periods and create= =20 > annoyances, because the alternative is easily much worse. > > > > > > > > > > > > > > > =20 > > > > > On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McClelland wrote: > >> >I have no idea what you're referring to there. >> >> It's something I inferred from your primary argument that seems to be=20 >> that user-configurable filters are bad because they would cause censorsh= ip.=20 >> But it also sounds like you're saying such filters are completely=20 >> ineffective at any sort of censorship at all. I don't really understand = how=20 >> 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 w= rote: >> >>> I am not a core developer. I have not been for some eight years now. = =20 >>> >>> > 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= =20 >>> nodes that screw up propagation they'll be routed around. I developed = the=20 >>> technical concepts required to get nearly 100% tx coverage even if almo= st=20 >>> all nodes are blocking them quite a few years ago (=20 >>> https://arxiv.org/pdf/1905.10518 ), but deployment of the=20 >>> implementation has gone slow due to other factors (you know, such as th= e=20 >>> most experienced developers being hit with billions of dollars in lawsu= its=20 >>> as a cost for their support of Bitcoin)... I expect if censoring actual= ly=20 >>> becomes widespread that technological improvements which further moot i= t=20 >>> will be developed. >>> >>> These are just vulnerabilities that should be closed anyways-- after al= l=20 >>> anyone at any time can just spin up any number of "nodes" that behave i= n=20 >>> arbitrary ways, at ant time. It's been a lower priority because there = are=20 >>> other countermeasures (addnode-a-friend, manually setbanning bad peers,= =20 >>> etc.) and aforementione distractions. >>> >>> > censorship due to widespread use of transaction filters is a bad thin= g=20 >>> (I'm not really taking a stance on that right now). >>> >>> I would point you to the history of discussion on Bitcoin starting back= =20 >>> with Satoshi's earliest announcements, and perhaps to help you understa= nd=20 >>> that if you want that what you want isn't bitcoin. If after considerat= ion=20 >>> you don't think censorship wouldn't be very bad, then really you and I = have=20 >>> nothing further to discuss. >>> >>> > are you willing to work with and compromise with people who are=20 >>> looking for a solution like this? Or are you going to force them to aba= ndon=20 >>> the Core project entirely >>> >>> I don't really think there is any space to compromise with people who= =20 >>> think it's okay to add censorship to Bitcoin-- I mean sure whatever exa= ct=20 >>> relay policy there is there is plenty of tradeoffs but from the start o= f=20 >>> this new filter debate the filter proponents have immediately come out = with=20 >>> vile insults accusing developers of promoting child sexual abuse and=20 >>> shitcoins and what not---- that isn't some attempt to navigate a=20 >>> technical/political trademark, it's an effort to villify and destory th= e=20 >>> opposition. And unambiguously so as luke has said outright that his g= oal=20 >>> is to destroy Bitcoin Core. So what's the compromise there? =20 >>> >>> > Or even worse still, felt compelled to coordinate a UASF to block=20 >>> these transactions entirely? >>> >>> I very much think people should do that-- they should actually make som= e=20 >>> consensus rules for their filters to fork off and we can see what the= =20 >>> market thinks. -- And also even if the market prefers censored Bitcoin= ,=20 >>> that's also fine with me, in the sense in my view Bitcoin was created t= o be=20 >>> money as largely free from human judgement as possible. When it was=20 >>> created most of the world was doing something else and didn't know they= =20 >>> needed freedom money. If it's still the case that most of the world=20 >>> doesn't want freedom money that would be no shock. They should be free = to=20 >>> have what they want and people who want freedom money should be free to= =20 >>> have what they want. I got into bitcoin before it was worth practicall= y=20 >>> anything because of the freedom it provides, and I think that's paramou= nt. >>> >>> Perhaps you should consider why they *don't* do that? I'd say it's=20 >>> because (1) it won't work, and (2) it's not actually what the world wan= ts--=20 >>> an outspoken influence campaign is not necessarily all that reflective = of=20 >>> much of anything. Particularly given how inaccurate and emotionally=20 >>> pandering the filter advocacy has been. But, hey, I've been wrong=20 >>> before. =20 >>> >>> >>> >>> On Thu, Sep 25, 2025 at 8:51=E2=80=AFPM Aiden McClelland =20 >>> wrote: >>> >>>> Greg,=20 >>>> >>>> Let me assume for a minute, for the sake of argument, that I agree tha= t=20 >>>> transaction censorship due to widespread use of transaction filters is= a=20 >>>> bad thing (I'm not really taking a stance on that right now). It is an= =20 >>>> irrefutable fact that a very large portion of the user base wants to f= ilter=20 >>>> transactions. So many so, that you yourself are worried they will reac= h the=20 >>>> 80% needed to prevent certain types of transactions from propogating.= =20 >>>> Wouldn't it then be *worse* if these 80% of users went and ran an=20 >>>> alternative implementation, most likely written by it's most radical= =20 >>>> supporters? Or even worse still, felt compelled to coordinate a UASF t= o=20 >>>> block these transactions entirely? >>>> >>>> I at no point intended to insinuate that you or any other core=20 >>>> contributer be compelled to implement a proposal like this. It's up to= its=20 >>>> supporters to do so. The real question is, are you willing to work wit= h and=20 >>>> compromise with people who are looking for a solution like this? Or ar= e you=20 >>>> 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 = wrote: >>>> >>>>> > 1) Allowing node >>>>> >>>>> Who said anything about allowing? Everyone is allowed to do whatever= =20 >>>>> they want. Drill a hole in your head if you like, not my concern. N= one of=20 >>>>> this thread is about what people are allowed to do-- that's off the t= able. =20 >>>>> The design and licensing of Bitcoin is such that no one gets to stop = anyone=20 >>>>> else from what they want to do anyways (which is, in fact, a big part= of=20 >>>>> the issue here). To think otherwise is to be stuck in a kind of ser= f=20 >>>>> thinking where you can only do what other people allow you to do. Th= at has=20 >>>>> never been what Bitcoin was about. >>>>> >>>>> Rather, the question is should people who care about Bitcoin spend=20 >>>>> their time and money developing infrastructure that would be useful, = even=20 >>>>> primarily useful, for censorship. I say no. Especially because any = time=20 >>>>> spent on it is time away from anti-censorship pro-privacy tools and b= ecause=20 >>>>> the effort spent doing so would undermine anti-censorship and pro-pri= vacy=20 >>>>> efforts because they would inevitably moot the efforts expected getti= ng=20 >>>>> into peoples business and filtering their transactions. >>>>> >>>>> You don't have to agree, and you're free to do your own thing just as= =20 >>>>> I'm free to say that I think it's a bad direction. From the very beg= inning=20 >>>>> Bitcoin has stood against the freedom to transact being overridden by= =20 >>>>> some admin based on their judgment call weighing principles against o= ther=20 >>>>> concerns, or at the behest of their superiors. So many Bitcoiner wil= l=20 >>>>> stand against, route around, and do what they can do to make ineffect= ual=20 >>>>> the blocking of consensual transactions. It might not seem as many a= t the=20 >>>>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a= paid=20 >>>>> PR and influence campaign, but it also doesn't matter so much becaus= e=20 >>>>> Bitcoin takes advantage of the nature of information being easy to sp= read=20 >>>>> and hard to stifel and it doesn't that that huge an effort to route a= round=20 >>>>> censorship efforts. >>>>> >>>>> There are elements of anti-censorship in Bitcoin that have been so fa= r=20 >>>>> underdeveloped. It's unfortunate that their further development migh= t be=20 >>>>> forced at a time when efforts are needed on other areas. But perhaps= they=20 >>>>> wouldn't get done without a concrete motivation. Such is life. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Sep 25, 2025 at 9:21=E2=80=AFAM yes_please =20 >>>>> wrote: >>>>> >>>>>> Sorry Greg, could you please elaborate further on your ideas? Some= =20 >>>>>> are not exactly clear: >>>>>> >>>>>> 1) Allowing node runners to configure their node as they please and= =20 >>>>>> refuse to relay some txs is considered authoritarian, censorship, an= d an=20 >>>>>> attempt to regulate third parties conduct. On the other hand, forcin= g nodes=20 >>>>>> to merge towards a single shared configuration (by preventing them t= o block=20 >>>>>> txs) is not considered authoritarian because this imposition does no= t=20 >>>>>> discriminate towards any txs and is thus non-authoritarian? Did I ge= t the=20 >>>>>> reasoning correctly here? >>>>>> >>>>>> 2) If the aim is to have a homogenous mempool state and to model=20 >>>>>> what will get mined, shouldn=E2=80=99t we reach this state through d= istributed=20 >>>>>> independent nodes who decide independently on what they prefer this= =20 >>>>>> homogenous state to be? If we don=E2=80=99t reach this state through= this=20 >>>>>> distributed/independent mechanism, then how are we to reach this sta= te? Who=20 >>>>>> gets to decide and steer the direction so that we all converge towar= ds this=20 >>>>>> homogenous state? One of the strongest aspects of bitcoin is the fa= ct that=20 >>>>>> no single party can force a change/direction, and the network has to= =20 >>>>>> somehow reach a shared agreement through independent decision makers= who=20 >>>>>> act in what manner they think is best. The proposed BIP seems to be = aligned=20 >>>>>> with such a principle, I fail to see any authoritarian aspect here.= =20 >>>>>> >>>>>> 3) I share your sentiment and the aim to have a homogenous mempool= =20 >>>>>> state, but I am skeptical of the manner in which we are to achieve t= his=20 >>>>>> according to the ideas you have here expressed (namely not through a= =20 >>>>>> distributed independent organic manner) >>>>>> >>>>>> >>>>>> Respectfully, yes_please =20 >>>>>> >>>>>> On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell =20 >>>>>> wrote: >>>>>> >>>>>>> So that when the "consistent state" changes as a result of some=20 >>>>>>> issue you can update configs instead of having to update software--= which=20 >>>>>>> has considerable more costs and risks, especially if you're carryin= g local=20 >>>>>>> customizations as many miners do. >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland =20 >>>>>>> wrote: >>>>>>> >>>>>>>> If mempool consistency across the network is all that is important= ,=20 >>>>>>>> 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= Maxwell=20 >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This appears to substantially misunderstands the purpose of the= =20 >>>>>>>>> mempool broadly in the network-- it's purpose is to model what wi= ll get=20 >>>>>>>>> mined. If you're not doing that you might as well set blocks onl= y. =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 d= eploying=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 leanin= gs. --=20 >>>>>>>>> though I am unsure if any exist since it is such a transparently = pointless=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=20 >>>>>>>>>> modular mempool/relay policy:=20 >>>>>>>>>> https://github.com/bitcoin/bips/pull/1985 >>>>>>>>>> >>>>>>>>>> I think it could potentially reduce conflict within the communit= y=20 >>>>>>>>>> around relay policy, as an alternative to running lots of differ= ent node=20 >>>>>>>>>> implementations/forks when there are disagreements. >>>>>>>>>> >>>>>>>>>> I am working on a reference implementation using Bellard's=20 >>>>>>>>>> QuickJS, but it has been almost a decade since I've written C++,= so it's=20 >>>>>>>>>> slow going and I'm sure doesn't follow best-practices. Once it's= working,=20 >>>>>>>>>> it can be cleaned up. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Aiden McClelland >>>>>>>>>> >>>>>>>>>> --=20 >>>>>>>>>> You received this message because you are subscribed to the=20 >>>>>>>>>> Google Groups "Bitcoin Development Mailing List" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it= ,=20 >>>>>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>>>>> To view this discussion visit=20 >>>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-= 80f0-6c68c6554f56n%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,= =20 >>>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>>> To view this discussion visit=20 >>>>>>>> https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a8= 95-b48664babbfcn%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,= =20 >>>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>>> To view this discussion visit=20 >>>>>>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uh= VrDiQnL6x1X6ALzfsJ7w4GztWVeNA%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/= 4968c87a-ab0a-47a7-9d38-e53fdae1630bn%40googlegroups.com. ------=_Part_85519_174257906.1758936629148 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg,=C2=A0

You'v= e made=20 some very compelling points. I really appreciate you taking the time to=20 explain your position, and I sympathize with it. I'm still not sure I=20 agree that there is no compromise here, or that allowing users to set=20 their own relay policy will result in significant censorship of real=20 transactions, but I'm not sure there's a way to prove who's right about=20 that until if/when it happens.=C2=A0

At the end of the day, users must be trusted with the ability to choose=20 what code they want to run, in bitcoin and otherwise. I will, as always, do what I can to enable even the less technical among them to be able=20 to do so in the safest way possible. For now this seems to be helping=20 some of them run Knots. If you ever see a path forward for getting these users back onto Core, I'm happy to collaborate.=C2=A0

Best,=C2=A0
Aiden M= cClelland


On Thursday, September 25, 2025 at 4:29:36=E2=80=AFPM UTC= -6 Greg Maxwell wrote:
"There are levels of survival we are p= repared to accept."

Black and white thinking = is not very helpful=C2=A0here particularly because the goals of pro-filteri= ng and anti-censorship aren't exact opposites.

A widely censored world would greatly degrade the value of Bitcoin,=C2=A0p= articularly if the censors managed to enlist significant miners.=C2=A0 It w= ould be routed around at great cost, and with much less freedom provided fo= r the world.=C2=A0 But just like people continue to buy racy magazines or o= ther completely lawful targets of operation chokepoint=C2=A0with USD, peopl= e would still route around Bitcoin censorship.=C2=A0 =C2=A0But why even use= Bitcoin if it's in a similar space of your transactions being capricio= usly blocks, your funds frozen, etc. as exists with legacy infrastructure?<= /div>

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 exis= ted a year ago, we are long past the huge spam floods-- they were depleted = by costs and fizzled as predicted--=C2=A0and Ocean Mining is fighting yeste= rday's battle. But what exists exists because its well funded).=C2=A0 M= eanwhile joe blow sending funds p2p to friends or family in far off places = doesn't have the funds or technical acumen=C2=A0to deal with censorship= potentially targeting him, his activities, or his payees.=C2=A0 The effect= of censorship is basically to require people to learn how to be money laun= derers to freely transact, and those who don't suffer.

The case is even stronger re: the recently filtering arguments bec= ause unlike some consensus rule anyone can just mine a block (rent hashpowe= r, you don't have to own it) or even more so the stuff like op_return l= imits have long been bypassed by major miners.=C2=A0 So the policy restrict= ion was already not working.=C2=A0 =C2=A0So in some sense there are argumen= ts getting conflated:=C2=A0 The op_return policy limit has already failed.= =C2=A0 So when people point out that it doesn't work it's just a st= atement of fact rather than speculation.=C2=A0 But basically the 'bad&#= 39; traffic has a lot easier time than more innocent traffic, which is part= of why filters can be both ineffective and dangerous.=C2=A0 It's also = the case that existing filter efforts are not backed by civil litigation or= state mandates, but building infrastructure creates an obvious stepping st= one to that (in part because of the insufficient effectiveness of filtering= )-- it's just a bad road that will almost inevitably lead to more escal= ations.=C2=A0 =C2=A0Bitcoin is just better of adopting the position that ot= her people's transactions aren't our business, even if they're = stupid or drive fees up a bit for some periods and create annoyances, becau= se the alternative is easily much worse.














=C2=A0=C2=A0

<= br>


On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McCle= lland <m...@drbonez.dev&g= t; wrote:
>I have no idea what you're referring to there.

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

Best,
Aiden McCle= lland

On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell &l= t;gmax...@gmail.com> wrot= e:
I am not a core developer. I have not been for some eight years no= w.=C2=A0 =C2=A0

>=C2=A0that you yourself are wo= rried they will reach the 80% needed

I have no ide= a what you're referring to there.=C2=A0 If lots of people run nodes tha= t screw up propagation they'll be routed around.=C2=A0 I developed the = technical concepts required to get nearly 100% tx coverage even if almost a= ll nodes are blocking them quite a few years ago ( https://arxiv.org/pdf/1905.10518 ), but dep= loyment of the implementation has gone slow due to other factors (you know,= such as the most experienced=C2=A0developers being hit with billions of do= llars in lawsuits as a cost for their support of Bitcoin)... I expect if ce= nsoring actually becomes widespread that technological improvements which f= urther moot it will be developed.

These are just v= ulnerabilities that should be closed anyways-- after all anyone at any time= can just spin up any number of "nodes" that behave in arbitrary= =C2=A0ways, at ant time.=C2=A0 It's been a lower priority because there= are other countermeasures (addnode-a-friend, manually setbanning=C2=A0bad = peers, etc.) and aforementione distractions.

>= =C2=A0censorship due to widespread use of transaction filters is a bad thin= g (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 und= erstand that if you want that what you want isn't bitcoin.=C2=A0 If aft= er consideration you don't think censorship wouldn't be very bad, t= hen really you and I have nothing further to discuss.

<= div>>=C2=A0are you willing to work with and compromise with people who a= re looking=20 for a solution like this? Or are you going to force them to abandon the=20 Core project entirely

I don't really think the= re is any space to compromise with people who think it'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't some attempt to navigate a technical/political trademark, it= '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's the compromise there?=C2=A0=C2=A0

>=C2=A0Or even worse still, felt compelled to coordinate= a UASF to block these transactions entirely?

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'= ;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't know they nee= ded freedom money.=C2=A0 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.=C2=A0 I got into bitcoin before it was worth practical= ly anything because of the freedom it provides, and I think that's para= mount.

Perhaps you should consider why they *don&#= 39;t* do that?=C2=A0 I'd say it's because (1) it won't work, an= d (2) it'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've been wrong before.=C2=A0=C2=A0=



On Thu, Sep 25, 2025 at 8:51=E2=80=AFPM= Aiden McClelland <m...@drbonez.dev> wrote:
Greg,=C2=A0
=
Let me assume for a minute, for the sake of arg= ument, that I agree that transaction censorship due to widespread use of tr= ansaction filters is a bad thing (I'm not really taking a stance on tha= t right now). It is an irrefutable fact that a very large portion of the us= er base wants to filter transactions. So many so, that you yourself are wor= ried they will reach the 80% needed to prevent certain types of transaction= s from propogating. Wouldn't it then be worse if these 80% of us= ers went and ran an alternative implementation, most likely written by it&#= 39;s most radical supporters? Or even worse still, felt compelled to coordi= nate a UASF to block these transactions entirely?
I at no point intended to insinuate that you or a= ny other core contributer be compelled to implement a proposal like this. I= t's up to its supporters to do so. The real question is, are you willin= g to work with and compromise with people who are looking for a solution li= ke this? Or are you going to force them to abandon the Core project entirel= y?

Best,
Aiden McClelland

On Thu, Sep 25, 202= 5, 2:03=E2=80=AFPM Greg Maxwell <gmax...@gmail.com> wrote:
>=C2=A0= 1)=C2=A0Allowing node

Who said anything about allowing?=C2=A0 Everyone is allowed to do whateve= r they want.=C2=A0 Drill a hole in your head if you like, not my concern.= =C2=A0 None of this thread is about what people are allowed to do-- that= 9;s off the table.=C2=A0 The design and licensing of Bitcoin is such that n= o one gets to stop anyone else from what they=C2=A0want to do anyways (whic= h is, in fact, a big part of the issue here).=C2=A0 =C2=A0To think otherwis= e is to be stuck in a kind of serf thinking where you can only do what othe= r people allow you to do.=C2=A0 That has never been what Bitcoin was about.=

Rather, the question is should people who care about Bitcoin spend t= heir time and money developing infrastructure that would be useful, even pr= imarily useful, for censorship.=C2=A0 I say no.=C2=A0 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=C2=A0moot the efforts=C2=A0exp= ected 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=C2=A0direction.=C2=A0 F= rom the very beginning Bitcoin has stood against the freedom to transact be= ing=C2=A0overridden by some admin based on their judgment call weigh= ing principles against other concerns, or at the behest of their superiors.= =C2=A0 So many Bitcoiner will stand against, route around, and do what they= can do to make ineffectual the blocking of consensual=C2=A0transactions.= =C2=A0 It might not seem as many at the moment, but the pro-privacy and ant= i-censorship 'side' doesn't have a paid PR and influence campai= gn,=C2=A0 but it also doesn't matter so much because Bitcoin takes adva= ntage of the nature of information being easy to spread and hard to stifel = and it doesn't that that huge an effort to route around censorship effo= rts.

There are elements of anti-censorship in Bitc= oin that have been so far underdeveloped.=C2=A0 It's unfortunate that t= heir further development might be forced at a time when efforts are needed = on other areas.=C2=A0 But perhaps they wouldn't get done without a conc= rete motivation. Such is life.





On Thu, Sep 25, 2025 at 9:21=E2=80=AFAM yes_p= lease <caucasi...@gmail.com> wrote:

Sorry Greg, could you please elaborate = further on your ideas? Some are not exactly clear:

1)=C2=A0Allowing node runners to configure their node as they please and re= fuse to relay some txs is considered authoritarian, censorship, and an atte= mpt to regulate third parties conduct. On the other hand, forcing nodes to = merge towards a single shared configuration (by preventing them to block tx= s) is not considered authoritarian because this imposition does not discrim= inate towards any txs and is thus non-authoritarian? Did I get the reasonin= g correctly here?

2) If the aim is to have a homogenous mempool st= ate and to model what will get mined, shouldn=E2=80=99t we reach this state= through distributed independent nodes who decide=C2=A0independently on wha= t they prefer this homogenous state to be? If we don=E2=80=99t reach this s= tate through this distributed/independent mechanism, then how are we to rea= ch this state? Who gets to decide and steer the direction so that we all co= nverge towards 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 network has to somehow reach a shared agreement through independent de= cision makers who act in what manner they think is best. The proposed BIP s= eems to be aligned with such a principle, I fail to see any authoritarian a= spect here.=C2=A0

3= )=C2=A0I 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=C2=A0=C2=A0= =C2=A0


On Thu, Sep 25, 2025 at 12:50=E2=80=AFAM Greg Maxwell <= gmax...@gmail.com> wrote:
So that when the "consistent s= tate" changes as a result of some issue you can update configs instead= of having to update software-- which has considerable more costs and risks= , especially if you're carrying local customizations as many miners do.=


On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClella= nd <m...@drbonez.dev> wrote:
If mempool consistency across the network is all th= at is important, why allow any configuration of mempool relay policies at a= ll?

On Wednesday, September 24, 2025 at 12:47:28=E2=80=AFPM UTC-6 Greg Maxwel= l wrote:
This appears to substantially=C2=A0misunderstands the purpos= e of the mempool broadly in the network-- it's purpose is to model what= will get mined.=C2=A0 If you're not doing that you might as well set b= locks only.=C2=A0 Significant=C2=A0discrepancies=C2=A0are harmful to the sy= stem and promote centralization=C2=A0and fail to achieve a useful purpose i= n any case.=C2=A0 What marginal benefits might be provided do not justify= =C2=A0building and deploying the technological=C2=A0infrastructure=C2=A0for= massive censorship.

If you think this is importan= t, I advise you to select another cryptocurrency which is compatible with s= uch authoritarian=C2=A0leanings.=C2=A0 -- though I am unsure if any exist s= ince it is such a transparently pointless direction.


On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aide= n McClelland <m...@= drbonez.dev> wrote:
Hi all,

I'd like to share for discussion a draft BIP to allow for a modu= lar mempool/relay policy: https://github.com/bitcoin/bips/= pull/1985

I think it could potentially reduce conflic= t within the community around relay policy, as an alternative to running lo= ts of different node implementations/forks when there are disagreements.

I am working on a reference implementation using Bel= lard'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-practi= ces. Once it's working, it can be cleaned up.

= Thanks,
Aiden 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+...= @googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cb= dab6fa-93bc-44c9-80f0-6c68c6554f56n%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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/de= 4dae19-86f4-4d7a-a895-b48664babbfcn%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+...@googlegroups.com.
To view this discussion visit https://groups.google.c= om/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%4= 0mail.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/4968c87a-ab0a-47a7-9d38-e53fdae1630bn%40googlegroups.com.
------=_Part_85519_174257906.1758936629148-- ------=_Part_85518_1014478515.1758936629148--