Delivery-date: Thu, 25 Sep 2025 19:47:05 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v1yUB-0002K4-Hl for bitcoindev@gnusha.org; Thu, 25 Sep 2025 19:47:05 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3641593a391sf1681007fac.3 for ; Thu, 25 Sep 2025 19:47:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1758854818; cv=pass; d=google.com; s=arc-20240605; b=bIiCViBmMGc+PMNjnxNGJs8GGOlhF1ut1TUcXVu75H9PWmVK9pM7lzDEkqWlGs+KIZ rXyjTe+tBxMY9vnVxCX/vF13RRBOFHQRMyqRKtECHuZiMNT5cTY59mDR1S5/Zzlgv4cq 6g4xtmYOWtPohfhegAX40LwP0h076QfkrAi1LkYJxRGmPa7/CWZ3QcYycG7MsBzN802A 6H1mMFvPl66PFVzrtPDWHw4Pej9dLJwyAO4F+vyDNwivp0twqYYg0iUJY0vu8U0Fj9rG qNihweh9R2ZE+udsYcSqykP6mzbPBbOFVeeFUmrXbJQ+PEZiCsezlhi4cNytNPBDx8l6 vWYw== 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; bh=cq/TO4aXvZnbj3nW3Fgy80P4Y/wMeTYSuZnmi/LO0+o=; fh=s0YZl4WG7vnMLZ6g4JT4GtFyWCHyx1ZWWZWb4vlYnKo=; b=ft98qo+kxkRL/a5o+oNg4p/YYLNz4nrV4FVrZnybge3nGDnfALpVRj9okrPtimhZDm 5ExqGDrKPj3DUoKkOjhCVH3pEw8eqOe4ILOLUcw8W3SNjS9hiiRVkzsWCilffxi8IUoX Ms0xZvTh0g9o3mn/QS2BnoFy9vBFQF3iUkGcnRXNNflRCUHpSswEfRFYGZStZUSbukD1 c4FYEAbm4DHtH10HlNHaMcaQ8GD1qlH6kijPTZFpgC38s1+Ow3nn1ncrVLH+5Ro6k+99 UMH8JssOuCnBFO8N397/wTqZvEU79RC3p2Ql00S+LmjUCL0BHn1Nq1Nigkbc6l4Lh703 1SPA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of gagglehoof@gmail.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=gagglehoof@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=drbonez.dev DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1758854818; x=1759459618; 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=cq/TO4aXvZnbj3nW3Fgy80P4Y/wMeTYSuZnmi/LO0+o=; b=vTmaIA3HFZtDcGtkbZsX373VK1Hl6T6R8jFjTzwL+/upD4UVeITgPd1qCO10nGUHYD r7p88d0SOQhTOY5QziI464n/8BBQF3hxyXbcvOqftYlmfrecC0wT1QwgKmc0zxmLhIWV 70MH2HDKsgv59BKKRI2tqD3GHOTKdRBDcfMh9DjhpirO3TxxNRtdp8kOIsxCW8xmrJBS IKu/ObkaJf0U6bjmBFVksEscXoGi3CgMPCZ45bwUKCk2IfNTn2DcQ3aeX2RoznpWAvcs Sd6tRZDz/JFFoFQQqXmpa6JTQ4Er8GYiW6mhFOJSOYf2MqqGjWG2tfLdKN/6c4Glolcl rqow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758854818; x=1759459618; 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=cq/TO4aXvZnbj3nW3Fgy80P4Y/wMeTYSuZnmi/LO0+o=; b=Vcd/NUzVCJB+WnVjG4b3y4/hbO4akkcTLqU4PCxC98o5iyYvApayPqXaGvcTPN0v/4 xCgFjoD8NIJPDI3h9PnjyZzt/pY+OSrDNvO0lcol710x9hvsKfArJS46hhZ1AaWxjEuE RretceQ9UOfEmMHHnsaxwJIUOVI0NipErMTu+cqj4Rvpsy3MgQgbP7MLoSq1lzUWdIvG qY0wMsAuSta0+dk0WlykexA4P67joB9qEhiM9d/qBnK/TAj9Ij0gthpfIhfHXskgyQuc 3J5Qf2ikCx+PIN7VOjKrgM8xcEnRPfMQmjvKaWR8oECFVfXkeopNd+vpbBAYO32pJwZd bCeg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVhmeec58iT8yBrE6sUF1PSMG0eb+Nldkt6e9vYNkTiLPXX7dpIV+ymrIjkOe8uiHYozlb/mZYqRFrk@gnusha.org X-Gm-Message-State: AOJu0YwRtgN2BOmUMPDNUoqNbMhuPTXV32DOljp1gFmfMxaTQy9ZxaKg 7FPSXkSdiE1lW4n73RCzVWxgXetiYlHFzwLrJiVaVGrqMjLL6gXMe/Sx X-Google-Smtp-Source: AGHT+IE5GbcxKzXEr+8OBsu05+wPWSIRMym6rL9zQ8iN19x19zoxUpnS5aIOgfAvEDLcVw3XJw4eeA== X-Received: by 2002:a05:687c:2186:b0:344:5013:4bfc with SMTP id 586e51a60fabf-35eec476397mr2898713fac.43.1758854817306; Thu, 25 Sep 2025 19:46:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4Wgg0KXfhLeEhiHUITItiR2sLdAxNPNHxNXJ/xQ83H6Q==" Received: by 2002:a05:6871:3a09:b0:319:c62c:c8e0 with SMTP id 586e51a60fabf-35ec120e0c1ls936267fac.0.-pod-prod-07-us; Thu, 25 Sep 2025 19:46:53 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCUAmKmTIhMCWOFmCpP1Xb88yTjKoB5tB8wjSfWcgXtR/B1erd0Q2iS2/TiDtPsN7CH42HEdIrTsqSPm@googlegroups.com X-Received: by 2002:a05:6808:1825:b0:43b:55c9:3a2d with SMTP id 5614622812f47-43f4cf31340mr2862305b6e.27.1758854813394; Thu, 25 Sep 2025 19:46:53 -0700 (PDT) Received: by 2002:a05:6504:604b:b0:2c0:aeab:e1f7 with SMTP id a1c4a302cd1d6-2c8266c4d25msc7a; Thu, 25 Sep 2025 19:17:32 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCV1xN6eV8UkxZ1sjLKVIjuqBTN0ZgHV2JA1UiJtaMtxeBuNs2jG08q1haZFRYgeeiXiMFL3qvmJRnUv@googlegroups.com X-Received: by 2002:a05:6512:3d10:b0:57a:6d7d:dd7b with SMTP id 2adb3069b0e04-582d092f0f7mr1582885e87.8.1758853049448; Thu, 25 Sep 2025 19:17:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1758853049; cv=none; d=google.com; s=arc-20240605; b=NcLt6zPqyTNOsiwnk9pdvZazwtODSc8fFQf6gF3EvFCIumcLNAeBsWMKzIliUhYfo0 wokTiloZjcOqviEra0iGiVGcUPuIJv6cLyci27ycQjFCtEnW7H43RbFhsGyy84WlGgE9 ljm6yo11kef8x9Xrnx8bvZr+CXUhgsp3gpgkLaKEAl4KYYyW/8ofNSs7Z73RVwPwgd5C oJQng+QQQd9hmYVJ+bwmpn+5RvdAewqL6nZssMAHVwe+5MUsoX+IXtYD+yBTHSezY6BA 25WjaVxBDbDUaWP7FnXrO82qv2Hgg5rZvkWFfPbBgbs4OvQXps7ljr2HVKFwd4JzJaoC 7Z3g== 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; bh=+t2SLpFnu8rSUEtJqLdl3BeCASghim4mf3xYi+VXgzE=; fh=Pdo+jSc90GtFeVdnJPqlqJQLWHrihkxv7GxwaVVHAcI=; b=HSxdwa9r5soLISE+Mdaku40yYeBIpxB+iuteQQkOa3Ftzvkfie7sNFrsYzzLuUKB4J 7Mkyc3sa06hgeC+7us50NffzH+RD9SpwM0ZZBNcVJiER+kIIgreRhKAlbQucDYj1xMmP aBxhwq81XUuxZkrdKyRyzIuKpb6Ry15SowETmMLN28aulJdjRJRMZFGMGkXPpL6RTNnM 9dqXt7htoclMJnmP3cHf9KZYpWjycwUc01jPUbI5HcfUuPQjTgtdzg0P+r6Kt6o5GQLX L+UyZuWIhI7NWYR9XifeRh2gX2VVYTG2s7/RjYMnYHeoEtocfk/H7KbQWm+pCFcrvGni ZJ0g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of gagglehoof@gmail.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=gagglehoof@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=drbonez.dev Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com. [209.85.218.44]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-583170ecb41si60703e87.7.2025.09.25.19.17.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Sep 2025 19:17:29 -0700 (PDT) Received-SPF: pass (google.com: domain of gagglehoof@gmail.com designates 209.85.218.44 as permitted sender) client-ip=209.85.218.44; Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-b2ef8e00becso335210766b.0 for ; Thu, 25 Sep 2025 19:17:29 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVrvQIIprMSaCq6WZHgMADx+wGBLG9NZLsp571m7nyenwy7mEoWZXzmXAXGyMpAsW4NxIfNhKRjmG+I@googlegroups.com X-Gm-Gg: ASbGnctEbTQuZl4pzH7sAFfsPbGrUAkuTx18Z1k+V2pXrz5SpjbeE0UhLGGbU8IaQPr LQiq3GzUjXZnRa760Q//reIxOrUQ3J0CFqtDQXlj4p0NhYCEuIvDhQ2Kdl+ipfWK/NH6oWP5asn FUK4J/bgy+WvZ1KLzpQnOdLTWNT9vGpzgCur663bl8h70mf7fvsk6Vr4xVhlJHY3p8++F2bY4b6 xVGIBFTXl2U57fN3sjmpRxjwOmsnAHiwrv0mhsCA2IRqGZYH/FeD4g3RtrxKSOrMK1UzW+eS+bw 908Sq8AldHmg1HgL3JE36NCnSEQx0egnMzwm3GER/yK1xwdN/2EwJ7dno2MXVP5bBzFC6E9j9rQ EB6vUUHtEIPHl7jwIMV/vXK4m0bUuo8zkYIQ4aEenWWA+TxsnYgWuqpABkR+aIxxjkayhUgw= X-Received: by 2002:a17:907:8689:b0:b07:de2c:1268 with SMTP id a640c23a62f3a-b34ba147a5fmr525746566b.5.1758853048468; Thu, 25 Sep 2025 19:17:28 -0700 (PDT) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-634a3ae3112sm2026362a12.25.2025.09.25.19.17.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Sep 2025 19:17:27 -0700 (PDT) Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-b256c8ca246so326935666b.1 for ; Thu, 25 Sep 2025 19:17:27 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCU4mljjvmlv/Oy/bNFoj+I7AZYVyZcVHQdbhpie3iUZXPuu6BU0kFa54K+0B7EvWVSt659OfsaYAz85@googlegroups.com X-Received: by 2002:a17:906:c150:b0:af9:eace:8a52 with SMTP id a640c23a62f3a-b34be8c4a31mr607335666b.50.1758853046974; Thu, 25 Sep 2025 19:17:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aiden McClelland Date: Thu, 25 Sep 2025 20:17:14 -0600 X-Gmail-Original-Message-ID: X-Gm-Features: AS18NWAulqT8WJvJ4YaPp6woXzTqu9_CkKXxVuk8UYS3Ev9dx5UTSS5NXMX8bRk Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts To: Chris Riley Cc: Greg Maxwell , yes_please , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000013c04e063faae3d2" X-Original-Sender: me@drbonez.dev X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of gagglehoof@gmail.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=gagglehoof@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=drbonez.dev 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.7 (/) --00000000000013c04e063faae3d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Chris, Can you elaborate further on what economic incentives there would be towards filter standardization? Thanks, *Aiden McClelland* On Thu, Sep 25, 2025, 8:06=E2=80=AFPM Chris Riley wrote: > One concern is that even if filter scripts are local and opt-in initially= , > social or economic pressure will push them toward "standardization"=E2=80= =94and > from there toward implicit coercion=E2=80=94so the risk of soft censorshi= p > increases over time. If relay policies start drifting, the mempool ceases > to reflect miner behavior and fragments into incompatible local views, > undermining its role as a shared substrate. Instead of decentralizing > control, filter modules may simply externalize it: those who author > =E2=80=9Cpopular=E2=80=9D (perhaps through demagoguery) filters gain outs= ized influence > over what the rest see. The path to robustness is not more policy layers, > but maintaining a minimal, common relay system. > > On Thu, Sep 25, 2025 at 6:29=E2=80=AFPM 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+unsubscribe@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+unsubscribe@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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg8= 4tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.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/= CAOSz24SZ9x_c%3D3eXY0McxQbivbG5zHOfTiaZjR%2B%3DuAju4%2BpC3Q%40mail.gmail.co= m. --00000000000013c04e063faae3d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Chris,=C2=A0

