From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 18 Apr 2026 18:51:29 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wEHJo-0001BX-JA for bitcoindev@gnusha.org; Sat, 18 Apr 2026 18:51:29 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-428104abf43sf3564895fac.2 for ; Sat, 18 Apr 2026 18:51:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776563482; cv=pass; d=google.com; s=arc-20240605; b=f+J1r1zgPQNeJecMNWpd3yRQEXcFOawb/uUzleFK3hgeRz9oW9o6LJxIRPUFK3E+ZL CF01E1ERDSyM6/oNwfBOzpdRHFAF9hXOzkKB0/HfesDwxFiMBdYsuz84+5ewDeMRr018 CqS4bKJiZ09SvOIHm7mZOhnnHfTK54VXr5R0/I1YQgoIfbOprzVYNPRI2HbcLKDugWLL g7/LuTwImanZeQTgVl4n0ZP9VLvHwVja04hywGSy/61mVjvpmRHJd7ZravblMnL+tIgj lLVUvymA2teGO7US56aH/9q3YfgAFU1duKMV0RTR+q5lVs3tE6DNouMa3XTJ11GDO1+0 lmGw== 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:content-transfer-encoding :in-reply-to:from:content-language:references:cc:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=YKAmCysiezme1zlDPI2swRE6zljxXtAcQ+tEANo7rIc=; fh=SRAGAI8N7xCzK66dijJec87XwCK2quCRICDmSJlJ5+0=; b=VMQbRkfVHRmaB9LUxnKyl7GVJDA15da4vdkXsaRxRcLZcY1F3+Wgi81q0Tznvv20tw plFR84j8Kid8nYJ8HTS5cdb5zhs2KTffIIu4H7cDCb7HsfFqIzJvTv3d2RnibqjwCiIu pdKXwckHaWIr5AIOSEnbgWTojSVFWHw8n9y4OEwffiJiUblpelTPDPSM+7Cf4PQ2z/8a aljjLSDo1xh9A7bvgU4ju2p4UhUzJTrtqfWNvGiAHH2WDWly8wDwybOByaPwuwGk8C+d eytSUVRjDFqV1F0xsUFARKb64jfy7jbpHjnyXTJAP/0tTYfyif6Xvw360dzqyVdeZMfM Y1bQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776556862 header.b=Jkngh9iZ; dkim=pass header.i=@clients.mail.as397444.net header.s=1776556864 header.b=ujWlLM99; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776563482; x=1777168282; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=YKAmCysiezme1zlDPI2swRE6zljxXtAcQ+tEANo7rIc=; b=MuEtHw66QabI19wy2xADwvwLGY56Wv1fnCkLhNITudtiV1vfQcGhEzSWaDJwnc2DTd DpL+GeD1AoJikQ0MjDxcmAHRj40HnV+K+1CAI65xzxwS0uWMlIZUi62zh6dXYjhJSCc8 du3N1dBiyTrII2qOaPd1/CuozkBqsIwvZOWgbYAdGUkAP4lUK7ue1N6oOBUKUBEvsTVq hQeyYGmwD+bTZNpCYFH5/DTdy2yNgx45cC5Pz9XCZLAkTE5C12DflwKlAp3zl6KT2yTw dUQam+Hmb5YY5l3SZ5DvuScXpXgjf/tbFC9l4f3fjFRvW6YxiKrRJeOdGIJ++e/Ii6vG ficQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776563482; x=1777168282; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=YKAmCysiezme1zlDPI2swRE6zljxXtAcQ+tEANo7rIc=; b=V74q29M+o/ihHZn/Kn3KExUeKYD8bJ2+aGNqGl9qX7+qCrdygZ/L73OubtCaR/+nGX ra/3FDhZ91Z/JrrApkQAEWhNTejtn92HsS3Sl/4bkUh8JCOX3pjwLslx8jFU80LTfyUZ zgATtb/xcjD5GLrUVvV79mTpjQc2KGkc8PKM+yrMSbbxXicIdIf/vhDSrHr/6gw4aAd8 ZdgpFZg6JwuTqbK9kdrNjN7r/9XhP9KtW0BidmjRspFk+NNfWngOGSuk+9+DC2KmTL6W tvcpzLiFrngZltZL3sgm9g0eY9tDpYZjDLaqdcyqaNVRXI1zLznxxrBPz6j68na4HE3M VGig== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/4Mwg128OsE3Yb1H/Qv+mOpzV2nU1miJIh+1mERINQPzpnUguZSa9YZv/aXEXmFGxgP6txAFUneeAO@gnusha.org X-Gm-Message-State: AOJu0Yw6/s9jC1DApVKYdVwGUkLVonZ38kNQEqeect1PsA32WoI5JHL/ BVLFM8lsAibdthoPTPmzQtc6DFT1bcar6Y4KAHQfhjny4VYOQfuc3AJM X-Received: by 2002:a05:6870:e391:b0:423:c79:6a2a with SMTP id 586e51a60fabf-42aded665e4mr5326017fac.26.1776563481735; Sat, 18 Apr 2026 18:51:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKNOAclIovT/Ra3JM/r24TqU6oSad2ZaBUB9ylpAnk4qQ==" Received: by 2002:a05:6870:8c35:b0:41c:592a:81e9 with SMTP id 586e51a60fabf-4280be4713als1080431fac.0.-pod-prod-01-us; Sat, 18 Apr 2026 18:51:17 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/uqIZzjhZ40VEKbq6bpQsLlr+qlQ0Yy7jgCz+Hh/0sj3LT7P7UDkIv/PfrRWCImTqw9ODeRIAnYZKY@googlegroups.com X-Received: by 2002:a05:6808:2006:10b0:479:ab0d:706d with SMTP id 5614622812f47-479ab0d8292mr1909381b6e.19.1776563477055; Sat, 18 Apr 2026 18:51:17 -0700 (PDT) Received: by 2002:a05:620a:12c5:b0:8d6:1bc4:a7bc with SMTP id af79cd13be357-8e7920843bems85a; Sat, 18 Apr 2026 17:29:23 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9uvT6r9QJLORtoz0jP1+zuR6M2hClkz+Pgmi7bCrH+gW8BXil7vg+hwGAMvmodwqMP5AcXX9+nHvxF@googlegroups.com X-Received: by 2002:a05:622a:11d5:b0:50d:9ea9:7083 with SMTP id d75a77b69052e-50e36b40e3fmr125450661cf.24.1776558562598; Sat, 18 Apr 2026 17:29:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776558562; cv=none; d=google.com; s=arc-20240605; b=QISWoXgiy102C5ymoYEuHTY5XxmOdGfC28ngbe0noJHn3MV85gNBWn94WOoWSJlgqw y8MAQPd8KoTndOLerABTUx04HC7n1+s2Sf3mH57s37/C1WvL3ACmZsk1v1jmAgiQiMg9 egnPCqOfIP5br2aLzb+hmhiINSfsaMT4IDIqGTfxFQyC5vlsl1GpVBsQ+Cc9WmKqzDOj +DbHqkUOMKcbb9GWYMtpTRantwqdnezaSiROr0Hs4mxb4EOGhq8ziUPFCetdRBnrxeIL HzZOj3MmB5EQvJ+glIFJDU9zsTMrMQxB2nl51x0g+5EllXfZosEvsoV5uJpiXsHZ3d92 Y16Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=nSjcG/6BQ886HU27BWU3XbgdCdo13P3X99E6pP401qI=; fh=WrUyyu3mL4sxXQ2aR5jDpwrAN6zeUdtrDDUVJDZkThA=; b=KjSAWlM0f+iFpI99RyZUP5syMdozXL74yZP8Gn1ziotInnTjhKDPgnal7plu+x9R2r vMqjHuZwCZxZcHFguwjaMwNr2Ctg1/H7Pmuf3cdp03XnMNfly0AIoImt6O8uLUm06/6O opuEQKLNCcIVAqFpLSLkvnEhVqYYJD3IRGWYe4A9queUiOfC3+Lbcvt2XCeedhJZ0zoD G+pKc7VB/Uxq5swnuhX023h1Pu5TC8qorLeCE+N2EgjWlT83Sf5LZ03KYu0KxADli8FF WspPsYQ8TL8GK/ovpNsZbO74DcHEfotH+u+RtWFkGCTzVwzNimSL18gLi0f91dcSxacE 3fSg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776556862 header.b=Jkngh9iZ; dkim=pass header.i=@clients.mail.as397444.net header.s=1776556864 header.b=ujWlLM99; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8b02ae3dd54si2074686d6.7.2026.04.18.17.29.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Apr 2026 17:29:22 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1wEG2K-00000006aiZ-101z; Sun, 19 Apr 2026 00:29:20 +0000 Message-ID: <2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886@mattcorallo.com> Date: Sat, 18 Apr 2026 20:29:18 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] PQC - What is our Goal, Even? To: conduition Cc: Ethan Heilman , bitcoindev@googlegroups.com References: Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776556862 header.b=Jkngh9iZ; dkim=pass header.i=@clients.mail.as397444.net header.s=1776556864 header.b=ujWlLM99; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) On 4/18/26 11:44 AM, conduition wrote: > I think I maybe under-stated my concern over the no-address-reuse req= uirement 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 di= rection instead. In the > face of address reuse, P2MR has zero advantages over P2TRv2. >=20 >=20 > I think we agree that merely spec-ing out P2MR as "not safe to reuse" in = a BIP will be insufficient=20 > to prevent all address reuse. We also agree that /reused /P2MR and P2TRv2= share the same security=20 > profile, with or without a future EC restriction (which can be applied to= either output type). >=20 > But we seem to disagree in our conclusions. You believe that because of t= his overlap in security=20 > profiles, that we therefore ought to prefer P2TRv2 - presumably because o= f its short-term=20 > efficiency. I think that's a huge leap of logic. The overall security pro= file of P2TRv2 and P2MR are=20 > wildly different and you are only taking a subset of P2MR's profile into = account. >=20 > To reach your conclusion that P2TRv2 is preferable, you'd need to assume = that the vast majority=20 > users who migrate to P2MR will reuse addresses - vast enough of a majorit= y that the short-term=20 > efficiency savings of P2TRv2 key-spending outweighs the safety of the (pr= esumed) tiny minority of=20 > users who actually use P2MR properly. >=20 > We have historical evidence this assumption won't hold. Take a look at Pr= oject Eleven's bitcoin risk=20 > list metrics dashboard . The volume of=20 > bitcoin exposed today due to address reuse is only a minority fraction of= the overall supply - about=20 > 5 million BTC at present. Still significant, but not an overwhelming majo= rity by any means. We have=20 > no reason to expect everyone will suddenly start reusing addresses consis= tently with P2MR, at least=20 > not any more than they already do. >=20 > If anything, address-reuse will reduce, and not just because we ask them = to. If you look at the=20 > highest-value addresses at fault of address-reuse today, they are mostly = corporate cold wallets:=20 > binance, robinhood, bitfinex, tether, etc, and these make up a significan= t chunk of those 5 million=20 > exposed coins. We can reasonably expect those players to use P2MR properl= y out of self-interest -=20 > These coins will be the lowest-hanging fruit targets if they fail to do s= o. >=20 > So yes, even after taking address reuse into account, P2MR is more secure= than P2TRv2, and=20 > personally I think the safety delta between them is wide enough to excuse= the minor handicap in=20 > P2MR's pre-quantum efficiency. I think the gap between our views is that I don't buy that the "percentage = harm reduction" outcome=20 is all that interesting. Sure, there's some % where it certainly is, but it= s probably in the 99+%=20 range, not in the 75-90% range. I think maybe the biggest gap is I just don= 't find any "solution"=20 that results in 10-20% of bitcoin (*especially* active bitcoin people hold = keys to that made some=20 progress in migrating but maybe screwed up address reuse) being stolen as a= t all interesting. If we=20 manage to get 90% of active coins secured and then 10-20% of active wallets= get some of their funds=20 stolen, have we actually accomplished something grand, or is Bitcoin's repu= tation so shot that we=20 might as well pack it up and go work on some new fresh chain that is PQC fr= om day one? I'm fairly=20 confident the answer is the second, not just in that "we"'ve failed, but th= at the market will see it=20 the same way. Sure, in any solution set here there is going to be coins lost, but if some= one did the work to=20 migrate, having a high % chance of screwing it up isn't an interesting scen= ario to consider -=20 bitcoin is simply dead in that case. > P2MR is also asking them to overhaul a UX decision they made with lot= s of user feedback on top > of that. >=20 >=20 > That's fair, it would be a difficult challenge to some low-effort wallets= not to receive coins to=20 > vulnerable addresses. But this argument implies EC spending on P2MR isn't= restricted in time -=20 > otherwise there is nothing to exploit when addresses are reused, and so a= ddress reuse wouldn't=20 > matter. Under this same implication, P2TRv2 fares even worse. Concretely: >=20 > * If EC spending is restricted, then both P2MR and P2TRv2 have exactly = the same security profile > and address reuse does not matter. >=20 > * 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/=C2=A0reuse ad= dresses are vulnerable.> > In other words, P2MR is the Nash equilibrium of a prisoner's dilemma squa= re [^1]. >=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 better = security by choosing P2MR.=20 > EC restriction is the only step which can secure reused addresses of eith= er P2MR or P2TRv2 [^2]. Right, see above. Who cares if NN% of people used P2MR, accidentally had so= me address reuse, and now=20 their coins are stolen? Bitcoin is over. Great, some exchanges managed to p= rotect their coins and=20 probably some long-term holders, but a ton didn't, due to no direct fault o= f their own. What in the=20 hell is the point of bitcoin if so many lost coins without fault? > Thus, if you firmly believe that many wallets will reuse addresses and wa= nt to mitigate the=20 > vulnerability that follows, then the choice between output types should n= ot weigh on your mind. Your=20 > goal should be to push everyone to commit to an EC-restricting soft fork = later (maybe have a look at=20 > BIP361 and contribute to that). The details of what output type is deploy= ed don't factor in. Again:=20 > the only difference between P2MR and P2TRv2 there is that P2TRv2 /needs a= future soft fork to=20 > restrict EC spending/, while with P2MR this is optional, but still desira= ble (since some wallets=20 > will mistakenly reuse addresses either way). The selection of output types matters for other reasons, certainly the only= consideration is not who=20 will select which output type. Matt --=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/= 2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886%40mattcorallo.com.