From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 21 May 2026 11:18:05 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wQ7y6-0003wa-Nv for bitcoindev@gnusha.org; Thu, 21 May 2026 11:18:05 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-43a60eba349sf14267531fac.3 for ; Thu, 21 May 2026 11:18:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779387476; cv=pass; d=google.com; s=arc-20240605; b=Xh6mIh4gM2SkKKi9ulZU+IjIndah0TV569g6xHcIb9iZDZSsNPetrHyoqQ9CaqnI07 cDYY6IxHDrTrgHXL3g8oXF3wOE/elzRjrJ89AVktmlglmXT4i5SiYMulcvuB6hEqyBA2 ArpODID1yPyjoLa8gL3KZqVe5D4QocPkESklR/khfL5lvT1BtmEy7vjKBAY/ERei64A9 RnCrBNyO3RNBSs6Hy3Qn4gNVxMlPVicF4U/YeX5OhcYfKAcVIsva9RB/pk/UusWK3hgS aGeEsswL0VJEcDJtLJJYndab8HqDqEXI61ZF80ebxHzv2B3Fl8DJ3SgnBVeKK4e2w5lr 3z+Q== 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=KEq7zxTIelqZ0MBJmp3p61J0UAnqAozQoOEj8udm8R8=; fh=DarNgQZDzWBFeLhZu/9iXed5Nhj3J+3FCS3K6hJ0AYg=; b=ZmxtCAvuuKec4nEXWwDBZETaxPxwV+UE1P3KijmPkLjT/whIRyZRuJEZN3L3fwLvrr 4ipGgocR0VyBnSHuN2OnTKVFiSu/YGIFn3TuEcOchIWLX/wO0+W7MaCraYg4/qVt/l5D uOqfRdTqNJJMQy0xN1KFTluFf/1dNe2qjtxQNH3d84j0SqlvEpTy7TkoC/lNHkC/A1P8 T9/H6I/1t0oUmbnxx6UQmPtCJ4uzgl/AMF3Jzsmtooca6xcXZiCg4PTMDUr+f6eFUnJg I4fpWiZcrKz3QEGpLdCSVDy/w7Q77iRncunNfMhqNMJ320xUl/m2IjtkH3WgfDNO2pi8 YxXw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=MRkfEeOS; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 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=1779387476; x=1779992276; 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=KEq7zxTIelqZ0MBJmp3p61J0UAnqAozQoOEj8udm8R8=; b=Q8If1fXtgD3ZllExsqVJYiIbxC/+ULiZaDmTW/NzW1E3oM0WplVYzCp3IkGwsjVSp5 xjNrBPhuDA+GP4FlL5oe+O9Jjtg/3db7B2w/WdP88OSIHD/VwtW3iCIZaY4dBYYalfjI hf8RqziL7Wv/2TRgyGSLQAahd0WSKXlKiDy+hXh3AaKwET9nr9ZeOAEg26MfWRCaUnAK ZLjUvGIuS7lhW0PHbUrQj4QSKXQy3v7gXyDv6BzUVBHLQe6Qmuu0iFdtGFKv8+GSHuqo vE/I1vO+JDdGm4HxArw6EvyfRtCQBXOvigzIcOf/QT7gZY1fMtMoLhcfek22uuTnsIvY tbXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779387476; x=1779992276; 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=KEq7zxTIelqZ0MBJmp3p61J0UAnqAozQoOEj8udm8R8=; b=YKwiQml2Z6d6PFIn2Dag9LbTHkqPwTy6IsRDUN8IpwwE0JrDiwwzo2rIWz3b4hTFGZ +Q8oMnaj0YTjbQMRFvUnVIjO5yKiygu2WTHeUCFb5avXzc7sMPu3AmqFKwXOmkoJeywV 95JIU4gnDjLKcWa2/s2euZUVTkctQ+iCoo/yuQuyT5zB8GMfkNuwc0A79yrKAr4Fswmm +XLSurF89fQIHiSZkLc6f1GEhSPzhjL8bPIO1h939a/batOMGgA+WmfOR5PhlzFgISrA VhRv67k41jKJnwp9Ul/6cmNABpKkVrHS9P5smZC3hbsJKVgcEYhestGDsxWNhcBZEq5R XJWA== X-Forwarded-Encrypted: i=2; AFNElJ/P4Ccmz6o/8Sogz28+TMPjrBFfVtzto+JaoBpRTE7w3YFE4HXhvu3LcLOcrSUqn2kndEWXfmIy5Ex0@gnusha.org X-Gm-Message-State: AOJu0YyMrr/nkuc0RMb4XIjUbjSrjsJZzNNF6Jvooo7NAsnnNRssGxD9 FK6a1q7AydAWv25h5xLADqZLiBZjxnCVz14GJhJ99efoXWdN7ZYpNya2 X-Received: by 2002:a05:6870:56a7:b0:439:c546:e9e7 with SMTP id 586e51a60fabf-43b5ae8c9aamr96598fac.27.1779387476358; Thu, 21 May 2026 11:17:56 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMO7dgSXoc+7JpH4xhj0CAVwC7W46cpP5Qs7/eo6/L6zIw==" Received: by 2002:a05:6870:63aa:b0:41c:64c3:46be with SMTP id 586e51a60fabf-43a01eb8956ls7342834fac.1.-pod-prod-07-us; Thu, 21 May 2026 11:17:51 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8eAJ173MfMnwN0rmtcRE5XPSc3MHfcJstoqDp8lrf/sxdmPLATg01EfNyh3wSpbjW2u27tw1mLPQdX@googlegroups.com X-Received: by 2002:a05:6808:6ec6:b0:485:115a:3573 with SMTP id 5614622812f47-4854a23ca14mr69276b6e.38.1779387471478; Thu, 21 May 2026 11:17:51 -0700 (PDT) Received: by 2002:aa7:d80c:0:b0:670:416a:5ab4 with SMTP id 4fb4d7f45d1cf-682284480e9msa12; Thu, 21 May 2026 08:24:42 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/XyQkd/v5PIPXLkQBtMSuaAHT5Q9ujNSonB/8ziFm4+Z6xYrtYiPUbf5UTrlkp2N+fljZc0jR4kVKl@googlegroups.com X-Received: by 2002:a05:6402:34c5:b0:681:2472:76c2 with SMTP id 4fb4d7f45d1cf-6883562a13fmr2234825a12.4.1779377081127; Thu, 21 May 2026 08:24:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779377081; cv=none; d=google.com; s=arc-20240605; b=DTykPIhW0Lln96mayYTqrNDBZ2o9TdCe4BlsxbQEz0MjMaer1eyhhs3Gc8iwID+2cR kZNFryu2GNkBi0FdOqJEvF9o3bJQsdoOcsw6EAgdIjEfuKfCHhkDOxKM7/ADVfGHGzqE 40X0ENWL7HezhsvYLsfwZglGrVKnC27I0lqDtP5hT0ZX8xjvRJ05v47rkLyKt8FcBq8X xohn4Lgjgrd7uAUPnB9UfE0zmRWeYzyOZnsCBi+J1cWdpF7ZSb5FfxCu6tXYnHRWq0oa kHSbxMPuBDnrcpyW0Ji7PTOzgMSD0KsTvs8OhGPCWhoCpQElZlfKh5W1vexClj0XOKpm ErNQ== 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=wAefup6H0ZlJ9AuLIsmF65JyrHqd1VXQyx3pfn0V8Rg=; fh=l4Ynrc0BQ/tTYF2IDoAPnFxl9oEYE0z1REHbHSj02OQ=; b=js5DD3oziz5FTAcRWJctCdKQjFrfL4zco+C9BflwIe7Yke56zxXntMC6SX43HFuYr6 p7E2C9f/Mgt1KGs4DPHic533Jok0bqCUgboW0WhAvVZ+tqdN1ofowTqBMnJSQpS6qzJJ 4MeeUn3Z8I5QQzZeq1TCLACMhL77fOVUdGbX7gaZh+24r9KA8SSMDdfQghVbQ+wFzi1X 8Z+v/i+yyJVT25viU3Y3FLnolVaNJvEy988WbFW1W0l43RhSkniiGuFJZoC/557bvTgS PC+yhUVeFgjUwbQHEPDBAZVg17DoFc1Ym3VWUy+D3CDgCJPoEh//hLg/kV4/NTbtxXKT DrpA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=MRkfEeOS; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch. [185.70.43.167]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-6887ed82603si19566a12.8.2026.05.21.08.24.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2026 08:24:41 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) client-ip=185.70.43.167; Date: Thu, 21 May 2026 15:24:31 +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: In-Reply-To: <3TguePkqzkPWZeuW8j7nrZnDnhmDpYfIh22hbInFeyVRwPX0Ohh7wjsptoNMnJAKwysYUGaGOaQVVx7se5WEeO-nmUEpcWUC_jKBWQrx4tI=@protonmail.com> References: <_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs=@proton.me> <3TguePkqzkPWZeuW8j7nrZnDnhmDpYfIh22hbInFeyVRwPX0Ohh7wjsptoNMnJAKwysYUGaGOaQVVx7se5WEeO-nmUEpcWUC_jKBWQrx4tI=@protonmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 724951298376610718c4bb58fa4e484b3451928f MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------fcfb7a2ee946077764d0b223f26fdd60eac52b1838e6033081be4bfc78ab549c"; 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=MRkfEeOS; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 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) --------fcfb7a2ee946077764d0b223f26fdd60eac52b1838e6033081be4bfc78ab549c Content-Type: multipart/mixed;boundary=---------------------0fe1d4d5177d9f22858b77acf5b27ad5 -----------------------0fe1d4d5177d9f22858b77acf5b27ad5 Content-Type: multipart/alternative;boundary=---------------------8a51379514e61f5fb68dad59b89f489b -----------------------8a51379514e61f5fb68dad59b89f489b Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Antoine, > My point is that Taproot incentivizes users of advanced contracts to make= their Script usage indistinguishable from other usages. I think I see what you mean. Matt made this point earlier. P2TR encourages = the use of the key-spending path because its cost is forced on the user, wh= o must intentionally opt-out of using it (NUMS point), while with P2MR the = user can choose to save space by omitting a cooperative BIP340 leaf script.= Then they'd have a script tree with just a single spending path for some c= omplex and easily-fingerprintable script which reduces their and everyone e= lse's anonymity set. I'll call this the 'single-leaf' pattern. I have three arguments against this point as a justification for P2TRv2: 1. The number of people who are going to fit into this incentive funnel wo= uld be small, so the effect on privacy for everyone else would be negligibl= e. For a single-leaf script tree to be more efficient than a two-leaf scrip= t tree, the difference between witness sizes for the cooperative vs uncoope= rative spending paths would have to be less than 32 bytes. Any larger and i= t now pays to include a cooperative path. The larger the difference, the mo= re well-incentivized a cooperative spending path would be. Though this rule= s out extraneous factors like development effort, but still I expect the in= centivized demographic will be tiny. 2. This property can be argued as a feature: P2MR has some advantage over = P2TR in efficiency, under certain scenarios. It gives P2MR a reason to exis= t even if CRQCs never appear. You're framing this property as a negative be= cause of the privacy implications, but we should consider the positives as = well. 3. Finally, compared to the integrity of the UTXO set, this is a bikeshed-= level design goal. If we have to risk the security of=C2=A0everyone's=C2=A0= coins, and commit ourselves to perfectly timing a follow-up soft-fork that = disables P2TRv2 key-spending, then the privacy gain is not worth it. Still, maybe we don't have to take that risk to get the incentive structure= we want. What if we modified P2MR to require trees of at least depth 1?=C2=A0This wa= y, the user=C2=A0must=C2=A0bear the cost of at least two spending paths any= way, so they might as well use one for an everyone-agrees BIP340 path. This= mirrors the incentive structure of P2TR's non-optional key-spend path. 99% of users (those building P2MR addresses properly) would not be affected= by this change anyway, because quantum-resistant hybrid addresses would be= the specified standard for consumer wallets, and those wallets would alrea= dy have at least two script leaves.=C2=A0The downside of this is a loss of = efficiency after Q-day, for wallets which may only need a single PQ leaf (n= o point in using an ECC leaf anymore). Would this assuage your concern about incentives? regards, conduition On Wednesday, May 20th, 2026 at 12:49 PM, Antoine Poinsot wrote: > Hi Conduition, >=20 > My point is that Taproot incentivizes users of advanced contracts to make= their Script usage indistinguishable from other usages. I believe this is = a desirable property because privacy is a common good, and because users us= ually do not need to reveal differences in their spending conditions. >=20 > If P2MR is made available you will immediately see usage from people that= are not interested in migrating to PQ cryptography, but simply do not want= to pay the cost of revealing the internal key in Taproot script path spend= s. This does two things: >=20 > - this preemptively abandons some of the benefits of Taproot; > - this makes any future soft fork to disable EC in P2MR context, which = would be necessary to provide any PQ migration guarantee, extremely dubious= . >=20 >=20 > Therefore i think alternatives that preserve Taproot's properties, like P= 2TRv2, are preferable. >=20 > Best, > Antoine > On Tuesday, May 19th, 2026 at 10:04 PM, 'conduition' via Bitcoin Developm= ent Mailing List wrote: >=20 > > Hi Antoine, thanks for chiming in.=C2=A0 > >=20 > >=20 > > > There are additional drawbacks to P2MR as specified in the current ve= rsion of BIP360. Bitcoin users activated Taproot a little over 5 years ago,= whose stated benefits include indistinguishable outputs between users of S= cript paths and non-Script paths, hide whether a Script path was present wh= en 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 t= he window just now, if there are other ways of mitigating CRQC risks. > >=20 > >=20 > >=20 > > I'm a bit confused by this framing of P2MR. Once P2MR is deployed and i= n-use with hybrid PQC, it will have the same practical privacy profile as P= 2TR prior to Q-Day, and an 'everyone-agrees' path using BIP340 keys would s= till be almost as well-incentivized. > >=20 > > For anyone who does truly need the savings of key-path spending, P2TR s= till exists and can be used. Nothing is being "thrown away" - you'd just ne= ed to ensure that any coins on P2TR addresses are moved to P2MR before Q-da= y. > >=20 > >=20 > > > Matt's arguing about maximizing the number of users/utxos safely migr= ated, not share of supply, so i don't think this is a valid counterpoint. T= he=C2=A0Milton-Shikhelman report from July 2025 estimated over 60% of exist= ing UTxOs reuse an address. > >=20 > >=20 > >=20 > > Ahh, I misunderstood. I'd be very curious to know more about the demogr= aphics of those address-reusing UTXOs. If they're controlled by exchanges o= r other big-bag-holders, then they're more likely to migrate in time. If no= t, well... At least BIP32 rescue protocols should be able to cover most of = them, since most end-users hold coins in BIP32 wallets. > >=20 > >=20 > > regards, > > conduition=C2=A0 > >=20 > >=20 > > On Monday, April 20th, 2026 at 3:51 PM, 'Antoine Poinsot' via Bitcoin D= evelopment Mailing List wrote: > >=20 > > > Hi Conduition, > > >=20 > > > Just a couple points on address reuse. > > >=20 > > >=20 > > > On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin D= evelopment Mailing List wrote: > > >=20 > > > > > I think I maybe under-stated my concern over the no-address-reuse= requirement for P2MR. We've been=C2=A0trying to convince wallets to not re= use addresses for 15+ years and have not only had no success, popular walle= ts have 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 reus= e" in a BIP will be insufficient to prevent all address reuse. We also agre= e that reused=C2=A0P2MR and P2TRv2 share the same security profile, with or= without a future EC restriction (which can be applied to either output typ= e). > > > >=20 > > > > But we seem to disagree in our conclusions. You believe that becaus= e of this overlap in security profiles, that we therefore ought to prefer P= 2TRv2 - presumably because of its short-term efficiency. I think that's a h= uge leap of logic. The overall security profile of P2TRv2 and P2MR are wild= ly different and you are only taking a subset of P2MR's profile into accoun= t. > > > >=20 > > > > To reach your conclusion that P2TRv2 is preferable, you'd need to a= ssume that the vast majority users who migrate to P2MR will reuse addresses= - vast enough of a majority that the short-term efficiency savings of P2TR= v2 key-spending outweighs the safety of the (presumed) tiny minority of use= rs who actually use P2MR properly. > > >=20 > > >=20 > > > There are additional drawbacks to P2MR as specified in the current ve= rsion of BIP360. Bitcoin users activated Taproot a little over 5 years ago,= whose stated benefits include indistinguishable outputs between users of S= cript paths and non-Script paths, hide whether a Script path was present wh= en 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 t= he window 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 bit= coin exposed today due to address reuse is only a minority fraction of the = overall supply - about 5 million BTC at present. Still significant, but not= an overwhelming majority by any means. We have no reason to expect everyon= e will suddenly start reusing addresses consistently with P2MR, at least no= t any more than they already do. > > >=20 > > >=20 > > > Matt's arguing about maximizing the number of users/utxos safely migr= ated, not share of supply, so i don't think this is a valid counterpoint. T= he=C2=A0Milton-Shikhelman report from July 2025 estimated over 60% of exist= ing UTxOs reuse an address. > > >=20 > > >=20 > > > > 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-re= use today, they are mostly corporate cold wallets: binance, robinhood, bitf= inex, tether, etc, and these make up a significant chunk 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 target= s if they fail to do so. > > > >=20 > > > > So yes, even after taking address reuse into account, P2MR is more = secure than P2TRv2, and personally I think the safety delta between them is= wide 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= with lots of user feedback on top of that. > > > >=20 > > > >=20 > > > >=20 > > > > That's fair, it would be a difficult challenge to some low-effort w= allets not to receive coins to vulnerable addresses. But this argument impl= ies EC spending on P2MR isn't restricted in time - otherwise there is nothi= ng to exploit when addresses are reused, and so address reuse wouldn't matt= er. Under this same implication, P2TRv2 fares even worse. Concretely: > > > >=20 > > > >=20 > > > > - If EC spending is restricted, then both P2MR and P2TRv2 have ex= actly the same security profile and address reuse does not matter.=C2=A0 > > > >=20 > > > > - If EC spending isn't restricted, then both address formats are = vulnerable 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 dilemm= a square [^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 b= etter security by choosing P2MR. EC restriction is the only step which can = secure 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 betwee= n output types should not weigh on your mind. Your goal should be to push e= veryone to commit to an EC-restricting soft fork later (maybe have a look a= t BIP361 and contribute to that). The details of what output type is deploy= ed don't factor in. Again: the only difference between P2MR and P2TRv2 ther= e is that P2TRv2 needs a future soft fork to restrict EC spending, while wi= th P2MR this is optional, but still desirable (since some wallets will mist= akenly reuse addresses either way). > > > >=20 > > > > regards, > > > > conduition > > > >=20 > > > > [^1]: You can expand that prisoner's dilemma square into a cube by = asking whether a CRQC will be invented or not, and P2MR is still a strictly= better choice even if no CRQC appears - with or without EC restriction - b= ecause of its better script-path efficiency. > > > >=20 > > > >=20 > > > >=20 > > > > [^2]:=C2=A0For those rare few wallets who are: (1) willing to upgra= de, (2) NOT willing to use fresh addresses, and (3) NOT willing to depend o= n 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 lo= cking script. This allows them to reuse addresses at the cost of efficiency= . With a stateful signature (e.g. XMSS/SHRINCS), they'd be adding a few hun= dred bytes to their witnesses, and they'd be able to reuse the address thou= sands to millions of times. I could picture corporate cold-wallets using th= is technique, 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 wro= te: > > > > >=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 a= ctively migrating the opposite direction instead. > > > > > >=20 > > > > > > There is a huge difference between, we would prefer you don't r= euse addresses because privacy loss although privacy is hard to maintain an= yways and if you reuse addresses in this context a CRQC may steal your user= 's funds. > > > > > >=20 > > > > > > Wallets are likely to be more responsive here than in the past = because the stakes are much higher. > > > > >=20 > > > > >=20 > > > > > More, maybe. But I think you=E2=80=99re drastically underestimati= ng to what extent address reuse is baked into many flows. > > > > >=20 > > > > > For example most funds or very large holders have a pre-defined l= ist of addresses that they=E2=80=99re allowed to send to (basically exchang= e accounts to sell), and have processes in place to ensure everyone cross v= alidates that the address is on the list. > > > > >=20 > > > > > Yes, it=E2=80=99s possible to redo these, but people won=E2=80=99= t, they=E2=80=99ll just presume that they can move the funds again before a= CRQC. And many 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 > > > > >=20 > > > > >=20 > > > > > > > In the face of address reuse, P2MR has zero advantages over P= 2TRv2. > > > > > >=20 > > > > > > It's not binary. If say 1% of coins in P2MR have address reuse = because 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 = still wallets relying on a disable-EC soft fork before a CRQC. > > > > >=20 > > > > >=20 > > > > > > I am NOT suggesting or proposing this, but one could require th= at 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 dec= ides this is wallets advertising PQ functionality aren't actually PQ safe b= ecause this allow address reuse then one could solve the address reuse prob= lem in this manner. > > > > >=20 > > > > >=20 > > > > > Yes, i mean I think P2MR would be way more exciting if we had an = efficient 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 t= hat wallets which allow EC address reuse aren't PQ safe. If a wallet doesn'= t want to provide PQ safety why would they put in the engineering effort to= support 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 reasona= bly likely to be secured by the time a CRQC exists. Put another way, we sho= uld 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 sto= len 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 suc= cess. > > > > > > > > > > > > > > > > For instance, imagine we deploy P2TRv2, and we get EVERYONE= to migrate to it before a CRQC appears. We maxed out our stated success me= tric. But we might not disable P2TRv2 key-spending in a timely manner. If t= he future community fails to deploy at the right time, a CRQC can steal at = least as much bitcoin as they could've before the migration, if not more. W= e maxed 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 con= sequence of a more general but less easily-quantifiable goal: to design an = optimal, flexible, and long-term-secure PQ migration path. If we standardiz= e this and make code available to help, migration will come as a natural co= nsequence, 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= suggested alternative here isn't > > > > > > > actually a concreate goal. "optimal, flexible, and long-term-= secure" 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", a= nd the correct trade-offs to make on security. We all weigh different prope= rties with different values. > > > > > > > > > > > > > > > > For instance, I put more weight on conclusive security of P= 2MR, whereas Matt puts more weight on fee-efficiency and "privacy" of P2TRv= 2 [^1]. > > > > > > >=20 > > > > > > > I think I maybe under-stated my concern over the no-address-r= euse requirement for P2MR. We've been > > > > > > > trying to convince wallets to not reuse addresses for 15+ yea= rs and have not only had no success, > > > > > > > popular wallets have been actively migrating the opposite dir= ection instead. In the face of address > > > > > > > reuse, P2MR has zero advantages over P2TRv2. > > > > > > >=20 > > > > > > > > There are also differences of faith. Matt puts more faith i= n the future community to activate follow-up soft forks. I put more faith i= n wallet developers 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 of faith that a majority of the UTXO set will migrate in time, an= d we also share 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. Focu= sing on those who are the most likely to migrate does almost nothing to mov= e the needle on the total number of coins protected, nor, thus, on the prob= ability of a future Bitcoin community feeling the need to burn coins. > > > > > > > > > > > > > > > > Also agreed. > > > > > > > > > > > > > > > > > > > > > > > > I didn't find any public statements from your cited example= s about quantum security posture. Since it seems important to understand th= e wallets' stances in this dilemma, I posted a tweet tagging 8 major multi-= chain wallets [2] including the 3 wallets you cited as examples. I'm curiou= s what they'll say. > > > > > > > > > > > > > > > > Having worked with such wallets before, my expectation is t= hat they'll follow whatever is standardized, as long as it gives them more = market 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 = those building single-chain wallets. > > > > > > >=20 > > > > > > > Sure but no new key scheme is going to be an "npm install wha= tever" - it requires a rewrite of a > > > > > > > bunch of key derivation and backup schemes. P2MR is also aski= ng them 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 com= panies 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 as default, they often do so using A/B testing and incremental ro= llout 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 walle= ts' corporate executives and technical advisors. They will weigh the risk o= f introducing new, riskier, less-efficient code paths against the risk of a= CRQC appearing in the near future. We and other users can try to lobby the= m, but ultimately each wallet's decision makers must eventually convince th= emselves the CRQC risk is greater. Some will move too slowly, and many will= likely regret their choices one way or another. > > > > > > > > > > > > > > > > I believe we cannot effectively optimize away a problem lik= e this by tempting decision-makers with slightly lower fees, since that's n= ot 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 outpu= ts meaningfully faster than P2MR would, and that this trumps arguments abou= t post-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 unle= ss much of the ecosystem changes their > > > > > > > processes substantially. > > > > > > >=20 > > > > > > > -- > > > > > > > You received this message because you are subscribed to the G= oogle 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/msg= id/bitcoindev/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.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, s= end an email to bitcoindev+unsubscribe@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba= 5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/kkdcg1Bo7GsRcpH5gDpfZ1WZR-ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfS= h8eVhE-x2-fOXExE9x2b2V21m6kact8e4CSzNQ%3D%40protonmail.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/_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj= 8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs%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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= F0sSI3to9XSYx59YKqcc8WkM99HJwP18Cca56peuOmfMnPFEmptu61Mtjkv4wf8xLgzWbGjDKfy= fn9Ipi7OvDuajiWU7NnhmjHhdjFpxOcM%3D%40proton.me. -----------------------8a51379514e61f5fb68dad59b89f489b Content-Type: multipart/related;boundary=---------------------64d3cd84179d66464b880841396672a7 -----------------------64d3cd84179d66464b880841396672a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