Can you elaborate further on what economic incentives there wou= ld be towards filter standardization?

Thanks,
Aiden McClelland

On Thu, Sep 25, 2025, 8:06=E2=80=AFPM Chris Riley <criley@gmail.com> wrote:
One concern is that even = if filter scripts are local and opt-in initially, social or economic pressu= re will push them toward "standardization"=E2=80=94and from there= toward implicit coercion=E2=80=94so the risk of soft censorship increases = over time. If relay policies start drifting, the mempool ceases to reflect = miner behavior and fragments into incompatible local views, undermining its= role as a shared substrate. Instead of decentralizing control, filter modu= les may simply externalize it: those who author =E2=80=9Cpopular=E2=80=9D (= perhaps through demagoguery) filters gain outsized influence over what the = rest see. The path to robustness is not more policy layers, but maintaining= a minimal, common relay system.

On Thu, Sep 25, 2025 at 6:29=E2=80=AFPM= Greg Maxwell <gmaxwell@gmail.com> wrote:
"There are l= evels of survival we are prepared to accept."

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

A widely censored world would greatly degrade th= e value of Bitcoin,=C2=A0particularly if the censors managed to enlist sign= ificant miners.=C2=A0 It would be routed around at great cost, and with muc= h less freedom provided for the world.=C2=A0 But just like people continue = to buy racy magazines or other completely lawful targets of operation choke= point=C2=A0with USD, people would still route around Bitcoin censorship.=C2= =A0 =C2=A0But why even use Bitcoin if it's in a similar space of your t= ransactions being capriciously blocks, your funds frozen, etc. as exists wi= th legacy infrastructure?

