From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 19 May 2026 19:04:28 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPWIL-0000M1-Pl for bitcoindev@gnusha.org; Tue, 19 May 2026 19:04:27 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-69d0a1cb4a1sf12658330eaf.0 for ; Tue, 19 May 2026 19:04:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779242660; cv=pass; d=google.com; s=arc-20240605; b=gpgK2kzx+zhDJjSaCJ/M9ipvDM7dc1pyuFF85njMfN30MvM4DFQ/SYF1QdtWcITL34 maIXeOKSc10zX7OgeVhvzh4g896EKKUXz963cX33SOZ8hTCcj9viX8nG8PDjMYlNRTmF SRMnQBPQ85k/h6MxLa9STk3y4cZI0aIzZoygm+NgUqXXYRVaA1ASykYTn3FBDu5Z95e0 OOSdyChqeCqpNdhu43Mvxn3eVavvYDRphgPmtxD9MjP20ZFlq04zdkyJug8dlP74o01s bb5TpGjS7EHgtPOIU4RDU2ZmI80yB5R+l9ClIVOlkX9w+ir+HyYwyIz3uCIsWYwi7aQx ySYw== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=pAyF4kmuO9OL22uyVM8ge0Yva3P7lGY8OyUoPOQHDJ0=; fh=AWEMqRDt4j7lQO7plr3MqC1v73ped2KcKMzJtC+K+EE=; b=Tzpa/bxmGViqv4ATkawn+IDpVRdbw8iwDsN5NE/cwuP9Gx9A2SXzv/CQ6I3kniB4F1 W9uLvJIuJDWTm5gpZv3bHu6e51U798ucGVNRrRdruXUEMAg652TijwBYS+hgNIPOM1bj 1yB+JewSXmWdh6Mmgu2Yazcp2ud42Mj2SDpmQwMoFYWA5AEpx74JshI+1P7YLR6lrSsz p7phAOn0KiWPw7YsKqW90J5Obi4wCz+LvuVI7iaSTZPI6VDMXHBs78AMnThTAbCYUEqK vbZ6/zlTAXvyps5zah1d4AqUhnawrio6Qx0e9LU8ujDfyTGUTtSNiRmZ5JFRcQdPoPtd iBiQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=XLseJYCk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.104 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779242660; x=1779847460; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=pAyF4kmuO9OL22uyVM8ge0Yva3P7lGY8OyUoPOQHDJ0=; b=WnZIgrdoQC8ON45VrcCfMYgi1U4vuLb4rih46tKBmGy48PQVjoFeCyifq4fL+U8QqZ Y6dp+yrImj61tRIb3mpUOPbckbPkfulT4Aj1J3Db5K2GR/HlgpbKSmTyXE8Mt4cxt8Dc VLixVLoi0tp/qg6AQS5G/nh7J1Ef5mCMQCudgjy3tfPVPQmlrYg02wPcwm+M1T6JHwQD nTDhIKqHPLJTw0NWnP9yNOV+ycP3T7StZH/o639mouMgYx9VWyvM1CH8VnDcKuhEreLI VYHvyrXbC7mv8iwcN26qLpOj3ZqaGmKQ6fN0TRo2GWtZ2Kp7be6AWj/Mgc6BsuwpPzjQ XcLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779242660; x=1779847460; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pAyF4kmuO9OL22uyVM8ge0Yva3P7lGY8OyUoPOQHDJ0=; b=b5AWA8M3iz03v5XhuuQWUVVmllcRBIKzPnxLlstyV8gPTkQRHe3fkyGTO01gCdAk3S SZWK09qyKyPnyR6wVUfj56GIFLujD/sV09h0fSyKStNaQd/+ecnYY8N/UOQ1vSqYouIl 7UlNEU/7GUU4xvI4lB18CqGrwOQfe8o4ldmoq1TkJKNFWwv0u09rKCYt8KOjhKjUkmGn gNefr0NIwPDkXj0aEAYuxG2C94SDvFzq+tbEZqxbsCvx3QuHEWtSdg7s+7mrQx8I2ksO NU4/KiPafqsRFYsZ/0R4UEd+LADK+yK21+4x9vXURqur/iEnpbtB3d4VzjMp9c8qjceT fbWA== X-Forwarded-Encrypted: i=2; AFNElJ8e6zdOADpOrtvGYj2/maP/GIhzxJGU325JyMMbrdQLsxGVMKrzCzsv2CsCGkxuxjhxISpeMKbROJp8@gnusha.org X-Gm-Message-State: AOJu0Ywhn/xIJp2Vu7DHxZntzJHlSwdHeGK1fygYTHIB/gUd3FJZ9O09 0NUbG7sTIuLZM0TnoE8poY8HJjczP1RtZyT5fO78T4MyyFjR6DULi5ie X-Received: by 2002:a05:6820:f07:b0:67e:16b4:aa0d with SMTP id 006d021491bc7-69c9437c154mr12658076eaf.30.1779242659413; Tue, 19 May 2026 19:04:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNCtclKCEATVRUru/L3KHEss6vC/AKiOnpnHanLUwMz8g==" Received: by 2002:a05:6820:824:b0:694:9e2f:cfab with SMTP id 006d021491bc7-69b8bfba0d4ls6802755eaf.0.-pod-prod-05-us; Tue, 19 May 2026 19:04:14 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/wHbx6MB++avJgJpQj7T0KY0NmqeXnj2ThhwkJ6Ue/FIOVnvg0vckn8zgzpGHD3+pgPnfxKbEwRpTJ@googlegroups.com X-Received: by 2002:a05:6808:c2c2:b0:455:daf0:9998 with SMTP id 5614622812f47-482e57900b4mr15959540b6e.41.1779242654651; Tue, 19 May 2026 19:04:14 -0700 (PDT) Received: by 2002:a05:6402:1c1e:b0:672:bd1b:222f with SMTP id 4fb4d7f45d1cf-68214c9dc87msa12; Tue, 19 May 2026 19:02:35 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9EdKbwaTz7jR0Z/SSmUJLdbs4eJFXdAoqDrcXIX6VLNfivqbJbVK8eMTcI8yMEcyK8TSfvqdkY4CE6@googlegroups.com X-Received: by 2002:a17:907:c22:b0:bc3:c6a4:a819 with SMTP id a640c23a62f3a-bd51796e738mr1184363966b.36.1779242553567; Tue, 19 May 2026 19:02:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779242553; cv=none; d=google.com; s=arc-20240605; b=QjvX2qBxIo+FXqrGgHbNeZewyKaZr1Z2XcjPozFCHeEfZwSOKnAprouzwUgHyXifIz zejjEpQddRC2fBuvA/qQc3boveWARt2NVDSggHzs04UYoEn7vbxBGQ7VIGfDx4pujqcO g06tVt24HXKOjW+EMFzDAZH7DhSI/9N4mGR0SYFsvLj4FVjoKjCM2D6R5p5MqayqgRRr gJBQGbWzPx6NSpDuUfm81fqJwl92Sd1yiy5tdM2qqSBZxy63THALa5ojPumf+7nLTroA h7k5L9RY0VS3F/v5WZ52CcYWtttL9GIU8O5NW4Bf9nC0mV6ux0hCI32f56yQxH0na58K 8vvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=cNw4dR6iBAhsxYbQ4niv4rIoCzn6x+/nzRyTf0Sg9WI=; fh=l4Ynrc0BQ/tTYF2IDoAPnFxl9oEYE0z1REHbHSj02OQ=; b=C1+kCI/kDcKVm2KrIF+zXHP1yg+EstklqY7aKDIJ0kCyyOQlnCAekFDJaWejy0dnU/ jXKKONnGlr/vuv7qV5rcNYpZMXZwwkNGRj8eOH+Nt8UcOnpv90Z8jRwGfdsDuQx6g4NY HiONogBKhZOMTPDI23quDi+TjU/qkaZTYJlsvopvHrl8DxM7X9X6X5aXHqgHsSZDTKrO 6Xrx8gXxVLTa+Qbaurnc0AhaO0DPHkIyt5y61tNbzeVyePI6dZlot8RmtUS/k1u/6ni5 EGa8uNz0Eicey2osZ6XZ+CLy6Q25/eRJL8c9CwwVDa6CQ58TkZBT6A/L4cHM5766dJPl Wnnw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=XLseJYCk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.104 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106104.protonmail.ch (mail-106104.protonmail.ch. [79.135.106.104]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-bd4f49679d7si32768466b.0.2026.05.19.19.02.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 19:02:33 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.104 as permitted sender) client-ip=79.135.106.104; Date: Wed, 20 May 2026 02:02:25 +0000 To: Antoine Poinsot From: "'conduition' via Bitcoin Development Mailing List" Cc: Matt Corallo , Ethan Heilman , Erik Aronesty , bitcoindev@googlegroups.com Subject: Re: [bitcoindev] PQC - What is our Goal, Even? Message-ID: <_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs=@proton.me> In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: c0935a47667b0b0ae135c3c24b0d715d3d5a3838 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------4354482a4d1af9a996effa091cbbdbcda9aa261d7b506821de827170275048f7"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=XLseJYCk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.104 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------4354482a4d1af9a996effa091cbbdbcda9aa261d7b506821de827170275048f7 Content-Type: multipart/mixed;boundary=---------------------67c7422035709bba017731342a0f00ad -----------------------67c7422035709bba017731342a0f00ad Content-Type: multipart/alternative;boundary=---------------------ebd4354dbcea8f139109d9b6abcbb226 -----------------------ebd4354dbcea8f139109d9b6abcbb226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Antoine, thanks for chiming in.=C2=A0 > There are additional drawbacks to P2MR as specified in the current versio= n of BIP360. Bitcoin users activated Taproot a little over 5 years ago, who= se stated benefits include indistinguishable outputs between users of Scrip= t paths and non-Script paths, hide whether a Script path was present when k= eypath is used, and incentivize using such keypath in the first place (i.e.= "doing the right thing"). I don't think we should throw all that out the w= indow just now, if there are other ways of mitigating CRQC risks. I'm a bit confused by this framing of P2MR. Once P2MR is deployed and in-us= e with hybrid PQC, it will have the same practical privacy profile as P2TR = prior to Q-Day, and an 'everyone-agrees' path using BIP340 keys would still= be almost as well-incentivized. For anyone who does truly need the savings of key-path spending, P2TR still= exists and can be used. Nothing is being "thrown away" - you'd just need t= o ensure that any coins on P2TR addresses are moved to P2MR before Q-day. > Matt's arguing about maximizing the number of users/utxos safely migrated= , not share of supply, so i don't think this is a valid counterpoint. The= =C2=A0Milton-Shikhelman report from July 2025 estimated over 60% of existin= g UTxOs reuse an address. Ahh, I misunderstood. I'd be very curious to know more about the demographi= cs of those address-reusing UTXOs. If they're controlled by exchanges or ot= her big-bag-holders, then they're more likely to migrate in time. If not, w= ell... At least BIP32 rescue protocols should be able to cover most of them= , since most end-users hold coins in BIP32 wallets. regards, conduition=C2=A0 On Monday, April 20th, 2026 at 3:51 PM, 'Antoine Poinsot' via Bitcoin Devel= opment Mailing List wrote: > Hi Conduition, >=20 > Just a couple points on address reuse. >=20 >=20 > On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin Devel= opment Mailing List wrote: >=20 > > > I think I maybe under-stated my concern over the no-address-reuse req= uirement for P2MR. We've been=C2=A0trying to convince wallets to not reuse = addresses for 15+ years and have not only had no success, popular wallets h= ave been actively migrating the opposite direction instead. In the face of = address=C2=A0reuse, P2MR has zero advantages over P2TRv2. > >=20 > >=20 > >=20 > > I think we agree that merely spec-ing out P2MR as "not safe to reuse" i= n a BIP will be insufficient to prevent all address reuse. We also agree th= at reused=C2=A0P2MR and P2TRv2 share the same security profile, with or wit= hout a future EC restriction (which can be applied to either output type). > >=20 > > But we seem to disagree in our conclusions. You believe that because of= this overlap in security profiles, that we therefore ought to prefer P2TRv= 2 - presumably because of its short-term efficiency. I think that's a huge = leap of logic. The overall security profile of P2TRv2 and P2MR are wildly d= ifferent and you are only taking a subset of P2MR's profile into account. > >=20 > > To reach your conclusion that P2TRv2 is preferable, you'd need to assum= e that the vast majority users who migrate to P2MR will reuse addresses - v= ast enough of a majority that the short-term efficiency savings of P2TRv2 k= ey-spending outweighs the safety of the (presumed) tiny minority of users w= ho actually use P2MR properly. >=20 >=20 > There are additional drawbacks to P2MR as specified in the current versio= n of BIP360. Bitcoin users activated Taproot a little over 5 years ago, who= se stated benefits include indistinguishable outputs between users of Scrip= t paths and non-Script paths, hide whether a Script path was present when k= eypath is used, and incentivize using such keypath in the first place (i.e.= "doing the right thing"). I don't think we should throw all that out the w= indow just now, if there are other ways of mitigating CRQC risks. >=20 >=20 > > We have historical evidence this assumption won't hold. Take a look at = Project Eleven's bitcoin risk list metrics dashboard. The volume of bitcoin= exposed today due to address reuse is only a minority fraction of the over= all supply - about 5 million BTC at present. Still significant, but not an = overwhelming majority by any means. We have no reason to expect everyone wi= ll suddenly start reusing addresses consistently with P2MR, at least not an= y more than they already do. >=20 >=20 > Matt's arguing about maximizing the number of users/utxos safely migrated= , not share of supply, so i don't think this is a valid counterpoint. The= =C2=A0Milton-Shikhelman report from July 2025 estimated over 60% of existin= g UTxOs reuse an address. >=20 >=20 > > If anything, address-reuse will reduce, and not just because we ask the= m to. If you look at the highest-value addresses at fault of address-reuse = today, they are mostly corporate cold wallets: binance, robinhood, bitfinex= , tether, etc, and these make up a significant chunk of those 5 million exp= osed coins. We can reasonably expect those players to use P2MR properly out= of self-interest - These coins will be the lowest-hanging fruit targets if= they fail to do so. > >=20 > > So yes, even after taking address reuse into account, P2MR is more secu= re than P2TRv2, and personally I think the safety delta between them is wid= e enough to excuse the minor handicap in P2MR's pre-quantum efficiency. > >=20 > >=20 > > > P2MR is also asking them to overhaul a UX decision they=C2=A0made wit= h lots of user feedback on top of that. > >=20 > >=20 > >=20 > > That's fair, it would be a difficult challenge to some low-effort walle= ts not to receive coins to vulnerable addresses. But this argument implies = EC spending on P2MR isn't restricted in time - otherwise there is nothing t= o exploit when addresses are reused, and so address reuse wouldn't matter. = Under this same implication, P2TRv2 fares even worse. Concretely: > >=20 > >=20 > > - If EC spending is restricted, then both P2MR and P2TRv2 have exactl= y the same security profile and address reuse does not matter.=C2=A0 > >=20 > > - If EC spending isn't restricted, then both address formats are vuln= erable when reused, and P2TRv2 exposure is worse because even those who don= 't=C2=A0reuse addresses are vulnerable. > > =20 > >=20 > >=20 > >=20 > > In other words, P2MR is the Nash equilibrium of a prisoner's dilemma sq= uare [^1].=C2=A0 > >=20 > >=20 > > - P2MR: addresses with hidden EC spend paths are safe > > - P2TRv2: everyone is vulnerable > > - P2MR with EC restriction: everyone is safe > > - P2TRv2 with EC restriction: everyone is safe > >=20 > >=20 > > Whether EC restriction happens or not, you always get the same or bette= r security by choosing P2MR. EC restriction is the only step which can secu= re reused addresses of either P2MR or P2TRv2 [^2]. > >=20 > >=20 > >=20 > > Thus, if you firmly believe that many wallets will reuse addresses and = want to mitigate the vulnerability that follows, then the choice between ou= tput types should not weigh on your mind. Your goal should be to push every= one to commit to an EC-restricting soft fork later (maybe have a look at BI= P361 and contribute to that). The details of what output type is deployed d= on't factor in. Again: the only difference between P2MR and P2TRv2 there is= that P2TRv2 needs a future soft fork to restrict EC spending, while with P= 2MR this is optional, but still desirable (since some wallets will mistaken= ly reuse addresses either way). > >=20 > > regards, > > conduition > >=20 > > [^1]: You can expand that prisoner's dilemma square into a cube by aski= ng whether a CRQC will be invented or not, and P2MR is still a strictly bet= ter choice even if no CRQC appears - with or without EC restriction - becau= se of its better script-path efficiency. > >=20 > >=20 > >=20 > > [^2]:=C2=A0For those rare few wallets who are: (1) willing to upgrade, = (2) NOT willing to use fresh addresses, and (3) NOT willing to depend on fu= ture activation of an EC restriction, then these wallets can choose to use = hybrid address formats which use ECC and hash-based sigs in the same lockin= g script. This allows them to reuse addresses at the cost of efficiency. Wi= th a stateful signature (e.g. XMSS/SHRINCS), they'd be adding a few hundred= bytes to their witnesses, and they'd be able to reuse the address thousand= s to millions of times. I could picture corporate cold-wallets using this t= echnique, but maybe not retail wallets. > >=20 > > On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo wrote: > >=20 > > >=20 > > >=20 > > >=20 > > > > On Apr 17, 2026, at 18:04, Ethan Heilman wrote: > > >=20 > > > > =EF=BB=BF > > > > > We've been trying to convince wallets to not reuse addresses for = 15+ years and have not only had no success, popular wallets have been activ= ely migrating the opposite direction instead. > > > >=20 > > > > There is a huge difference between, we would prefer you don't reuse= addresses because privacy loss although privacy is hard to maintain anyway= s and if you reuse addresses in this context a CRQC may steal your user's f= unds. > > > >=20 > > > > Wallets are likely to be more responsive here than in the past beca= use the stakes are much higher. > > >=20 > > >=20 > > > More, maybe. But I think you=E2=80=99re drastically underestimating t= o what extent address reuse is baked into many flows. > > >=20 > > > For example most funds or very large holders have a pre-defined list = of addresses that they=E2=80=99re allowed to send to (basically exchange ac= counts to sell), and have processes in place to ensure everyone cross valid= ates that the address is on the list. > > >=20 > > > Yes, it=E2=80=99s possible to redo these, but people won=E2=80=99t, t= hey=E2=80=99ll just presume that they can move the funds again before a CRQ= C. And many of them can, of course - the large funds probably would be abou= t to move in a few days or weeks - but I=E2=80=99m quite confident it=E2=80= =99ll get normalized pretty quickly=E2=80=A6 > > >=20 > > >=20 > > > > > In the face of address reuse, P2MR has zero advantages over P2TRv= 2. > > > >=20 > > > > It's not binary. If say 1% of coins in P2MR have address reuse beca= use those users preferred to use insecure wallets, you still protected 99% = of the other P2MR coins. > > >=20 > > >=20 > > > Yes but we=E2=80=99re still back to square one - there=E2=80=99s stil= l wallets relying on a disable-EC soft fork before a CRQC. > > >=20 > > >=20 > > > > I am NOT suggesting or proposing this, but one could require that a= ny P2MR output whose EC pubkey has been leaked on-chain due to address reus= e can only be spent through the quantum safe leaf. If the community decides= this is wallets advertising PQ functionality aren't actually PQ safe becau= se this allow address reuse then one could solve the address reuse problem = in this manner. > > >=20 > > >=20 > > > Yes, i mean I think P2MR would be way more exciting if we had an effi= cient way to enforce addresses as single use directly in consensus. I=E2=80= =99m not, however, aware of one. > > >=20 > > >=20 > > > > All told, it seems better to communicate to wallets and users that = wallets which allow EC address reuse aren't PQ safe. If a wallet doesn't wa= nt to provide PQ safety why would they put in the engineering effort to sup= port P2MR and PQ sigs.=C2=A0 > > >=20 > > >=20 > > > Because there will be marketing for =E2=80=9CPQ safe=E2=80=9D and no = one (but us) will actually care about the distinction or bugs :). > > >=20 > > > Matt > > >=20 > > >=20 > > > > On Fri, Apr 17, 2026, 17:02 Matt Corallo = wrote: > > > >=20 > > > > >=20 > > > > >=20 > > > > > On 4/16/26 1:34 PM, conduition wrote: > > > > > > Hi List, > > > > > > > > > > > >> Fundamentally, it seems to me the most reasonable goal is that= we should be seeking to increase the number of coins which are reasonably = likely to be secured by the time a CRQC exists. Put another way, we should = be seeking to minimize the chance that the Bitcoin community feels the need= to fork to burn coins by reducing the number of coins which can be stolen = to the minimum number [1]. > > > > > > > > > > > > I think that's a reasonable goal which we all share, but is not= the only goal. Real-life isn't about min-maxing a single metric of success= . > > > > > > > > > > > > For instance, imagine we deploy P2TRv2, and we get EVERYONE to = migrate to it before a CRQC appears. We maxed out our stated success metric= . But we might not disable P2TRv2 key-spending in a timely manner. If the f= uture community fails to deploy at the right time, a CRQC can steal at leas= t as much bitcoin as they could've before the migration, if not more. We ma= xed out our success metric but still failed, so that metric must not be our= only goal. > > > > > > > > > > > > That's why we should achieve your stated goal only as a consequ= ence of a more general but less easily-quantifiable goal: to design an opti= mal, flexible, and long-term-secure PQ migration path. If we standardize th= is and make code available to help, migration will come as a natural conseq= uence, as will other desirable goals like "not letting a CRQC screw us all = over", and "enabling long-term cryptographic agility". > > > > >=20 > > > > > Sure, there are limitations of the goal as I stated, but your sug= gested alternative here isn't > > > > > actually a concreate goal. "optimal, flexible, and long-term-secu= re" isn't something we can optimize > > > > > for :) > > > > >=20 > > > > > > If we can agree on that, then any further disagreement will be = due to a difference of opinion as to what is "optimal" or "flexible", and t= he correct trade-offs to make on security. We all weigh different propertie= s with different values. > > > > > > > > > > > > For instance, I put more weight on conclusive security of P2MR,= whereas Matt puts more weight on fee-efficiency and "privacy" of P2TRv2 [^= 1]. > > > > >=20 > > > > > I think I maybe under-stated my concern over the no-address-reuse= requirement for P2MR. We've been > > > > > trying to convince wallets to not reuse addresses for 15+ years a= nd have not only had no success, > > > > > popular wallets have been actively migrating the opposite directi= on instead. In the face of address > > > > > reuse, P2MR has zero advantages over P2TRv2. > > > > >=20 > > > > > > There are also differences of faith. Matt puts more faith in th= e future community to activate follow-up soft forks. I put more faith in wa= llet developers following standards and in users proactively migrating to P= Q-safe wallets. > > > > > > > > > > > > Based on Matt's previous emails, I think we both share the same= LACK of faith that a majority of the UTXO set will migrate in time, and we= also share the goal of mitigating that. > > > > > > > > > > > > > > > > > >> This naturally means focusing on the wallets which are the *le= ast likely* to migrate or otherwise get themselves in a safe spot. Focusing= on those who are the most likely to migrate does almost nothing to move th= e needle on the total number of coins protected, nor, thus, on the probabil= ity of a future Bitcoin community feeling the need to burn coins. > > > > > > > > > > > > Also agreed. > > > > > > > > > > > > > > > > > > I didn't find any public statements from your cited examples ab= out quantum security posture. Since it seems important to understand the wa= llets' stances in this dilemma, I posted a tweet tagging 8 major multi-chai= n wallets [2] including the 3 wallets you cited as examples. I'm curious wh= at they'll say. > > > > > > > > > > > > Having worked with such wallets before, my expectation is that = they'll follow whatever is standardized, as long as it gives them more mark= et share and as long as they can "npm install whatever" to implement it. I'= m not trivializing here - These devs are just spread much thinner than thos= e building single-chain wallets. > > > > >=20 > > > > > Sure but no new key scheme is going to be an "npm install whateve= r" - it requires a rewrite of a > > > > > bunch of key derivation and backup schemes. P2MR is also asking t= hem to overhaul a UX decision they > > > > > made with lots of user feedback on top of that. > > > > >=20 > > > > > > The harder question to answer is whether the major wallets make= the PQ output type the default for receiving Bitcoin. Big software compani= es are typically very concerned about bugs in new code paths, and they weig= h this risk against the benefits of any new feature. When deploying new fea= tures as default, they often do so using A/B testing and incremental rollou= t techniques. So the earlier question shouldn't be binary. It becomes: How = quickly will major wallets roll out PQ outputs as default? > > > > >=20 > > > > > Fair, true point. > > > > >=20 > > > > > > Rollout pace will depend on the personal views of the wallets' = corporate executives and technical advisors. They will weigh the risk of in= troducing new, riskier, less-efficient code paths against the risk of a CRQ= C appearing in the near future. We and other users can try to lobby them, b= ut ultimately each wallet's decision makers must eventually convince themse= lves the CRQC risk is greater. Some will move too slowly, and many will lik= ely regret their choices one way or another. > > > > > > > > > > > > I believe we cannot effectively optimize away a problem like th= is by tempting decision-makers with slightly lower fees, since that's not a= ll they are worried about. I believe we especially should not try to do so = at the expense of conclusive PQ security and long-term optimization. > > > > > > > > > > > > I think the crux of the P2TRv2 vs P2MR disagreement here is tha= t Matt believes P2TRv2 will induce wallets to roll out default PQ outputs m= eaningfully faster than P2MR would, and that this trumps arguments about po= st-quantum security or efficiency. > > > > >=20 > > > > > No, its far from just about fees. Its also about maintaining the = goals that we had going into > > > > > taproot. And a bit that P2MR doesn't accomplish anything unless m= uch of the ecosystem changes their > > > > > processes substantially. > > > > >=20 > > > > > -- > > > > > 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/b= itcoindev/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com. > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2C= gPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me. >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/kkdcg1Bo7GsRcpH5gDpfZ1WZR-ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8eV= hE-x2-fOXExE9x2b2V21m6kact8e4CSzNQ%3D%40protonmail.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/= _3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onX= RUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs%3D%40proton.me. -----------------------ebd4354dbcea8f139109d9b6abcbb226 Content-Type: multipart/related;boundary=---------------------b18315a21618dfb83d498a3bdd027297 -----------------------b18315a21618dfb83d498a3bdd027297 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,= thanks for chiming in. 