=
My point is that Taproot i= ncentivizes users of advanced contracts to make their Script usage indistin= guishable from other usages.

I thi= nk I see what you mean. Matt made this point earlier. P2TR encourages the u= se of the key-spending path because its cost is forced on the user, who mus= t intentionally opt-out of using it (NUMS point), while with P2MR the user = can choose to save space by omitting a cooperative BIP340 leaf script. Then= they'd have a script tree with just a single spending path for some comple= x and easily-fingerprintable script which reduces their and everyone else's= anonymity set. I'll call this the 'single-leaf' pattern.

I have three arguments agains= t this point as a justification for P2TRv2:

  1. The number of people who are going to fit into this incentive funne= l would be small, so the effect on privacy for everyone else would be negli= gible. For a single-leaf script tree to be more efficient than a two-leaf s= cript tree, the difference between witness sizes for the cooperative vs unc= ooperative spending paths would have to be less than 32 bytes. Any larger a= nd it now pays to include a cooperative path. The larger the difference, th= e more well-incentivized a cooperative spending path would be. Though this = rules out extraneous factors like development effort, but still I expect th= e incentivized demographic will be tiny.

  1. This property can be argued as a feature: P2MR has some advanta= ge over P2TR in efficiency, under certain scenarios. It gives P2MR a reason= to exist even if CRQCs never appear. You're framing this property as a neg= ative because of the privacy implications, but we should consider the posit= ives as well.

  1. Finally, compared to the integrity of the UT= XO set, this is a bikeshed-level design goal. If we have to risk the securi= ty of everyone's coins, and commit o= urselves to perfectly timing a follow-up soft-fork that disables P2TRv2 key= -spending, then the privacy gain is not worth it.