But the irony is that th= e traffic that people most desperately want to stop would be among the leas= t impeded-- already today the spam traffic exists at all because it's w= ell funded (or really existed a year ago, we are long past the huge spam fl= oods-- they were depleted by costs and fizzled as predicted--=C2=A0and Ocea= n Mining is fighting yesterday's battle. But what exists exists because= its well funded).=C2=A0 Meanwhile 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 hi= s payees.=C2=A0 The effect of censorship is basically to require people to = learn how to be money launderers to freely transact, and those who don'= t suffer.

The case is even stronger re: the recent= ly filtering arguments because unlike some consensus rule anyone can just m= ine a block (rent hashpower, you 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 was already not working.=C2=A0 =C2=A0So in so= me sense there are arguments 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 statement of fact rather than speculation.=C2=A0 But= basically the 'bad' traffic has a lot easier time than more innoce= nt traffic, which is part of why filters can be both ineffective and danger= ous.=C2=A0 It's also the case that existing filter efforts are not back= ed by civil litigation or state mandates, but building infrastructure creat= es an obvious stepping stone to that (in part because of the insufficient e= ffectiveness of filtering)-- it's just a bad road that will almost inev= itably lead to more escalations.=C2=A0 =C2=A0Bitcoin is just better of adop= ting the position that other people's transactions aren't our busin= ess, even if they're stupid or drive fees up a bit for some periods and= 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 <me@drbonez.dev> wrote:
>I h= ave no idea what you're referring to there.

=
It's something I inferred from your primary arg= ument that seems to be that user-configurable filters are bad because they = would cause censorship. But it also sounds like you're saying such filt= ers 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,
<= font face=3D"courier new, monospace">Aiden McClelland

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

>=C2=A0that you yourse= lf are worried they will reach the 80% needed

I ha= ve 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 devel= oped the technical concepts required to get nearly 100% tx coverage even if= almost all nodes are blocking them quite a few years ago ( https://arxiv.org/pdf/1905.10518 ), but deployment of the implementa= tion has gone slow due to other factors (you know, such as the most experie= nced=C2=A0developers being hit with billions of dollars in lawsuits as a co= st for their support of Bitcoin)... I expect if censoring actually becomes = widespread that technological improvements which further moot it will be de= veloped.

These are just vulnerabilities that shoul= d be closed anyways-- after all anyone at any time can just spin up any num= ber of "nodes" that behave in arbitrary=C2=A0ways, at ant time.= =C2=A0 It's been a lower priority because there are other countermeasur= es (addnode-a-friend, manually setbanning=C2=A0bad peers, etc.) and aforeme= ntione distractions.

>=C2=A0censorship due to w= idespread use of transaction filters is a bad thing (I'm not really tak= ing a stance on that right now).

I would point you= to the history of discussion on Bitcoin starting back with Satoshi's e= arliest announcements, and perhaps to help you understand that if you want = that what you want isn't bitcoin.=C2=A0 If after consideration you don&= #39;t think censorship wouldn't be very bad, then really you and I have= nothing further to discuss.

>=C2=A0are you wil= ling 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 <me@drbonez.dev> wrote:
Greg,=C2= =A0

Let me assume for a = minute, for the sake of argument, that I agree that transaction censorship = due to widespread use of transaction filters is a bad thing (I'm not re= ally taking a stance on that right now). It is an irrefutable fact that a v= ery large portion of the user base wants to filter transactions. So many so= , that you yourself are worried they will reach the 80% needed to prevent c= ertain types of transactions from propogating. Wouldn't it then be w= orse if these 80% of users went and ran an alternative implementation, = most likely written by it's most radical supporters? Or even worse stil= l, 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 implem= ent a proposal like this. It's up to its supporters to do so. The real = question is, are you willing to work with and compromise with people who ar= e looking for a solution like this? Or are you going to force them to aband= on the Core project entirely?

Best,
Aiden McClelland

On Thu, Sep 25, 2025, 2:03=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com> wrote:
>=C2=A01)=C2=A0Allowing node
=
Who said an= ything about allowing?=C2=A0 Everyone is allowed to do whatever they want.= =C2=A0 Drill a hole in your head if you like, not my concern.=C2=A0 None of= this thread is about what people are allowed to do-- that's off the ta= ble.=C2=A0 The design and licensing 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 stu= ck in a kind of serf thinking where you can only do what other people allow= you to do.=C2=A0 That has never been what Bitcoin was about.
<= div>
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.=C2=A0 I say no.=C2=A0 Especially because any time spent o= n it is time away from anti-censorship pro-privacy tools and because the ef= fort spent doing so would undermine anti-censorship and pro-privacy efforts= because they would inevitably=C2=A0moot the efforts=C2=A0expected 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 fr= ee to say that I think it's a bad=C2=A0direction.=C2=A0 From the very b= eginning Bitcoin has stood against the freedom to transact being=C2=A0overridden by some admin based on their judgment call weighing 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 mak= e ineffectual the blocking of consensual=C2=A0transactions.=C2=A0 It might = not seem as many at the moment, but the pro-privacy and anti-censorship = 9;side' doesn't have a paid PR and influence campaign,=C2=A0 but it= also doesn't matter so much because Bitcoin takes advantage of the nat= ure of information being easy to spread and hard to stifel and it doesn'= ;t that that huge an effort to route around censorship efforts.
<= br>
There are elements of anti-censorship in Bitcoin that have be= en so far underdeveloped.=C2=A0 It's unfortunate that their further dev= elopment might be forced at a time 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, 2025 at 9:21=E2=80=AFAM yes_please <caucasianjazz12@gmail.com> wrote= :

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

= 1)=C2=A0Allowing node runners to configure thei= r node as they please and refuse to relay some txs is considered authoritar= ian, censorship, and an attempt to regulate third parties conduct. On the o= ther hand, forcing nodes to merge towards a single shared configuration (by= preventing them to block txs) is not considered authoritarian because this= imposition does not discriminate towards any txs and is thus non-authorita= rian? Did I get the reasoning correctly here?

2) If the aim is to = have a homogenous mempool state and to model what will get mined, shouldn= =E2=80=99t we reach this state through distributed independent nodes who de= cide=C2=A0independently on what they prefer this homogenous state to be? If= we don=E2=80=99t reach this state through this distributed/independent mec= hanism, then how are we to reach this state? Who gets to decide and steer t= he direction so that we all converge towards this homogenous state?=C2=A0 O= ne 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 ag= reement through independent decision makers who act in what manner they thi= nk is best. The proposed BIP seems to be aligned with such a principle, I f= ail to see any authoritarian aspect here.=C2=A0

3)=C2=A0I share your sentiment an= d the aim to have a homogenous mempool state, but I am skeptical of the man= ner in which we are to achieve this according to the ideas you have here ex= pressed (namely not through a distributed independent organic manner)