There are additional drawbacks to P2MR a= s specified in the current version of BIP360. Bitcoin users activated Tapro= ot a little over 5 years ago, whose stated benefits include indistinguishab= le outputs between users of Script paths and non-Script paths, hide whether= a Script path was present when keypath is used, and incentivize using such= keypath in the first place (i.e. "doing the right thing"). I don't think w= e should throw all that out the window just now, if there are other ways of= mitigating CRQC risks.
=
I'm a bit confused by this framing of P2MR= . Once P2MR is deployed and in-use with hybrid PQC, it will have the same p= ractical privacy profile as P2TR prior to Q-Day, and an 'everyone-agrees' p= ath using BIP340 keys would still be almost as well-incentivized.

For anyone who does truly need the sa= vings of key-path spending, P2TR still exists and can be used. Nothing is b= eing "thrown away" - you'd just need to ensure that any coins on P2TR addre= sses are moved to P2MR before Q-day.

<= div style=3D"">Matt's arguing about maximizing the number of users/ut= xos safely migrated, not share of supply, so i don't think this is a valid = counterpoint. The Milton-Shikhelman report from July 2025 estimated ov= er 60% of existing UTxOs reuse an address.

Ahh, I misunderst= ood. I'd be very curious to know more about the demographics of those addre= ss-reusing UTXOs. If they're controlled by exchanges or other big-bag-holde= rs, then they're more likely to migrate in time. If not, well... At least B= IP32 rescue protocols should be able to cover most of them, since most end-= users hold coins in BIP32 wallets.