Still, maybe we don't have to= take that risk to get the incentive structure we want.

What if we modified P= 2MR to require trees of at least depth 1? This way, t= he user must bear the cost of at lea= st two spending paths anyway, so they might as well use one for an everyone= -agrees BIP340 path. This mirrors the incentive structure of P2TR's non-opt= ional key-spend path.

99% of users (those building P2MR addresses properly) would not be aff= ected by this change anyway, because quantum-resistant hybrid addresses wou= ld be the specified standard for consumer wallets, and those wallets would = already have at least two script leaves. The downside of this is a loss of efficiency af= ter Q-day, for wallets which may only need a single PQ leaf (no point in us= ing an ECC leaf anymore).

Would = this assuage your concern about incentives?

regards,
conduition

On Wednesday, May 20th, 2026 at 12:49 PM, Antoine Poinsot <daros= ior@protonmail.com> wrote:
Hi Conduition,

My point is that Taproot incentivizes users of advanced contracts = to make their Script usage indistinguishable from other usages. I believe t= his is a desirable property because privacy is a common good, and because u= sers usually do not need to reveal differences in their spending conditions= .

=
If P2= MR is made available you will immediately see usage from people that are no= t interested in migrating to PQ cryptography, but simply do not want to pay= the cost of revealing the internal key in Taproot script path spends. This= does two things:
  • this preemptively aba= ndons some of the benefits of Taproot;
  • this makes any future soft fork to disable EC i= n P2MR context, which would be necessary to provide any PQ migration guaran= tee, extremely dubious.

