From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 20 May 2026 13:47:04 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wPnok-0001eS-8t for bitcoindev@gnusha.org; Wed, 20 May 2026 13:47:04 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-439bb11e411sf9405783fac.3 for ; Wed, 20 May 2026 13:47:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779310016; cv=pass; d=google.com; s=arc-20240605; b=ZlIvwW/lGBh/iDTBo/MDcf2jFAbVrKpOF7cLLe/6X4U4JUsqgGsHoiSCSVMXSkt92s feB1uXdxYk+5xOpTikSHOdd/mkoneR6hQU+s+H8hPATuLlAzhORjhCRb4DSFPRkT/jwO ogag81ROK498t1lbhzvzY46l9c58psCV6DfX1GGkmjcIniT210nn/7O/8u0N2PpQWfit hDlnOWsDnJw0LyYWFL6n+icocNLkhQC0HsYj+NBQ/y/KelH++bN2VLT30eSoSUH6kRn0 8RXvgOTAhgA2s17/aitNIxtkJ06A1iD5xxLHB+qnkC+3/5PxxzDJ7GZ8XgJuQtW4TR/b dIhA== 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=+sl9brXO85jko2wqIMvjz74x38lUBfHN2PYs/VexOfs=; fh=QNrLCGChAcf3h/xG4LlQhCDyXyVBf6P1jGaJlAoXN74=; b=XhPsNfHxMZqoIHcH7OQj8ZWiKb6Wknew9jhovHetviSzbmErM1ymtUGi+QLGguwgis ZowaoZMEaf3Kvo/wMqvCj3tDSp6axz7AkhseWP4SUPB6k7Jp9uY4G6GZpLVTLYQzILnS 0sHQGgCAUYZWdPhu4EGZonfGEDlQsr2WmdAJkhuU0mxGFwuWDlfPJGZFd4CnvCdfVmzQ y9c4TQ1Z5Yf40nTmcCO4B3nrE2vbT/8+P4k/0zAMyWTd5a+sIAjGB3fi5xxKQc0ex17e smHrfQCYDj9wk4poFnwMfDnAytqB12wjg1DS7eUDuwv5hijMcaPmWZKj28uLq4IrekJc FDiw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=o3AKBgvw; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779310016; x=1779914816; 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=+sl9brXO85jko2wqIMvjz74x38lUBfHN2PYs/VexOfs=; b=sNC1mjFBuSWZDwq3MSPRB9eVr9S85wVzHio72Dbg8ko9tX8EeliZLoxAwDhn/DA/mQ MwxxLPBsbrtMeQXcghQkfOZfYP91f8fdkLj1fHL0sUC2h34+VfzCenGKgNNPrjQoLjJC P9E81d2rkMUjnvYi42lsg5B/6Q6GWjDC2QzbX6EVj/PWnZT0MQrUEKo1XSJNK5h2OEDn 6UQgLwTThNmcju7uD0y/AXzZrFuM7DNaqlGwuI86588mHflTx0nRL0z+TpdP17WjzXch yKKeMI8BbTZKdHIHWyPkawz/WRaWy/Cq/rf+qR28NtsYiORJa5J6GI0BW3rURAntcmlg ZHvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779310016; x=1779914816; 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=+sl9brXO85jko2wqIMvjz74x38lUBfHN2PYs/VexOfs=; b=KzUjWZgMigrxhLQiRdDujkNKaBcs0blE0lPnVI36btL8dUsvA55OBZJaAWylQGL+Hq lyddz3KhfyOIHOc57LyDl+OipQSP0Zzx1oSDnD2YP3GbFdYjqtUlAA41BYndzaXdfeYn K+UTTqAVaXxw0my05fr4kRF3ARb5Czr0a78MVGQke9kISZocRKvBlSSKvqIxfF4ze6+y GfDWSQ5VZda4fSp6tX+CGiWdg0R1NDkkekSTPmT8OXgGl+Dfc7NDqIfCtkNQeJ2PU42T QPmqXfZFHvLUtz6usl72KEqyrmgDe7oXzT3mvyhU59SaHZc+eKA44sXWrDdbSN5Mtz/x EX5g== X-Forwarded-Encrypted: i=2; AFNElJ9MyN16yqlwyoGUMwBJIzkTJ3Rq/3XlM2gxQ9B9jVLwMGzl3L/ex65SPcvIA8qsaA7Kx1OqXEyep6K7@gnusha.org X-Gm-Message-State: AOJu0YxNff8QipbL4shkwGOZaa47J3qej7q3Gk1LYB+QeAXB7ePo5o2g 0s0pGgvoY4Vas2+8mKH1IlcEUCY91N2T1hmVQ3C19MZDS2MnJe29TsY3 X-Received: by 2002:a05:6870:b611:b0:42c:ebc:7f53 with SMTP id 586e51a60fabf-43b2eb746cbmr130523fac.37.1779310015873; Wed, 20 May 2026 13:46:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOkaLX1/V4DfyfUoCMn+lPjhLxeI3mWteyYm+CvnaGB4g==" Received: by 2002:a05:6870:c229:b0:42c:d87:fc11 with SMTP id 586e51a60fabf-43a01d6719als6754698fac.1.-pod-prod-03-us; Wed, 20 May 2026 13:46:51 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8nvXBtJ+2yPtON59GZ63MQcqpkE03p71NJnpE8/9zr4ZycXdxenCggsPJrbsN+TexWAPdSPowjnBuW@googlegroups.com X-Received: by 2002:a05:6808:d51:b0:47c:b363:63a1 with SMTP id 5614622812f47-482e5943798mr16942169b6e.31.1779310010995; Wed, 20 May 2026 13:46:50 -0700 (PDT) Received: by 2002:ab3:7109:0:b0:301:73d0:a528 with SMTP id a1c4a302cd1d6-30173ef51cemsc7a; Wed, 20 May 2026 11:49:15 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ++wqO5WwDOtnSCGfhLbmfTQlQGtubGreWgGuzPdOviDt1bYY6DQfZ86lsZg+UEGnfH4gULk0e8slaA@googlegroups.com X-Received: by 2002:a05:6512:b9c:b0:5a8:ecfa:aaa4 with SMTP id 2adb3069b0e04-5aa0e76b34cmr8729716e87.35.1779302953532; Wed, 20 May 2026 11:49:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779302953; cv=none; d=google.com; s=arc-20240605; b=PMTnPNqn1tDbM9ySE6NldnvZW3hiPc3eQ1cKwePKju0goJdCaldlxYESmzSW8KhiJU chlBcy2X9UuBIPGopIXtJPBUdG+tzIwFfksH6E4A9VNy/6jOhLBz1DhTYOEo86qJogTW 6q73X56aO4QQaG8ov1qiykO9P5FeC5dmBwCT1DwEg4FJ2tEm8yzPPQUAssj/6Y1cQZaO gPe+Q9cQ2Upvuw6YYIDx+eLskXaoV1XE+1NkhHS2O8qhuZaXxFMrjoYOFd5hQZnm8orT N5MX/4dNNTsBciurHnHr/6mJBTN/2ZNPHLUwwtbDgWW3n0XaK/rz/tKdSNu/nGJPjEBj OSiw== 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=ZMklrUGSRSzP1MxrDtVwqcHD1tZSKG/zNeTaUtvfS3Y=; fh=wuzCZ0FAbCVPQi0X5sqdzGc1G3sXE3RMs2nfBrKO1jo=; b=V+z7OuHqo/NVgGZpbXW2sGiUUiVWtSVe9b5fxGeph+kF1b2VFMRI+KPQaOSX/Yh+rO y8wlMPLJUWZzRYG2FcqDykjGDPd1Z4D3yWj+jCK4WIyUBHi+rwMFLr0OypA1NTPZSGkO YubKmxGF+BIfRf7tC4nX9rUdVWuf3zmG11fXMtgkArKTB4qcOlS4aLSmtk1JDsGGvD2s Pe4GA0JimoR+pNptXkt1aZgLoXzNc0XZ2HKmeCyJkyrVJMmsbOcsAU4fadCNYpEZxVtl xnLbMZ7A+ZjuS+SM1AqrfPvvFYUdj9MS1FmNRlBH00sk5rgADqrI9OWIiR9N/1BXP4K1 76pw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=o3AKBgvw; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-395887500c9si2870131fa.6.2026.05.20.11.49.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 11:49:13 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22; Date: Wed, 20 May 2026 18:48:57 +0000 To: conduition From: "'Antoine Poinsot' 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: <3TguePkqzkPWZeuW8j7nrZnDnhmDpYfIh22hbInFeyVRwPX0Ohh7wjsptoNMnJAKwysYUGaGOaQVVx7se5WEeO-nmUEpcWUC_jKBWQrx4tI=@protonmail.com> In-Reply-To: <_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs=@proton.me> References: <_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs=@proton.me> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: db9cfef77b3892efd66894e1a4ecd3623d5c20b6 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_XHwWlbemOYb3YpFXQr8w2fIS9y5jYxHeGypwwotgT8Y" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=o3AKBgvw; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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 (-) --b1=_XHwWlbemOYb3YpFXQr8w2fIS9y5jYxHeGypwwotgT8Y Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition, My point is that Taproot incentivizes users of advanced contracts to make t= heir Script usage indistinguishable from other usages. I believe this is a = desirable property because privacy is a common good, and because users usua= lly do not need to reveal differences in their spending conditions. If P2MR is made available you will immediately see usage from people that a= re not interested in migrating to PQ cryptography, but simply do not want t= o pay the cost of revealing the internal key in Taproot script path spends.= This does two things: - this preemptively abandons some of the benefits of Taproot; - this makes any future soft fork to disable EC in P2MR context, which woul= d be necessary to provide any PQ migration guarantee, extremely dubious. Therefore i think alternatives that preserve Taproot's properties, like P2T= Rv2, are preferable. Best, Antoine On Tuesday, May 19th, 2026 at 10:04 PM, 'conduition' via Bitcoin Developmen= t Mailing List wrote: > Hi Antoine, thanks for chiming in. > >> There are additional drawbacks to P2MR as specified in the current versi= on of BIP360. Bitcoin users activated Taproot a little over 5 years ago, wh= ose stated benefits include indistinguishable outputs between users of Scri= pt 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 we 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 practical privacy profile as P2T= R prior to Q-Day, and an 'everyone-agrees' path using BIP340 keys would sti= ll be almost as well-incentivized. > > For anyone who does truly need the savings of key-path spending, P2TR sti= ll exists and can be used. Nothing is being "thrown away" - you'd just need= to 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 migrate= d, 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 UTxO= s reuse an address. > > Ahh, I misunderstood. I'd be very curious to know more about the demograp= hics of those address-reusing UTXOs. If they're controlled by exchanges or = other big-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 th= em, since most end-users hold coins in BIP32 wallets. > > regards, > conduition > > On Monday, April 20th, 2026 at 3:51 PM, 'Antoine Poinsot' via Bitcoin Dev= elopment Mailing List wrote: > >> Hi Conduition, >> >> Just a couple points on address reuse. >> >> On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin Deve= lopment Mailing List wrote: >> >>>> I think I maybe under-stated my concern over the no-address-reuse requ= irement for P2MR. We've been trying to convince wallets to not reuse addres= ses for 15+ years and have not only had no success, popular wallets have be= en actively migrating the opposite direction instead. In the face of addres= s reuse, P2MR has zero advantages over P2TRv2. >>> >>> 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 P2MR 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 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. >>> >>> 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. >> >> There are additional drawbacks to P2MR as specified in the current versi= on of BIP360. Bitcoin users activated Taproot a little over 5 years ago, wh= ose stated benefits include indistinguishable outputs between users of Scri= pt 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 we should throw all that out the = window just now, if there are other ways of mitigating CRQC risks. >> >>> We have historical evidence this assumption won't hold. Take a look at = [Project Eleven's bitcoin risk list metrics dashboard](https://www.projecte= leven.com/bitcoin-risq-list/metrics). The volume of bitcoin exposed today d= ue to address reuse is only a minority fraction of the overall supply - abo= ut 5 million BTC at present. Still significant, but not an overwhelming maj= ority by any means. We have no reason to expect everyone will suddenly star= t reusing addresses consistently with P2MR, at least not any more than they= already do. >> >> Matt's arguing about maximizing the number of users/utxos safely migrate= d, 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 UTx= Os reuse an address](https://pq-bitcoin.org/posts/bitcoin-qva-1#fig-reuse-p= ercentages). >> >>> 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. >>> >>> 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. >>> >>>> P2MR is also asking them to overhaul a UX decision they made with lots= of user feedback on top of that. >>> >>> 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: >>> >>> - If EC spending is restricted, then both P2MR and P2TRv2 have exactly = the same security profile and address reuse does not matter. >>> >>> - If EC spending isn't restricted, then both address formats are vulner= able when reused, and P2TRv2 exposure is worse because even those who don't= reuse addresses are vulnerable. >>> >>> In other words, P2MR is the Nash equilibrium of a prisoner's dilemma sq= uare [^1]. >>> >>> - 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 >>> >>> 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]. >>> >>> 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). >>> >>> regards, >>> conduition >>> >>> [^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. >>> >>> [^2]: For those rare few wallets who are: (1) willing to upgrade, (2) N= OT 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 hybri= d address formats which use ECC and hash-based sigs in the same locking scr= ipt. 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 hundred byte= s to their witnesses, and they'd be able to reuse the address thousands to = millions of times. I could picture corporate cold-wallets using this techni= que, but maybe not retail wallets. >>> >>> On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo wrote: >>> >>>>> On Apr 17, 2026, at 18:04, Ethan Heilman 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 wallets have been actively= migrating the opposite direction instead. >>>>> >>>>> There is a huge difference between, we would prefer you don't reuse a= ddresses because privacy loss although privacy is hard to maintain anyways = and if you reuse addresses in this context a CRQC may steal your user's fun= ds. >>>>> >>>>> Wallets are likely to be more responsive here than in the past becaus= e the stakes are much higher. >>>> >>>> More, maybe. But I think you=E2=80=99re drastically underestimating to= what extent address reuse is baked into many flows. >>>> >>>> For example most funds or very large holders have a pre-defined list o= f addresses that they=E2=80=99re allowed to send to (basically exchange acc= ounts to sell), and have processes in place to ensure everyone cross valida= tes that the address is on the list. >>>> >>>> Yes, it=E2=80=99s possible to redo these, but people won=E2=80=99t, th= ey=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 >>>> >>>>>> In the face of address reuse, P2MR has zero advantages over P2TRv2. >>>>> >>>>> It's not binary. If say 1% of coins in P2MR have address reuse becaus= e 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 effic= ient way to enforce addresses as single use directly in consensus. I=E2=80= =99m not, however, aware of one. >>>> >>>>> All told, it seems better to communicate to wallets and users that wa= llets 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 suppo= rt P2MR and PQ sigs. >>>> >>>> Because there will be marketing for =E2=80=9CPQ safe=E2=80=9D and no o= ne (but us) will actually care about the distinction or bugs :). >>>> >>>> Matt >>>> >>>>> On Fri, Apr 17, 2026, 17:02 Matt Corallo w= rote: >>>>> >>>>>> 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= 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 migr= ate to it before a CRQC appears. We maxed out our stated success metric. Bu= t we might not disable P2TRv2 key-spending in a timely manner. If the futur= e 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. We maxed = out our success metric but still failed, so that metric must not be our onl= y goal. >>>>>>> >>>>>>> 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,= flexible, and long-term-secure PQ migration path. If we standardize this a= nd make code available to help, migration will come as a natural consequenc= e, 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 sugges= ted alternative 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 c= orrect trade-offs to make on security. We all weigh different properties wi= th different values. >>>>>>> >>>>>>> For instance, I put more weight on conclusive security of P2MR, whe= reas 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 re= quirement for P2MR. 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 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 fu= ture community to activate follow-up soft forks. I put more faith in wallet= developers following standards and in users proactively migrating to PQ-sa= fe wallets. >>>>>>> >>>>>>> Based on Matt's previous emails, I think we both share the same LAC= K of faith that a majority of the UTXO set will migrate in time, and we als= o 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. 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 = quantum security posture. Since it seems important to understand the wallet= s' stances in this dilemma, I posted a tweet tagging 8 major multi-chain wa= llets [2] including the 3 wallets you cited as examples. I'm curious what t= hey'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 s= hare and as long as they can "npm install whatever" to implement it. I'm no= t trivializing here - These devs are just spread much thinner than those bu= ilding single-chain wallets. >>>>>> >>>>>> Sure but no new key scheme is going to be an "npm install whatever" = - it requires a rewrite of a >>>>>> bunch of key derivation and backup schemes. P2MR is also asking them= to overhaul 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 a= re typically very concerned about bugs in new code paths, and they weigh th= is risk against the benefits of any new feature. When deploying new feature= s as default, they often do so using A/B testing and incremental rollout te= chniques. So the earlier question shouldn't be binary. It becomes: How quic= kly will major wallets roll out PQ outputs as default? >>>>>> >>>>>> Fair, true point. >>>>>> >>>>>>> Rollout pace will depend on the personal views of the wallets' corp= orate executives and technical advisors. They will weigh the risk of introd= ucing new, riskier, less-efficient code paths against the risk of a CRQC ap= pearing in the near future. We and other users can try to lobby them, but u= ltimately each wallet's decision makers must eventually convince themselves= 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 like this b= y tempting decision-makers with slightly lower fees, since that's not all t= hey are worried about. I believe we especially should not try to do so at t= he expense of conclusive PQ security and long-term optimization. >>>>>>> >>>>>>> I think the crux of the P2TRv2 vs P2MR disagreement here is that Ma= tt believes P2TRv2 will induce wallets to roll out default PQ outputs meani= ngfully faster than P2MR would, and that this trumps arguments about post-q= uantum security or efficiency. >>>>>> >>>>>> No, its far from just about fees. Its also about maintaining the goa= ls 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 G= roups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, se= nd an email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%= 2Bunsubscribe@googlegroups.com). >>>>>> To view this discussion visit https://groups.google.com/d/msgid/bitc= oindev/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com. >>> >>> -- >>> 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. >> >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/kkdcg1Bo7GsRcpH5gDpfZ1WZR-ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8e= VhE-x2-fOXExE9x2b2V21m6kact8e4CSzNQ%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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8o= nXRUvaTXW4g_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/= 3TguePkqzkPWZeuW8j7nrZnDnhmDpYfIh22hbInFeyVRwPX0Ohh7wjsptoNMnJAKwysYUGaGOaQ= VVx7se5WEeO-nmUEpcWUC_jKBWQrx4tI%3D%40protonmail.com. --b1=_XHwWlbemOYb3YpFXQr8w2fIS9y5jYxHeGypwwotgT8Y Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Conduiti= on,
My = point is that Taproot incentivizes users of advanced contracts to make thei= r Script usage indistinguishable from other usages. I believe this is a des= irable property because privacy is a common good, and because users usually= do not need to reveal differences in their spending conditions.

If P2MR is made a= vailable 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 spends. This does two th= ings:
=
  • this preemptively abandons some= of the benefits of Taproot;
  • this makes any future soft fork to disable EC in P2MR con= text, which would be necessary to provide any PQ migration guarantee, extre= mely dubious.

Therefore i think alterna= tives that preserve Taproot's properties, like P2TRv2, are preferable.

Best,
Antoine
On Tuesday, May 19th, 2026 at 10:04 PM, 'conduition' via Bitcoin De= velopment Mailing List <bitcoindev@googlegroups.com> wrote:
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-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 "= 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/= 3TguePkqzkPWZeuW8j7nrZnDnhmDpYfIh22hbInFeyVRwPX0Ohh7wjsptoNMnJAKwysYUGaGOaQ= VVx7se5WEeO-nmUEpcWUC_jKBWQrx4tI%3D%40protonmail.com.
--b1=_XHwWlbemOYb3YpFXQr8w2fIS9y5jYxHeGypwwotgT8Y--