regards,
conduition 

On Monday, April 20th, 2026 at 3:51 PM, 'Antoine Poinsot' via Bitco= in Development Mailing List <bitcoindev@googlegroups.com> wrote:
Hi Conduition,

Just a couple points on address reuse.

On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin= Development Mailing List <bitcoindev@googlegroups.com> wrote:
I think I maybe under-stated my concern over the no-address-reuse = requirement for P2MR. We've been trying to convince wall= ets to not reuse addresses for 15+ years and have not only had no success, = popular wallets have been actively migrating the opposite direction instead= . In the face of address reuse, P2MR has zero advantages o= ver P2TRv2.

I think we agree that mere= ly spec-ing out P2MR as "not safe to reuse" in a BIP will be insufficient t= o prevent all address reuse. We also agree that reused P= 2MR and P2TRv2 share the same security profile, with or without a future EC= restriction (which can be applied to either output type).

But we seem to d= isagree in our conclusions. You believe that because of this overlap in sec= urity profiles, that we therefore ought to prefer P2TRv2 - presumably becau= se of its short-term efficiency. I think that's a huge leap of logic. The o= verall security profile of P2TRv2 and P2MR are wildly different and you are= only taking a subset of P2MR's profile into account.

To reach your conclusion tha= t P2TRv2 is preferable, you'd need to assume that the vast majority users w= ho migrate to P2MR will reuse addresses - vast enough of a majority that th= e short-term efficiency savings of P2TRv2 key-spending outweighs the safety= of the (presumed) tiny minority of users who actually use P2MR properly.