Therefore i thi= nk alternatives that preserve Taproot's properties, like P2TRv2, are prefer= able.

Best,
Antoine
On Tuesday, May 19th, 2026 at 10:04 PM, 'conduition' via Bitcoin De= velopment Mailing List <bitcoindev@googlegroups.com> wro= te:
Hi Antoine, thanks for chiming in. 

There are additional drawbac= ks to P2MR as specified in the current version of BIP360. Bitcoin users act= ivated Taproot a little over 5 years ago, whose stated benefits include ind= istinguishable outputs between users of Script paths and non-Script paths, = hide whether a Script path was present when keypath is used, and incentiviz= e using such keypath in the first place (i.e. "doing the right thing"). I d= on't think we should throw all that out the window just now, if there are o= ther ways of mitigating CRQC risks.

I'm a bit confused by this fra= ming of P2MR. Once P2MR is deployed and in-use with hybrid PQC, it will hav= e the same practical privacy profile as P2TR prior to Q-Day, and an 'everyo= ne-agrees' path using BIP340 keys would still be almost as well-incentivize= d.

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 to ensure that any coins o= n P2TR addresses are moved to P2MR before Q-day.

<= /div>
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 Milton-Shikhelman report from July 2025 = estimated over 60% of existing UTxOs reuse an address.

