Delivery-date: Wed, 01 Oct 2025 16:04:55 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v45sT-0007rU-CI for bitcoindev@gnusha.org; Wed, 01 Oct 2025 16:04:55 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-33bb2e3a481sf936974fac.2 for ; Wed, 01 Oct 2025 16:04:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759359887; cv=pass; d=google.com; s=arc-20240605; b=VQ3C50GBUfTlttyDjSYuGkz6x/8gmw/pRWwrNKLjzYIbGhgZQV2x2Nu+fAkM1MVHZg Ay9a/P7xUHqo77r7R2mpREwF/MIkp0q8VLrWCnRkCkGPIicw5nJ5eJ2eKTxK5O4hxfxK zJ9pnUx42BPVzKJZCmmii9dJ/YezpcZEH/s0V3wsK7BJHXj5DYY0ZpRHcyznDLpZkSsE Kg47i0vXZC/Z0ZhD8FFP2ukZPYPnBeQUnLebyn6dGm7+NMvQYAooU7OpVGR1azp/UT0x e/VrDEX4T85ZfGT/LxFA44w3f//xPDt2EpYhqUQFa3vlDW+Yag+Tp7qEc7mlmIXN2ut4 xvWg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=J7Y4VKWk67ebsoOQwXy80rJ1rOrWKVN3zdbbSXFKV+w=; fh=szYC+UfYJ/Skrh8/6BKZsRtrYJfz9fOllCwxdOtIk9o=; b=P2JqzmCPmxzYTYk/CdW7YYAI2l7BQw2GyAG4rNbQ68qA46n+sUEaO3ZhNB0jK4tHgx VmIDODbz+rxQ+1JE7B5bnoz44CuL7Sn/3p5MVCpN+tRHsTsXxj2y5ctqbJ+dH9pVpeYh mnoqiESSfQS7+bSYFZkKQYSQtgz1ewL+6WLPjpEfvf6XyJkdaqs0ojxLo6fid9Cq/oAr aPPzDvcMYiSHFY+qIT4UM2oN9on27Vn1xETAbzrEtSP60t9p6E3Pj/1dVnnjXRs7g9IT zbkgdiuubWMftSKaahtd+jugDQV2woO8uC2YyLXsPvck+GaIe3kGhQkd+euB8nLJA62E ylPQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RmYAGLyS; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52a as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1759359887; x=1759964687; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=J7Y4VKWk67ebsoOQwXy80rJ1rOrWKVN3zdbbSXFKV+w=; b=xYY4NYjoUzZkLCooAb1xeoPbSCJzX69ZCeU6FcSesxzHGWDfhyrqP9YY4EbMwerL4A 2ZelbC2nuEr7OQMVkT/9APb5E9Gt1Q58WalXLV4WzKW60ei7w3OOC2wwitfwymVAxO07 APQWrY0fTjaNnQMDf0vi2U4wlXZSpzbPMt5H6YqqQL/RfgLnW2BvRc/JZAKOuHSL1gay E3yoOuWl2gTfNWv4ryo57ZA8Xju5Is1nHaiRp8eykf58gOSbf5D/AgtyXTVfEDT811Nu Ui6BW5klKjolBHRIQC6D3T7infq1Bg+jpArxVwrPYe8NvMfM5JW1/n6FQTXZrKAR0acD RupQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759359887; x=1759964687; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J7Y4VKWk67ebsoOQwXy80rJ1rOrWKVN3zdbbSXFKV+w=; b=Uc7dxkBGt6GrodlFsZIc4gZa2M9J7ywSh6hW3ocabe+uWwByXc6QCXK1jnr2wDBHtf qeGd4auOdvzrocRAleMHbZLjEQvnuS+Z41v47OEFQEM+InL36u+nFKox3qjM5fp8H+Sd c2p1q1pKLNf873QYZIX/uJZntSMel8/ALj4J80qcmTypzjTHm8CkmO06539J3+1v/K9I Wks7gEcJKgR7eUOTKnZ38rDxbFwL0ZTj0JWZsstTJLQ+/GGxYSUUX+4Rc/0QObQx/zUS QchVdtg5WnF81/2PT7wFixJrEiwJGr9449JBJ6/SO+a0SVE+U+HLxMN38FLWVptcd4IZ XShA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759359887; x=1759964687; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=J7Y4VKWk67ebsoOQwXy80rJ1rOrWKVN3zdbbSXFKV+w=; b=imzNo1jfkADAr4f5ZC8Gs8g0xcjzyb9uCYLfBEqBkItYMZ9+jn6XuhgexAo3OO3Uc4 eIhhJ0Ni3JfA1UM6v21IgZmg36Cl+QDUO85YqoJLDU8fr++3KKAL9HUnkkthYeY+Dqh5 cnxWUS1q3Qbm/pgCHvFr+TEugAuC+6Uh+W2L6437tegAqqwvF0VJRbH4XkPjhudCTtLx g9XDd9hRy4fik8/DHFPWpf4pKAtSIk++CmSQUgDP1AWnYAZIt/IqiCcz/PTg+Ic2EZAU 2QHElObg4pMUhefwvi4nGCHV3aAHX02OlxNfKgP8eUAzuV7YdhvrtmeA54kxn21E17Xj GhXg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVTTPan87PwYKWQUOnVJJ01eUQqLZkly66X9JzOD7bVZ0/KaqKHhVg9CTv9EnuwnZvP9oIpAgnqkJJx@gnusha.org X-Gm-Message-State: AOJu0Yy3JtVWzi76VAJsxizdzLcCZq44MpY4I0Ebntq8Ks5+Qq33vvxk zXnYp/Xi5uJESVAkEKfZeE69Yucesi/4MizVn63u10DVkc8gz3BVa+Lm X-Google-Smtp-Source: AGHT+IExsphtXu0TxcJQ8ETtHd92+7Q/CZCBVY7hKzezD3nNsPvLAoLSPWiGYfHYGZz+yCr9l77HlQ== X-Received: by 2002:a05:6870:d1ca:b0:35a:cf5e:fc5a with SMTP id 586e51a60fabf-39b8e3b3827mr2931831fac.3.1759359886880; Wed, 01 Oct 2025 16:04:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6atW4XFk+OhazZS9ZoXXeSniXdV47ubLmeRsudXOYDaQ==" Received: by 2002:a05:6871:d685:20b0:330:f9af:ee37 with SMTP id 586e51a60fabf-3abfec49dcals129362fac.1.-pod-prod-01-us; Wed, 01 Oct 2025 16:04:43 -0700 (PDT) X-Received: by 2002:a05:6808:1995:b0:43f:9a92:fd31 with SMTP id 5614622812f47-43fa4319f8dmr3088694b6e.44.1759359883673; Wed, 01 Oct 2025 16:04:43 -0700 (PDT) Received: by 2002:a05:6808:8493:b0:3f9:f009:458e with SMTP id 5614622812f47-43fa51797d7msb6e; Wed, 1 Oct 2025 14:57:59 -0700 (PDT) X-Received: by 2002:a17:902:e78e:b0:286:456f:8c8a with SMTP id d9443c01a7336-28e7f4b61a4mr52943885ad.50.1759355877888; Wed, 01 Oct 2025 14:57:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759355877; cv=none; d=google.com; s=arc-20240605; b=OiVRLSaxtgcvy/G0GzMbtNlxvb5iuUClmGmJF7CZT7oKN/8TXtWQ8UpLacgWO91DWp NHdW8rpNQ8b6eM2LSU7gDUORMFSNoe0LoZ4gMSv/ynLQPrAa4Omd1S6T3UUbOYYHO4aj gI3yI074ELVbVdwW9OKmntWqpuNLesH0HDTa4W+3pgoq2UJG9AF/o+A4d7uXSzUGs9bX oPJLXSp9cMcq2EyIwccTDC/cBuoNn2OGYAQnxi3uKtJQQqGUj54HOJzXSHv48qJgD4Lr d6gAAFx8FU7tOOX66rlXQLRvLghV29vqA9qonSOHORcIRORwyHSLBI6xPXEgs4kJpM// gzeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=GIgkeNZ8s/n9NJEfNWpbnJ4zE2AEkOtKtv0bRdn85q4=; fh=LGchkCxkGFoVwUGKPwivkLrqHLrKFWcyHlp+il8XdcE=; b=Hr9isSnC/C5TLxUgOnkBY1LU+toqIDjbS60wEPkH1SQEd6cnzkygHSXDaOgDsTp+90 15LElIGXubzbHAjCWQqFzBf5v9tuarZfAESkG8Nz7tc7i4UQJbTYaPRXGQPhqy2nVmUo CkITp0vz3Z7/4X8jZK5/UbvjBpbROmDl5YOrf4bqtDeMl3QGzsWQcymUGfsQMTA9bFBu 6ex4T2uOSJ6QNuufuReEmVgTtKRK/elTl7pmqwD2xnSJGmDWPQESJKQUZVbLDbfQhiH5 s674JFsVbxMXMUni+duPf8zw8hs4H98AUjCcSDvTHz93SLsuvJeto7SKpJstv8TNvJWw yUTA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RmYAGLyS; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52a as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com. [2607:f8b0:4864:20::52a]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-28e8d19dcc8si344095ad.7.2025.10.01.14.57.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Oct 2025 14:57:57 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52a as permitted sender) client-ip=2607:f8b0:4864:20::52a; Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-b49c1c130c9so268118a12.0 for ; Wed, 01 Oct 2025 14:57:57 -0700 (PDT) X-Gm-Gg: ASbGncvKxSAvo8V6fmrk+arsRYG3Ecg4bZfI19U2PFBGmie8/KwqZK3dPhIyl3OnccN FNhlqmZQ7OdNjiOMG3zIQZH4R+ZL68GLtT5zXRF3tBuvmUIpvD+bKXcZuahejJe6weDCbr3NN+w AwCBpxh5LxT0pizhPwWJntm/UGlR8ZlXbcwPNZKwbj1MppVUyjLECVrUh6YMj9nMTjgAEcpW1A3 BcuMH1LX9m9wPV2Ur8x3EVQ0EHFx0wPW/HPdTQVkQ== X-Received: by 2002:a17:903:1aa5:b0:24c:a9c6:d193 with SMTP id d9443c01a7336-28e7f3172b8mr59687565ad.18.1759355877372; Wed, 01 Oct 2025 14:57:57 -0700 (PDT) MIME-Version: 1.0 References: <4968c87a-ab0a-47a7-9d38-e53fdae1630bn@googlegroups.com> In-Reply-To: <4968c87a-ab0a-47a7-9d38-e53fdae1630bn@googlegroups.com> From: Greg Maxwell Date: Wed, 1 Oct 2025 21:57:44 +0000 X-Gm-Features: AS18NWBNq27Xon8fSAInTIMWQUqNVapNAUHKwavI-qp2ZdUpvbNlfEXZHjGtvgA Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts To: Aiden McClelland Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000001ab86306401ff6ce" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=RmYAGLyS; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52a as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000001ab86306401ff6ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > or that allowing users to set their own relay policy will They're already allowed to. No one could even stop them if they wanted to. This repeated framework of things being about what people are allowed to do is distorting people's thinking. When I say people should not do a thing, or others shouldn't waste their time building tools for the thing-- or even that the thing causes harm this has absolutely nothing to do with the view of preventing them from doing it, or even preventing others who want to help from helping them. The two are entirely distinct. But I guess understanding the difference between something that you ought not do like cram unrelated data into Bitcoin with something that should (or even can) be stopped is nuance that is just entirely missing in the advocacy of censors. I don't care if they run knots any more than I care if they eat rocks. It's sad if it ends up harming them, it's sad if they were deceived into doing something that is against their own interest. Hopefully it's fine but it's ultimately not my problem. My node protects me, and if enough censors trash up the p2p network they'll simply be routed around (e.g. by forming an alternative network, by detecting and preventing them from saturating connections if they continue/repeat the "garbageman" connection flooding DDOS attacks, and so on). I suppose it does matter somewhat if usage was widespread enough to create a DDOS on the non-censoring bitcoin nodes requires expending development resources to work around harm, but that's mostly development that ought to happen anyways and anti-censorship is a fun thing to rally around and probably a better use of time then some other initiatives. On Wed, Oct 1, 2025 at 7:57=E2=80=AFPM 'Aiden McClelland' via Bitcoin Devel= opment Mailing List wrote: > Greg, > > You've made some very compelling points. I really appreciate you taking > the time to explain your position, and I sympathize with it. I'm still no= t > sure I agree that there is no compromise here, or that allowing users to > set their own relay policy will result in significant censorship of real > transactions, but I'm not sure there's a way to prove who's right about > that until if/when it happens. > > At the end of the day, users must be trusted with the ability to choose > 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 to do = so > in the safest way possible. For now this seems to be helping some of them > run Knots. If you ever see a path forward for getting these users back on= to > Core, I'm happy to collaborate. > > Best, > Aiden McClelland > > > On Thursday, September 25, 2025 at 4:29:36=E2=80=AFPM UTC-6 Greg Maxwell = 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 miner= s. >> 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 wit= h >> USD, people would still route around Bitcoin censorship. But why even = use >> Bitcoin if it's in a similar space of your transactions being capricious= ly >> 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, we >> 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 sending >> 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, a= nd >> 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 limit= s >> 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 peop= le >> point out that it doesn't work it's just a statement of fact rather than >> speculation. But basically the 'bad' traffic has a lot easier time than >> more innocent traffic, which is part of why filters can be both ineffect= ive >> and dangerous. It's also the case that existing filter efforts are not >> backed by civil litigation or state mandates, but building infrastructur= e >> creates an obvious stepping stone to that (in part because of the >> insufficient effectiveness of filtering)-- it's just a bad road that wil= l >> almost inevitably lead to more escalations. Bitcoin is just better of >> adopting the position that other people's transactions aren't our busine= ss, >> even if they're stupid or drive fees up a bit for some periods and creat= e >> annoyances, because the alternative is easily much worse. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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 >>> that user-configurable filters are bad because they would cause censors= hip. >>> But it also sounds like you're saying such filters are completely >>> ineffective at any sort of censorship at all. I don't really understand= how >>> these two viewpoints can coexist. What am I missing here? >>> >>> Best, >>> *Aiden McClelland* >>> >>> On Thu, Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell = 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 developed= the >>>> technical concepts required to get nearly 100% tx coverage even if alm= ost >>>> 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 t= he >>>> most experienced developers being hit with billions of dollars in laws= uits >>>> as a cost for their support of Bitcoin)... I expect if censoring actua= lly >>>> 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 beh= ave >>>> in arbitrary ways, at ant time. It's been a lower priority because th= ere >>>> are other countermeasures (addnode-a-friend, manually setbanning bad p= eers, >>>> 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 bac= k >>>> with Satoshi's earliest announcements, and perhaps to help you underst= and >>>> that if you want that what you want isn't bitcoin. If after considera= tion >>>> you don't think censorship wouldn't be very bad, then really 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 ab= andon >>>> 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 ex= act >>>> relay policy there is there is plenty of tradeoffs but from the start = of >>>> this new filter debate the filter proponents have immediately come out= 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 t= he >>>> 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 what= the >>>> market thinks. -- And also even if the market prefers censored Bitcoi= n, >>>> 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 the= y >>>> needed freedom money. If it's still the case that most of the world >>>> doesn't want freedom money that would be no shock. They should be free= to >>>> have what they want and people who want freedom money should be free t= o >>>> have what they want. I got into bitcoin before it was worth practical= ly >>>> anything because of the freedom it provides, and I think that's paramo= unt. >>>> >>>> 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 wa= nts-- >>>> an outspoken influence campaign is not necessarily all that reflective= of >>>> much of anything. Particularly given how inaccurate and emotionally >>>> pandering the filter advocacy has been. But, hey, I've been wrong >>>> before. >>>> >>>> >>>> >>>> On Thu, Sep 25, 2025 at 8:51=E2=80=AFPM Aiden McClelland >>>> 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 filt= ers is >>>>> a bad thing (I'm not really taking a stance on that right now). It is= an >>>>> irrefutable fact that a very large portion of the user base wants to = filter >>>>> transactions. So many so, that you yourself are worried they will rea= ch 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 t= o its >>>>> supporters to do so. The real question is, are you willing to work wi= th and >>>>> compromise with people who are looking for a solution like this? Or a= re 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 wrote: >>>>> >>>>>> > 1) Allowing node >>>>>> >>>>>> Who said anything about allowing? Everyone is allowed to do whateve= r >>>>>> 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 do-- 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 (which is, in fact, a big par= t of >>>>>> the issue here). To think otherwise is to be stuck in a kind of se= rf >>>>>> thinking where you can only do what other people allow you to do. T= hat 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 any= 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-pr= ivacy >>>>>> efforts because they would inevitably moot the efforts expected gett= ing >>>>>> into peoples business and filtering their transactions. >>>>>> >>>>>> You don't have to agree, and you're free to do your own thing just a= s >>>>>> I'm free to say that I think it's a bad direction. From the very be= ginning >>>>>> Bitcoin has stood against the freedom to transact being overridden >>>>>> by some admin based on their judgment call weighing principles again= st >>>>>> other concerns, or at the behest of their superiors. So many Bitcoi= ner >>>>>> will stand against, route around, and do what they can do to make >>>>>> ineffectual the blocking of consensual transactions. It might not s= eem as >>>>>> many at the moment, but the pro-privacy and anti-censorship 'side' d= oesn't >>>>>> have a paid PR and influence campaign, but it also doesn't matter s= o much >>>>>> because Bitcoin takes advantage of the nature of information being e= asy to >>>>>> spread and hard to stifel and it doesn't that that huge an effort to= route >>>>>> around censorship efforts. >>>>>> >>>>>> There are elements of anti-censorship in Bitcoin that have been so >>>>>> far underdeveloped. It's unfortunate that their further development= might >>>>>> be forced at a time when efforts are needed on other areas. But per= haps >>>>>> 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 >>>>>> wrote: >>>>>> >>>>>>> Sorry Greg, could you please elaborate further on your ideas? Some >>>>>>> are not exactly clear: >>>>>>> >>>>>>> 1) Allowing node runners to configure their node as they please and >>>>>>> refuse to relay some txs is considered authoritarian, censorship, a= nd an >>>>>>> attempt to regulate third parties conduct. On the other hand, forci= ng nodes >>>>>>> to merge towards a single shared configuration (by preventing them = to block >>>>>>> txs) is not considered authoritarian because this imposition does n= ot >>>>>>> discriminate towards any txs and is thus non-authoritarian? Did I g= et 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 this >>>>>>> homogenous state to be? If we don=E2=80=99t reach this state throug= h this >>>>>>> distributed/independent mechanism, then how are we to reach this st= ate? Who >>>>>>> gets to decide and steer the direction so that we all converge towa= rds this >>>>>>> homogenous state? One of the strongest aspects of bitcoin is the f= act that >>>>>>> no single party can force a change/direction, and the network has t= o >>>>>>> somehow reach a shared agreement through independent decision maker= s who >>>>>>> act in what manner they think is best. The proposed BIP seems to be= aligned >>>>>>> with such a principle, I fail to see any authoritarian aspect 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 >>>>>>> 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 carryi= ng local >>>>>>>> customizations as many miners do. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland >>>>>>>> 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 Gre= g Maxwell >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> This appears to substantially misunderstands the purpose of the >>>>>>>>>> mempool broadly in the network-- it's purpose is to model what w= ill get >>>>>>>>>> mined. If you're not doing that you might as well set blocks on= ly. >>>>>>>>>> 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 leani= ngs. -- >>>>>>>>>> though I am unsure if 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, >>>>>>>>>>> >>>>>>>>>>> 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 lot= s of >>>>>>>>>>> different node implementations/forks when there are disagreemen= ts. >>>>>>>>>>> >>>>>>>>>>> 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-44c9= -80f0-6c68c6554f56n%40googlegroups.com >>>>>>>>>>> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> 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+...@googlegroups.com. >>>>>>>>> To view this discussion visit >>>>>>>>> https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a= 895-b48664babbfcn%40googlegroups.com >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>>> 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/CAAS2fgRABqRe1j6xzW0u= hVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>> -- > 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/4968c87a-ab0a-47a7-9d38-e53f= dae1630bn%40googlegroups.com > > . > --=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/= CAAS2fgQ%3D4525YrjQabOutRX56V1Bw7VPf91cJU9oCdoO96DKJg%40mail.gmail.com. --0000000000001ab86306401ff6ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0or that allowing users to set=20 their own relay policy will