There are additional drawbacks to P2MR as specified in the current ver= sion of BIP360. Bitcoin users activated Taproot a little over 5 years ago, = whose stated benefits include indistinguishable outputs between users of Sc= ript paths and non-Script paths, hide whether a Script path was present whe= n keypath is used, and incentivize using such keypath in the first place (i= .e. "doing the right thing"). I don't think we should throw all that out th= e window just now, if there are other ways of mitigating CRQC risks.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
We have historical evidence this as= sumption won't hold. Take a look at Pro= ject Eleven's bitcoin risk list metrics dashboard. The volume of bitcoi= n exposed today due to address reuse is only a minority fraction of the ove= rall supply - about 5 million BTC at present. Still significant, but not an= overwhelming majority by any means. We have no reason to expect everyone w= ill suddenly start reusing addresses consistently with P2MR, at least not a= ny more than they already do.

Matt's arguing about maximizing the num= ber of users/utxos safely migrated, not share of supply, so i don't think t= his is a valid counterpoint. The Milton-Shikhelman report from J= uly 2025 estimated= over 60% of existing UTxOs reuse an address.

If anything, address-reuse will reduce, and not= just because we ask them to. If you look at the highest-value addresses at= fault of address-reuse today, they are mostly corporate cold wallets: bina= nce, robinhood, bitfinex, tether, etc, and these make up a significant chun= k of those 5 million exposed coins. We can reasonably expect those players = to use P2MR properly out of self-interest - These coins will be the lowest-= hanging fruit targets if they fail to do so.