Respectf= ully, yes_please=C2=A0=C2=A0=C2=A0


On Thu, Sep 25, 2025 at 12:50= =E2=80=AFAM Greg Maxwell <gmaxwell@gmai= l.com> wrote:
So that when the "consistent state" ch= anges 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 McClelland <me@drbonez.dev> wrote:
If mempool consistency across the netw= ork is all that is important, why allow any configuration of mempool relay = policies at all?

On Wednesday, September 24, 2025 at 12:47:28=E2=80=AFPM UTC= -6 Greg Maxwell wrote:
This appears to substantially=C2=A0misundersta= nds the purpose 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 blocks only.=C2=A0 Significant=C2=A0discrepancies=C2=A0are har= mful to the system and promote centralization=C2=A0and fail to achieve a us= eful purpose in any case.=C2=A0 What marginal benefits might be provided do= not justify=C2=A0building and deploying the technological=C2=A0infrastruct= ure=C2=A0for massive censorship.

If you think this= is important, I advise you to select another cryptocurrency which is compa= tible with such authoritarian=C2=A0leanings.=C2=A0 -- 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:
--
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 bit= coindev+...@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+un= subscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/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+un= subscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msg= id/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gm= ail.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.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU= 86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.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/bitcoindev/CAOSz24SZ9x_c%3D3eXY0McxQbivbG5zHOfTiaZjR%2B%3DuAju4= %2BpC3Q%40mail.gmail.com.
--00000000000013c04e063faae3d2--