They're alread= y allowed to. No one could even stop them if they wanted to.

=
This repeated framework of things being about what people are al= lowed to do is distorting people's thinking.

W= hen I say people should not do a thing, or others shouldn't waste their= time building tools for the thing-- or even that the thing causes harm thi= s has absolutely nothing to do with the view of preventing them from doing = it, or even preventing others who want to help from helping them.=C2=A0

The two are entirely distinct.=C2=A0 =C2=A0But I gues= s understanding the difference between something that you ought not do like= cram unrelated data into Bitcoin with something that should (or even can) = be stopped is nuance that is just entirely missing in the advocacy of censo= rs.

I don't care if they run knots any more th= an I care if they eat rocks.=C2=A0 It's sad if it ends up harming them,= it's sad if they were=C2=A0deceived=C2=A0into doing something that is = against their own interest. Hopefully it's fine but it's ultimately= not my problem.=C2=A0 My node protects me, and if enough censors trash up = the p2p network they'll simply be routed around (e.g. by forming an alt= ernative network, by detecting and preventing them from saturating connecti= ons if they continue/repeat the "garbageman" connection flooding = DDOS attacks,=C2=A0 and so on).=C2=A0 I suppose it does matter somewhat if = usage was widespread enough to create a DDOS on the non-censoring bitcoin n= odes requires expending development resources to work around harm,=C2=A0 bu= t that's mostly development that ought to happen anyways and anti-censo= rship is a fun thing to rally around and probably a better use of time then= some other initiatives.=C2=A0=C2=A0