So yes, even after taking address reu= se into account, P2MR is more secure than P2TRv2, and personally I think th= e safety delta between them is wide enough to excuse the minor handicap in = P2MR's pre-quantum efficiency.

P2MR is also asking them to overhaul a UX decisio= n they made with lots of user feedback on top of that.

That's fair, it would be a difficult challenge = to some low-effort wallets not to receive coins to vulnerable addresses. Bu= t this argument implies EC spending on P2MR isn't restricted in time - othe= rwise there is nothing to exploit when addresses are reused, and so address= reuse wouldn't matter. Under this same implication, P2TRv2 fares even wors= e. Concretely:

    If EC spending is restric= ted, then both P2MR and P2TRv2 have exactly the same security profile and a= ddress reuse does not matter. 
  • If EC spending isn't restricted, then both address form= ats are vulnerable when reused, and P2TRv2 exposure is worse because even t= hose who don't reuse addresses are vulnerable.
    • <= /ul>
<= span>
In other words, P2MR i= s the Nash equilibrium of a prisoner's dilemma square [^1]. 

  • P2MR: addresses with hidden E= C spend paths are safe
  • P2TRv2: every= one is vulnerable
  • P2MR with EC restr= iction: everyone is safe
  • P2TRv2 with= EC restriction: everyone is safe