Ahh, = I misunderstood. I'd be very curious to know more about the demographics of= those address-reusing UTXOs. If they're controlled by exchanges or other b= ig-bag-holders, then they're more likely to migrate in time. If not, well..= . At least BIP32 rescue protocols should be able to cover most of them, sin= ce 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-l= ists@mattcorallo.com> wrote:




> 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 "= 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/_3mqxJvqmo5uwzca07-KxjxELdI5NAL= 0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoX= s%3D%40proton.me.


--
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/F0sSI3= to9XSYx59YKqcc8WkM99HJwP18Cca56peuOmfMnPFEmptu61Mtjkv4wf8xLgzWbGjDKfyfn9Ipi= 7OvDuajiWU7NnhmjHhdjFpxOcM%3D%40proton.me.
-----------------------64d3cd84179d66464b880841396672a7-- -----------------------8a51379514e61f5fb68dad59b89f489b-- -----------------------0fe1d4d5177d9f22858b77acf5b27ad5 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== -----------------------0fe1d4d5177d9f22858b77acf5b27ad5-- --------fcfb7a2ee946077764d0b223f26fdd60eac52b1838e6033081be4bfc78ab549c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmoPI58JEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfhQ37EXrjDnKyFd1iu6J/6jSdLmj9lUHF5vrgr ERG1TRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABUmwEAoHTZyRwM+QU7T/y6 G0AAlHiyexENxoZdAxaY/jbp2rMBAJHGjdt3wyohk85ez5cyHWXdaX/4i47L WJMTDmzujUkG =gA/O -----END PGP SIGNATURE----- --------fcfb7a2ee946077764d0b223f26fdd60eac52b1838e6033081be4bfc78ab549c--