On Wed, Oct 1, 2025 at 7:57=E2=80=AFPM 'Aiden McClel= land' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
=
Greg,=C2=A0

You've 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 rig= ht 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= McClelland


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

Black and white thinking is no= t very helpful=C2=A0here particularly because the goals of pro-filtering an= d anti-censorship aren't exact opposites.

A wi= dely censored world would greatly degrade the value of Bitcoin,=C2=A0partic= ularly if the censors managed to enlist significant miners.=C2=A0 It would = be 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 = completely lawful targets of operation chokepoint=C2=A0with USD, people wou= ld still route around Bitcoin censorship.=C2=A0 =C2=A0But why even use Bitc= oin if it's in a similar space of your transactions being capriciously = blocks, your funds frozen, etc. as exists with legacy infrastructure?
=

But the irony is that the traffic that people most desp= erately want to stop would be among the least impeded-- already today the s= pam traffic exists at all because it's well funded (or really existed a= year ago, we are long past the huge spam floods-- they were depleted by co= sts and fizzled as predicted--=C2=A0and Ocean Mining is fighting yesterday&= #39;s battle. But what exists exists because its well funded).=C2=A0 Meanwh= ile 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 pote= ntially targeting him, his activities, or his payees.=C2=A0 The effect of c= ensorship is basically to require people to learn how to be money launderer= s to freely transact, and those who don't suffer.