Whether EC restriction happens or not, you always get the same or be= tter security by choosing P2MR. EC restriction is the only step which can s= ecure reused addresses of either P2MR or P2TRv2 [^2].
=
Thus, if you firmly believe that many wallets w= ill reuse addresses and want to mitigate the vulnerability that follows, th= en the choice between output types should not weigh on your mind. Your goal= should be to push everyone to commit to an EC-restricting soft fork later = (maybe have a look at BIP361 and contribute to that). The details of what o= utput type is deployed don't factor in. Again: the only difference between = P2MR and P2TRv2 there is that P2TRv2 needs a future soft fork to restric= t EC spending, while with P2MR this is optional, but still desirable (s= ince some wallets will mistakenly reuse addresses either way).
regards,
conduition

[^1]: Y= ou can expand that prisoner's dilemma square = into a cube by asking whether a CRQC will be invented or not, and P2MR is s= till a strictly better choice even if no CRQC appears - with or without EC = restriction - because of its better script-path efficiency.

[^2]: = For those rare few wallets who are: (1) willing to upgrade, (2) NOT willing= to use fresh addresses, and (3) NOT willing to depend on future activation= of an EC restriction, then these wallets can choose to use hybrid address = formats which use ECC and hash-based sigs in the same locking script. This = allows them to reuse addresses at the cost of efficiency. With a stateful s= ignature (e.g. XMSS/SHRINCS), they'd be adding a few hundred bytes to their= witnesses, and they'd be able to reuse the address thousands to millions o= f times. I could picture corporate cold-wallets using this technique, but m= aybe not retail wallets.
On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo <lf-lists@m= attcorallo.com> wrote:


On Apr 17, 2026, at 18:04, Ethan Heilman = <eth3rs@gmail.com> wrote:

=EF=BB=BF
> We've been trying to convince wallets to not = reuse addresses for 15+ years and have not only had no success, popular wal= lets have been actively migrating the opposite direction instead.

There is a huge difference betwee= n, we would prefer you don't reuse addresses because privacy loss although = privacy is hard to maintain anyways and if you reuse addresses in this cont= ext a CRQC may steal your user's funds.

Wallets are likely to be more responsive here than in the p= ast because the stakes are much higher.
=
More, maybe. But I think you=E2=80=99re drastically underest= imating to what extent address reuse is baked into many flows.
For example most funds or very large holders have a pre-define= d list of addresses that they=E2=80=99re allowed to send to (basically exch= ange accounts to sell), and have processes in place to ensure everyone cros= s validates that the address is on the list.

Yes, = it=E2=80=99s possible to redo these, but people won=E2=80=99t, they=E2=80= =99ll just presume that they can move the funds again before a CRQC. And ma= ny of them can, of course - the large funds probably would be about to move= in a few days or weeks - but I=E2=80=99m quite confident it=E2=80=99ll get= normalized pretty quickly=E2=80=A6

> In the face of addres= s reuse, P2MR has zero advantages over P2TRv2.

<= /div>
It's not binary. If say 1% of coins in P2MR have add= ress reuse because those users preferred to use insecure wallets, you still= protected 99% of the other P2MR coins.
=
Yes but we=E2=80=99re still back to square one - there=E2=80= =99s still wallets relying on a disable-EC soft fork before a CRQC.
I am NOT suggesting or proposing this, but one could require that any= P2MR output whose EC pubkey has been leaked on-chain due to address reuse = can only be spent through the quantum safe leaf. If the community decides t= his is wallets advertising PQ functionality aren't actually PQ safe because= this allow address reuse then one could solve the address reuse problem in= this manner.

Yes, i mean= I think P2MR would be way more exciting if we had an efficient way to enfo= rce addresses as single use directly in consensus. I=E2=80=99m not, however= , aware of one.

All told, it seems better to communicate to wa= llets and users that wallets which allow EC address reuse aren't PQ safe. I= f a wallet doesn't want to provide PQ safety why would they put in the engi= neering effort to support P2MR and PQ sigs. 

Because there will be marketing for =E2=80=9CPQ sa= fe=E2=80=9D and no one (but us) will actually care about the distinction or= bugs :).

Matt

=
On Fri, Apr 17, 2026, 17:02 Matt Corallo <= lf-lists@mattcorallo.com> wrote:


On 4/16/26 1:34 PM, conduition wrote:
> Hi List,
>
>> Fundamentally, it seems to me the most reasonable goal is that we = should be seeking to increase the number of coins which are reasonably like= ly to be secured by the time a CRQC exists. Put another way, we should be s= eeking to minimize the chance that the Bitcoin community feels the need to = fork to burn coins by reducing the number of coins which can be stolen to t= he minimum number [1].
>
> I think that's a reasonable goal which we all share, but is not the on= ly goal. Real-life isn't about min-maxing a single metric of success.
>
> For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrate= to it before a CRQC appears. We maxed out our stated success metric. But w= e might not disable P2TRv2 key-spending in a timely manner. If the future c= ommunity fails to deploy at the right time, a CRQC can steal at least as mu= ch bitcoin as they could've before the migration, if not more. We maxed out= our success metric but still failed, so that metric must not be our only g= oal.
>
> That's why we should achieve your stated goal only as a consequence of= a more general but less easily-quantifiable goal: to design an optimal, fl= exible, and long-term-secure PQ migration path. If we standardize this and = make code available to help, migration will come as a natural consequence, = as will other desirable goals like "not letting a CRQC screw us all over", = and "enabling long-term cryptographic agility".