<= div>The case is even stronger re: the recently filtering arguments because = unlike some consensus rule anyone can just mine a block (rent hashpower, yo= u don'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 w= as already not working.=C2=A0 =C2=A0So in some sense there are arguments ge= tting 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 statemen= t of fact rather than speculation.=C2=A0 But basically the 'bad' tr= affic has a lot easier time than more innocent traffic, which is part of wh= y filters can be both ineffective and dangerous.=C2=A0 It's also the ca= se 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= '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 pe= ople's transactions aren't our business, even if they're stupid= or drive fees up a bit for some periods and create annoyances, because the= alternative is easily much worse.


=




=




=

=C2=A0=C2=A0




On Thu, Sep 25, 2025 at 9:26=E2=80=AFPM Aiden McClelland = <m...@drbonez.dev> wrote:
>I have n= o idea what you're referring to there.

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

Best,
Aiden McClelland
<= br>
On Thu,= Sep 25, 2025, 3:14=E2=80=AFPM Greg Maxwell <gmax...= @gmail.com> wrote:
I am not a core developer. I have not been= for some eight years now.=C2=A0 =C2=A0

>=C2=A0= that you yourself are worried they will reach the 80% needed

=
I have no idea what you're referring to there.=C2=A0 If lots= of people run nodes that screw up propagation they'll be routed around= .=C2=A0 I developed the technical concepts required to get nearly 100% tx c= overage even if almost all nodes are blocking them quite a few years ago ( = https://arxiv.org/pdf/1905.10518 ), but deployment of t= he implementation has gone slow due to other factors (you know, such as the= most experienced=C2=A0developers 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 vulnerabiliti= es that should be closed anyways-- after all anyone at any time can just sp= in up any number of "nodes" that behave in arbitrary=C2=A0ways, a= t ant time.=C2=A0 It's been a lower priority because there are other co= untermeasures (addnode-a-friend, manually setbanning=C2=A0bad peers, etc.) = and aforementione distractions.

>=C2=A0censorsh= ip due to widespread use of transaction filters is a bad thing (I'm not= really taking a stance on that right now).

I woul= d point you to the history of discussion on Bitcoin starting back with Sato= shi's earliest announcements, and perhaps to help you understand that i= f you want that what you want isn't bitcoin.=C2=A0 If after considerati= on you don't think censorship wouldn't be very bad, then really you= and I have nothing further to discuss.

>=C2=A0= are you willing to work with and compromise 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

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&g= t; wrote:
Greg,=C2=A0

Let me assume for a minute, for the sake of argument, that I agree tha= t transaction censorship due to widespread use of transaction filters is a = bad thing (I'm not really taking a stance on that right now). It is an = irrefutable fact that a very large portion of the user base wants to filter= transactions. So many so, that you yourself are worried they will reach th= e 80% needed to prevent certain types of transactions from propogating. Wou= ldn't it then be worse if these 80% of users went and ran an alt= ernative implementation, most likely written by it's most radical suppo= rters? Or even worse still, felt compelled to coordinate a UASF to block th= ese transactions entirely?

I at no point intended to insinuate that you or any other core contribut= er be compelled to implement a proposal like this. It's up to its suppo= rters to do so. The real question is, are you willing to work with and comp= romise with people who are looking for a solution like this? Or are you goi= ng to force them to abandon the Core project entirely?

=
Best,
= Aiden McClelland

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

<= /div>
Who said anything about allowing?=C2=A0 Ever= yone is allowed to do whatever they want.=C2=A0 Drill a hole in your head i= f you like, not my concern.=C2=A0 None of this thread is about what people = are allowed to do-- that's off the table.=C2=A0 The design and licensin= g of Bitcoin is such that no one gets 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 be stuck in a kind of serf thinking wher= e you can only do what other people allow you to do.=C2=A0 That has never b= een what Bitcoin was about.

Rather, the question is should people who= care about Bitcoin spend their time and money developing infrastructure th= at would be useful, even primarily useful, for censorship.=C2=A0 I say no.= =C2=A0 Especially because any time spent on it is time away from anti-censo= rship pro-privacy tools and because the effort spent doing so would undermi= ne anti-censorship and pro-privacy efforts because they would inevitably=C2= =A0moot the efforts=C2=A0expected getting into peoples business and filteri= ng their transactions.

You don't have to agree, and you're fr= ee to do your own thing just as I'm free to say that I think it's a= bad=C2=A0direction.=C2=A0 From the very beginning Bitcoin has stood agains= t the freedom to transact being=C2=A0overridden by some admin based = on their judgment call weighing principles against other concerns, or at th= e behest of their superiors.=C2=A0 So many Bitcoiner will stand against, ro= ute around, and do what they can do to make ineffectual the blocking of con= sensual=C2=A0transactions.=C2=A0 It might not seem as many at the moment, b= ut the pro-privacy and anti-censorship 'side' doesn't have a pa= id PR and influence campaign,=C2=A0 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 to ro= ute around censorship efforts.

There are elements = of anti-censorship in Bitcoin that have been so far underdeveloped.=C2=A0 I= t's unfortunate that their further development might be forced at a tim= e when efforts are needed on other areas.=C2=A0 But perhaps they wouldn'= ;t get done without a concrete motivation. Such is life.



=


On Thu, Sep 25, 202= 5 at 9:21=E2=80=AFAM yes_please <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= refuse to relay some txs is considered authoritarian, censorship, and an a= ttempt to regulate third parties conduct. On the other hand, forcing nodes = to merge towards a single shared configuration (by preventing them to block= txs) is not considered authoritarian because this imposition does not disc= riminate towards any txs and is thus non-authoritarian? Did I get the reaso= ning 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 st= ate through distributed independent nodes who decide=C2=A0independently on = what they prefer this homogenous state to be? If we don=E2=80=99t reach thi= s state 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= converge 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= decision makers who act in what manner they think is best. The proposed BI= P seems to be aligned with such a principle, I fail to see any authoritaria= n aspect here.=C2=A0

3)=C2=A0I share your sentiment and the aim to have a homogen= ous mempool state, but I am skeptical of the manner in which we are to achi= eve 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 &= lt;gmax...@gmail.com> wrote:
So that when the "consistent state" changes a= s 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.


On Wed, Sep 24, 2025 at 8:47=E2=80=AFPM Aiden McClelland <m...@drbonez.dev> wrote:
=
If mempool consiste= ncy across the network is all that is important, why allow any configuratio= n of mempool relay policies at all?

On Wednesday, September 24, 2025 at 12:47= :28=E2=80=AFPM UTC-6 Greg Maxwell wrote:
This appears to substantiall= y=C2=A0misunderstands the purpose of the mempool broadly in the network-- i= t's purpose is to model what will get mined.=C2=A0 If you're not do= ing that you might as well set blocks only.=C2=A0 Significant=C2=A0discrepa= ncies=C2=A0are harmful to the system and promote centralization=C2=A0and fa= il to achieve a useful purpose in any case.=C2=A0 What marginal benefits mi= ght be provided do not justify=C2=A0building and deploying the technologica= l=C2=A0infrastructure=C2=A0for massive censorship.

If you think this is important, I advise you to select another cryptocurre= ncy which is compatible with such authoritarian=C2=A0leanings.=C2=A0 -- tho= ugh I am unsure if any exist since it is such a transparently pointless dir= ection.


On Wed, Sep 24= , 2025 at 6:30=E2=80=AFPM Aiden McClelland <m...@drbonez.dev> wrote:
<= div>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 co= mmunity 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 Quic= kJS, 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= 9;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/= cbdab6fa-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/= de4dae19-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.com/d/msgid= /bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmai= l.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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/4968c87a-ab0a-47a7-9d38-e53fdae1630bn%40googlegrou= ps.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/bitcoindev/CAAS2fgQ%3D4525YrjQabOutRX56V1Bw7VPf91cJU9oCdoO96DKJg%40ma= il.gmail.com.
--0000000000001ab86306401ff6ce--