Sure, there are limitations of the goal as I stated, but your suggested alt= ernative here isn't
actually a concreate goal. "optimal, flexible, and long-term-secure" isn't = something we can optimize
for :)

> If we can agree on that, then any further disagreement will be due to = a difference of opinion as to what is "optimal" or "flexible", and the corr= ect trade-offs to make on security. We all weigh different properties with = different values.
>
> For instance, I put more weight on conclusive security of P2MR, wherea= s Matt puts more weight on fee-efficiency and "privacy" of P2TRv2 [^1].

I think I maybe under-stated my concern over the no-address-reuse requireme= nt for P2MR. We've been
trying to convince wallets to not reuse addresses for 15+ years and have no= t only had no success,
popular wallets have been actively migrating the opposite direction instead= . In the face of address
reuse, P2MR has zero advantages over P2TRv2.

> There are also differences of faith. Matt puts more faith in the futur= e community to activate follow-up soft forks. I put more faith in wallet de= velopers following standards and in users proactively migrating to PQ-safe = wallets.
>
> Based on Matt's previous emails, I think we both share the same LACK o= f faith that a majority of the UTXO set will migrate in time, and we also s= hare the goal of mitigating that.
>
>
>> This naturally means focusing on the wallets which are the *least = likely* to migrate or otherwise get themselves in a safe spot. Focusing on = those who are the most likely to migrate does almost nothing to move the ne= edle on the total number of coins protected, nor, thus, on the probability = of a future Bitcoin community feeling the need to burn coins.
>
> Also agreed.
>
>
> I didn't find any public statements from your cited examples about qua= ntum security posture. Since it seems important to understand the wallets' = stances in this dilemma, I posted a tweet tagging 8 major multi-chain walle= ts [2] including the 3 wallets you cited as examples. I'm curious what they= 'll say.
>
> Having worked with such wallets before, my expectation is that they'll= follow whatever is standardized, as long as it gives them more market shar= e and as long as they can "npm install whatever" to implement it. I'm not t= rivializing here - These devs are just spread much thinner than those build= ing single-chain wallets.

Sure but no new key scheme is going to be an "npm install whatever" - it re= quires a rewrite of a
bunch of key derivation and backup schemes. P2MR is also asking them to ove= rhaul a UX decision they
made with lots of user feedback on top of that.

> The harder question to answer is whether the major wallets make the PQ= output type the default for receiving Bitcoin. Big software companies are = typically very concerned about bugs in new code paths, and they weigh this = risk against the benefits of any new feature. When deploying new features a= s default, they often do so using A/B testing and incremental rollout techn= iques. So the earlier question shouldn't be binary. It becomes: How quickly= will major wallets roll out PQ outputs as default?

Fair, true point.

> Rollout pace will depend on the personal views of the wallets' corpora= te executives and technical advisors. They will weigh the risk of introduci= ng new, riskier, less-efficient code paths against the risk of a CRQC appea= ring in the near future. We and other users can try to lobby them, but ulti= mately each wallet's decision makers must eventually convince themselves th= e CRQC risk is greater. Some will move too slowly, and many will likely reg= ret their choices one way or another.
>
> I believe we cannot effectively optimize away a problem like this by t= empting decision-makers with slightly lower fees, since that's not all they= are worried about. I believe we especially should not try to do so at the = expense of conclusive PQ security and long-term optimization.
>
> I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt = believes P2TRv2 will induce wallets to roll out default PQ outputs meaningf= ully faster than P2MR would, and that this trumps arguments about post-quan= tum security or efficiency.

No, its far from just about fees. Its also about maintaining the goals that= we had going into
taproot. And a bit that P2MR doesn't accomplish anything unless much of the= ecosystem changes their
processes substantially.

--
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/600f95eb-04e8-470d-b6df-= cf725e48d1b5%40mattcorallo.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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/sMhLbmV30g91LFREGHE2JfcnoPYAOeU= XZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJs= E%3D%40proton.me.

--
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+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/kkdcg1Bo7GsRcpH5gDpfZ1WZR-= ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8eVhE-x2-fOXExE9x2b2V21m6kact8e= 4CSzNQ%3D%40protonmail.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/_3mqxJ= vqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTX= W4g_gH9qZvIvpY1ZHZkpgpaoXs%3D%40proton.me.
-----------------------b18315a21618dfb83d498a3bdd027297-- -----------------------ebd4354dbcea8f139109d9b6abcbb226-- -----------------------67c7422035709bba017731342a0f00ad Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------67c7422035709bba017731342a0f00ad-- --------4354482a4d1af9a996effa091cbbdbcda9aa261d7b506821de827170275048f7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmoNFiIJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdaCSgzN0ZE72d4QHMDgXDt2ok7sRLc40Ic6cw5 C6DMSxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABi2gEA1h8Lvpa3+YV0puwz V/MoQ6nL5OoF0runA5mzdIKNn44BAOENnbZt0/TVYXYFUwZS3bh2/GgnViVN RON9Im6yEk8H =QpC8 -----END PGP SIGNATURE----- --------4354482a4d1af9a996effa091cbbdbcda9aa261d7b506821de827170275048f7--