From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Jun 2026 17:41:10 -0700 Received: from mail-oo1-f60.google.com ([209.85.161.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1waNIB-0001ND-PU for bitcoindev@gnusha.org; Thu, 18 Jun 2026 17:41:10 -0700 Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-69efcc71a1fsf1763539eaf.0 for ; Thu, 18 Jun 2026 17:41:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781829661; cv=pass; d=google.com; s=arc-20240605; b=BU6bIxqG37ZJXqGo2vbXuaW6s2sysNI9IDglhA3PGuYGIK5Ccekdo531E74hdJpuc3 a/Vf690f6cyQyLe1d2j6+B8AXcrTa1nIgfp3e1s5/9/7v8IR8a4ScUZ2/HlwGGhZN/Ev dNl99H00/LtN2iag71JJbg/FL4zq0PalDf2ftdfHf7XPe9Vta68qDNVYAjGya80+nVCS A/CnTFDAG7R9Iz3sUGsc7iqYrq8MTRk/EloOVPZQaOJANKbse6z6IoqSDRJxE5/C+c7t nwC/YI1B6iqNGzrQ4SCcUei69cmiV5xs+mmO4rmXZEqRCT0Bl78p17C3M5nWPnZiuup4 IFRg== 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=QZEcc/5cyC2YWDU8a7mF0ehOBjECFNvvz3B3+cJ4ooc=; fh=MJbS2tCoj0aRpTOveF1dpM1AqEw1nHJHMHKC8berVr4=; b=geAY3Rp7RaXSdFNTvu0f4vy7d7vSAEopBOJw/QNDUOEa2/yGtEwY9niSNOzluvs1QU h8Y/g+5USy6K4CnsEyTTp/y4bsErKHT1QG2fUcGj4Nc9Dv6wH6u9wl473jDti2+U3lDb H4tgQ2kUOppnvEqW19Zn/NyDbFYxpLTKRxz5t5AtMxyiXb+qsphiteCrTWxb4vaRrl+3 ayczhTW1Jnkd7Imc+fxpzp15RG/mjsAZtmOFilyd87fGgIEP3+aJHIqsPhul1LBZOzAb FDfstBtrg7tuBnBIs7571Aa3suA2zU3Z9wp5glrHqlxlDhZVa+Zzsxa+Cb7y4omh/KwI orbg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=RomBsQ9D; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 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=1781829661; x=1782434461; 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=QZEcc/5cyC2YWDU8a7mF0ehOBjECFNvvz3B3+cJ4ooc=; b=lgQ9iMyFmTBe4H6cLaRi0l68bCOWCbSNxo71oR6IgbuqT3zH3RJNNJ8g4SdsdQ+Sri 8j8w2VlBJgOnkpgyWUsgKWQMKZNpwItQE2vFJ3aYRbGn/r/vq8EP8EYZlFBoqAPChdu1 RGnXNpF5w9tsjsKWthhWIZHC9e7FXFT72BdGizwnNqMzZ653MSO+c3OpWKRm39J4H15s Hmh2JCIOow5iC8YuRQxj/R/qnTWc4b7qJlKxSQ56knm+AL7OOxSGRb/edL9s4V65IYOl h2ROiw3uswLa834vpp6RlDIqQxteMiSd3yasvD7X7KT+XWiOdqdOYKtQNT5WgHn9if1r JHAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781829661; x=1782434461; 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=QZEcc/5cyC2YWDU8a7mF0ehOBjECFNvvz3B3+cJ4ooc=; b=bXIFP/lHE8H2BodwJRwm4EVSveWUZqjy8qpDqszUKt9IufmZ8ZXjJTdfSHaWFVJ/e6 t3VkoUfDSrQV7FD9BxU0vHZBeNFEZylOr/EsJC21hKAv+rT786rcA7UQ8LVIIQw7D+3+ Ii/wDAnR8o/UDBCjskUH31ivIJ52w15N0m/juTM+fKVoMPD/CCw+YO3FmPORj92kZyRm w1iotSHLi4KMN04EidBXaPf3z1dN9U8PWQqKoaj2Q5pL3SNVqn2Hq+5dgehwF/TCgnUn 8EpMr8DLFuFS4nhawH3EkiqRr4n3MRWyZhGxQnWgivdTTOM0Xhbyfjm0Tcq0UhJLNXGW 4stQ== X-Forwarded-Encrypted: i=2; AFNElJ/xFJ0sFPB8ysI2QLfG99ZCBk9j2vVVkUI7kEa86IAXMsh7dxE4Zz888nqd7BMQEE6Dcm5L0/rsmkiE@gnusha.org X-Gm-Message-State: AOJu0YzEKmdRIdryHSFhBK1cRZeS2aJvPa/CsO8qA/iR+rZ8PbpcP64B d0nl4L/k8f5G7pPqVsj3UwTu1u1ESiBBDXh7M/+TPq/5WzTztn481IPC X-Received: by 2002:a05:6820:709c:20b0:6a0:dd5b:b3a6 with SMTP id 006d021491bc7-6a0dd5bb636mr386016eaf.39.1781829661456; Thu, 18 Jun 2026 17:41:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUeuLWBB6pdm2AWudHF7PCWjyPp2x7bSnjBuj0kwmjnjPg==" Received: by 2002:a05:6820:3083:b0:696:77d2:4757 with SMTP id 006d021491bc7-6a0c6bad851ls1113377eaf.1.-pod-prod-06-us; Thu, 18 Jun 2026 17:40:57 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ++Cp0ylGw7kQCwgpeExxx3daLG/ie2T9Px/iKEDg8OFsHQbIAX+0ZnIIA0984Gcv38mFEUygmut5wO@googlegroups.com X-Received: by 2002:a05:6808:13d3:b0:489:94d0:1ffe with SMTP id 5614622812f47-48994d0272amr826282b6e.2.1781829657089; Thu, 18 Jun 2026 17:40:57 -0700 (PDT) Received: by 2002:a05:6402:24d6:b0:688:32f8:dedb with SMTP id 4fb4d7f45d1cf-696e5220a20msa12; Thu, 18 Jun 2026 17:38:41 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8XuqCye9Ze466cv9I4Ax2bS3AWcTFy/C7c5Dk5fxWCHzVLHgEVIKi6v1qZ9Gh5+pDPszezVIiLmFzs@googlegroups.com X-Received: by 2002:a17:907:7ba7:b0:c07:2c22:a6fe with SMTP id a640c23a62f3a-c098eb2c41fmr66441166b.47.1781829519525; Thu, 18 Jun 2026 17:38:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781829519; cv=none; d=google.com; s=arc-20240605; b=LnpFMuFZxv3E3+eI8/nD80u2LEOnlkf22+kMZ6sPyVyYHfeJGQ8NBYMm78sfYxTnnI osski+qHNwJcpKA7+ySjl5dbas01AYxmBcY1qbpWWTURhlNcDEfkSUBasLmuGbl1Gp7Z K+2l96x5U3Ask+Yp/dDPWXJGjBbQuJU42Li+OEMBtY2z5l6DT9WcobWjI9leWTqBQQY4 vSGbX4EuGOVpsis0mex9gUjbh4k9jdoHAJaztY2XGcCNR1G0U4y8jDeZSxgozjb3diUR e7rMvzS5qCpIxolgJOe02i3FXaZ/VR7WbccJlmWgx2BnnmOjIbQLsYAPgpJtYNJfwIJr qpXg== 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=Vkv2Di5OA2YKPxLzuiv8voZeUZysh0TJypHjAubNHlE=; fh=x2RhTgREnGL9Pud95B3Kk4+0Ujvb9srG2TsazUqHlF4=; b=UmF+q7N9bpIq/Jr4bHOK2wuzhI+fYBRhtbYTHTnsic/jsAjIaS767ybDmBG1/rphHk NFgm1ttCiFajGyXDloEPnE4PvkNLRTx7iWFhzYSMU2eh8EErGE4aO4h5+/5M1AaZ+y8B XqmjeMbx7eUH2qqagLqGavVfq7KqP42KJ5FWNEVDk4k5pK5H6HJOaUC/ze3mv6E6baSV LzbLn9jml9XX2E0vqRt+f9yuxE2BLPy1lY9Yyg3x83bCQ5AEaOurRkcv13kwhtxMHZtW Kx8aF0NRgjAGpzffGMNTJckOI27LxGUcp2sU4H/KynGUDYfjBU+X5mWOelYpp2UUDRyo g2Sw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=RomBsQ9D; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch. [185.70.43.19]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-69711e077e6si25503a12.3.2026.06.18.17.38.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 17:38:39 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) client-ip=185.70.43.19; Date: Fri, 19 Jun 2026 00:38:32 +0000 To: Anthony Towns , Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: Antoine Poinsot , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: In-Reply-To: References: =?us-ascii?Q?_____<=5Fz6=5FJUmphCkUYvI6gemSFMD9Sb=5FrDL03IQbtZQCNlk6pmioGEQBir=5FgMyZCfticFa8Ttfc0xoFHdxR07=5FMNuAfBu8do=5Fh5IDf2apVk1w1BM=3D@wuille.net>__<81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3U?= =?us-ascii?Q?e5E4zc2qWYn65gRxmmFLKg=3D@wuille.net>_?= Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 1594e5aa521b0d08aa06ceb1b2ad0cb24c45f2ec MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------5d3a6e60565ce036229a51209e114575cf5cf627d0008839270e08236506812d"; 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=RomBsQ9D; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 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) --------5d3a6e60565ce036229a51209e114575cf5cf627d0008839270e08236506812d Content-Type: multipart/mixed;boundary=---------------------d35c7cfa3fcfe2844cce13b70b038c0e -----------------------d35c7cfa3fcfe2844cce13b70b038c0e Content-Type: multipart/alternative;boundary=---------------------811102703eecb224bf020894c167c71d -----------------------811102703eecb224bf020894c167c71d Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Now I have some points I'd like to respond to about rescue protocols. This = is largely tangential to the P2MR/P2TRv2 question. > In either case, I consider anything that requires hardcoding specific wal= let designs (BIP32 or otherwise) into Bitcoin's consensus rules (and only a= llowing those coins to survive) to be squarely in disaster-recovery land. I= t feels like embracing arbitrariness, and giving up on the permissionlessne= ss that makes Bitcoin interesting It's fair to say such a solution is arbitrary, insofar as the knowledge asy= mmetries like BIP32 CKD are arbitrary. But can you propose any alternatives= which are not arbitrary? I would not count=C2=A0hoping=C2=A0for majority migration=C2=A0to be a vali= d solution. We ought to consider and plan for the contingency that migratio= n to the PQ output type is=C2=A0underwhelming, even if that is not the=C2= =A0best=C2=A0outcome, because such an outcome is still likely even if the n= ew output type were magically 10x cheaper and more private than P2TR. > My impression is that your approach is to have an answer for many possibl= e futures, including ones where Q-day arrives within just a few years. But = optimizing for disaster-recovery also means reducing the chances of preserv= ing Bitcoin as we know it in the scenarios where a successful migration is = still possible. And if Q-day does arrive that soon, I don't see what we can= do today that would preserve Bitcoin in a form we care about anyway. By ac= cepting that, we can focus on the futures where our choices today can still= materially improve the outcome. Mostly yes. I gotta agree with AJ's quote here. In chess, one wins by forci= ng the worst possible outcome to be victory. In probabilistic games, one wi= ns by maximizing the chance of success and minimizing the cost of failure. = We should be doing the same thing here. A quantum "disaster recovery" scenario, as you put it, is absolutely worth = optimizing for IMO, because with our current trajectory it seems very plaus= ible, and yet its severe consequences can be mostly mitigated at little cos= t. I don't think we should abandon such survivable scenarios just because t= hey're less palatable than others. I dispute that rescue protocols would discourage PQ migration. Quite the op= posite: They=C2=A0force=C2=A0PQ migration even for inactive users, by turni= ng vulnerable UTXOs into PQ-safe ones retroactively. Even if rescue protocols do massively discourage migration to PQ outputs, t= his would be of little consequence exactly because rescue protocols would= =C2=A0exist (which is their beauty). Even in the most extreme case where we= deploy a PQ output type and exactly=C2=A0nobody=C2=A0migrates to it, we ca= n still use rescue protocols to achieve the same rate of ownership-preserva= tion as if all quantum-recoverable coins (BIP32, hashed addr, etc) had migr= ated to PQ outputs=C2=A0immediately. It'll be less efficient and more awkwa= rd, but far from hopeless. Again, the real target demographic that we need to focus on migrating=C2=A0= is the=C2=A0quantum unrecoverable subset, i.e. coins which have no quantum-= hard knowledge asymmetry, like satoshi's coins, P2PK wallets, and JBOK wall= ets with exposed pubkeys. If we expect to have rescue protocols, then we do= n't really care what address format these coins move to, as long as it's to= =C2=A0something=C2=A0quantum-recoverable. But convincing them to move at al= l seems hard, because their owners are probably dead or the keys are lost. = How to handle such coins after Q-day is an open question, and it seems to b= oil down to the good old "freeze-or-steal" debate. > If Q-day comes before migration can reach meaningful levels (what those a= re is probably a matter of perspective), then I think there isn't much of a= n interesting future for Bitcoin anyway. The future is only as interesting as we make it. Even if Q-Day comes before= most coins migrate, we have an opportunity to make that future interesting= , using rescue protocols. Maybe some folks don't want to work on them or wo= uld rather sell their coins first, and that's totally valid, but I implore = you to at least keep your mind open to the possible futures that rescue pro= tocols open up, because it is unclear exactly which future we are bound for= and I'd rather that neutral internet money still exists in each of them. We have to play the cards we are dealt, and right now we've been dealt a ve= ry fortunate hand=C2=A0because of BIP32=C2=A0(thanks to you sipa!): Most us= ers have at least=C2=A0some=C2=A0secret knowledge that a CRQC cannot forge,= and that's a pretty awesome privilege, one which even extends to other blo= ckchains whose wallets use BIP32, or its derivatives. You should be very pr= oud of that IMO=C2=A0=F0=9F=99=82 > Disaster-recovery: neither the "predictable/planned consensus change" of= =C2=A0Later nor the "everyone takes responsiblity for their own funds" work= s, and the only way to avoid a large percentage of bitcoin becoming a rewar= d for quantum research is to replace EC spend paths with a ZK proof of know= ledge of a BIP32 seed or similar, requiring=C2=A0a hard fork. @AJ rescue protocols can be deployed via soft fork, because we'd be constri= cting rules and not relaxing them. We'd require any EC spends to also=C2=A0= satisfy the rescue protocol in addition to the existing consensus rules (si= gnatures etc).=C2=A0Of course, there might be external reasons to deploy it= as a hard fork, e.g. to roll back mass theft if we don't time things right= , or to disentangle from quantum-theft advocates,=C2=A0but I think we shoul= d aim for soft fork compatibility if possible. > the "quantum-safe" hard-fork variant=C2=A0of bitcoin would be fairly desc= ribed as a utxo-bootstrapped altcoin, would compete in the market with the = "quantum-unsafe" bitcoin thatexisting nodes would continue to follow, and p= ossibly there would be=C2=A0many slightly varying such altcoins competing w= ith each other, eg on exactly what height the utxo snapshot was taken or wh= at coins become spendable. It would not be a fun time for holders of affect= ed utxos. I really hope we do not end up in a situation with competing rescue protoco= l deployments. I don't think snapshots are necessary so that's not really a= factor. As for the exact conditions which permit rescue... that could indeed get di= cey if we need to collate a bunch of different rescue protocols into one Fr= ankensteinian mess. The most popular proposal will probably be one which co= vers all the most common hard-relations, but this still needs more research= . If we think of rescue protocols more abstractly, the spender just needs to = prove their script pubkey commited to a quantum-hard relation, and that the= spender knows the witness to that relation. It doesn't actually matter whi= ch exact relation - BIP32, hashed address, musig, whatever - just that it's= quantum-hard. Maybe there is a way to formulate a two-step proof system ge= neral enough to rescue UTXOs with any such relation, by first proving the r= elation is quantum-hard, then proving you know the witness to the relation.= That would be awesome but still an open problem. regards, conduition On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns aj@erisian.com.au = wrote: > On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote: >=20 > > I want to first correct a potential misunderstanding here, because > > I realize the terms "Later" and "Never" aren't very descriptive. They > > are specifically about an expected and relied-upon expectation that an > > EC-disabling fork will happen that at least applies to the output type > > itself, in time. "Later" is the expectation that such a disabling will > > happen after the output type is introduced, but still in time (so, befo= re > > Q-day). Outputs without a strong expectation that their EC paths/opcode= s > > will be disabled, or not in time, I classify under "Never". >=20 > > I believe here you're instead arguing for P2MR ("Merkle-Never") > > over all "Later" options. That was my previous point: I think (solely) > > having "Never" output types like P2MR is just utterly insufficient for > > any worthwhile migration. It's so incompatible with today's workflows > > that it either won't be adopted, or (possibly inadvertently) adopted > > in an insecure fashion. Yes, it gives people the option to safeguard > > their own coins, but to me that's disaster recovery territory - I think > > we ought to prioritize maximizing the chances for saving the currency > > as a whole in case Q-day comes, not a small subset of individual users' > > coins. P2MR (alone) doesn't really achieve much in that regard in my vi= ew, > > thus we at least need something of the "Later" class in addition. >=20 > I'm not sure I follow/agree with the logic here. I think the general idea > is: >=20 > 1) we create some new address types that allow post-quantum spending, but > also allow efficient quantum-vulnerable spending that can be used prior > to Q-day >=20 > 2) many people migrate to these new address types >=20 > 3) Q-day arrives >=20 > 4) all spending goes via the post-quantum paths, and everyone's funds are > safe >=20 > There are three main variations to this, I think: >=20 > Later-dominant: towards the end of (2) but prior to (3), the > quantum-vulnerable spend paths are disabled in a predictable, planned > manner, preventing coin theft, but not disrupting active usage > significantly (or not disrupting it any more than the proximity of > Q-day already is). >=20 > Self-reliance: Q-day goes from maybe to definitely faster than consensus > changes can be coordinated, and the only reason people's funds remain > safe is that they can (and do) keep the quantum-vulnerable spend > paths secret. >=20 > Disaster-recovery: neither the "predictable/planned consensus change" of > Later nor the "everyone takes responsiblity for their own funds" > works, and the only way to avoid a large percentage of bitcoin > becoming a reward for quantum research is to replace EC spend paths > with a ZK proof of knowledge of a BIP32 seed or similar, requiring > a hard fork. Such a hard fork would be certain to be controversial > ("why at this height: I received a payment five blocks after // > my funds were stolen by a quantum attacker five blocks earlier // > why are only BIP32 funds recoverable not scheme X"), but if no other > approach works, might still be the ultimately outcome. >=20 > > So the point here was just: if you already accept the need for a "Later= " > > output type (=3D one with builtin-in EC disabling expected from the sta= rt), > > P2TRv2 is preferable over P2MR+ED, because: >=20 > As far as I can see, only having P2TRv2 addresses would rule out the > "self-reliance" path here. >=20 > Picking when Q-day will occur, either individually for determining > your own security posture, or collectively for organising a consensus > change seems very difficulty: it involves evaluating both complex state > of the art physics research, but also estimating the covert abilities > of national governments and the incentives to attack bitcoin prior to > revealing their capabilities. To me, that doesn't bode well for a smooth > and fast deployment of a consensus change in advance of problems occuring= . >=20 > It's possible that general carelessness on behalf of users would also > rule out the effectiveness of a self-reliance approach: if only the most > conscientious 1% of users make use of P2MR securely, that might secure 10= % > of funds, but having 90% of the bitcoin supply crash probably wouldn't be > very valuable either. But even then, that may make the "disaster-recovery= " > approach less problematic, by ensuring the 1%/10% who were conscientious > can avoid being part of the "my funds were stolen by a quantum attacker" > contingent, eg. >=20 > > > Theorycrafting for a second here. It's reasonable to conjecture fee > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advanta= ge > > > over P2TRv2 will yield significant savings for end-users in absolute > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes bec= omes > > > significant (100 sats per spend or more). >=20 > I don't think that is the right way to look at. 8vb/input is about > an additional 14% today (vs a taproot key-path spend), but with the > post-quantum signatures we have available now that's likely to reduce > to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B, > you're only getting an expected savings in fees / increase in block > capacity on that order of magnitude, ie: 1%-7%. That's nice to have, > for sure, but doesn't compare to introducing a new address type that > puts the PQ sigs in an extension block, or one that uses ZK proofs to > do cross-input or cross-transaction signature aggregation, eg. So a 32B > witness overhead for an unused/unusable key-path post-Q-day doesn't seem > very relevant to me. >=20 > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed > > perfectly. The expectation should be just that it happens before Q-day, > > and when it looks inevitable or the fear about that is large enough. >=20 > FWIW, I would define "timed perfectly" precisely as "EC disabling > fork happens before Q-day". Maybe allowing some additional months of > EC-efficiency would be a win while not taking out too much migration time= , > but for me "perfection" here means "no one who upgraded lost money via > quantum-related vulnerabilities". >=20 > One reason I'm doubtful is that I think for some the "it looks inevitable= " > threshold has already been crossed, eg: >=20 > > > So let me attempt to partially fill the silence, similarly to what > > > Scott Aaronson did in his April 29 post. Given everything I know, > > > including scary non-public information, I now put the odds of qday by > > > 2032 at 50%. 10% by 2030. >=20 > > > IMO a good target date for migration is 2029, roughly 3.5 years > > > out. 2029 happens to be the date selected by Google, Cloudflare, and > > > the Ethereum Foundation. >=20 > https://x.com/drakefjustin/status/2061793725299224676 >=20 > > > So, here it is: if quantum computers start breaking cryptography a > > > few years from now, don=E2=80=99t you dare come to this blog and tell= me that > > > I failed to warn you. This post is your warning. Please start switchi= ng > > > to quantum-resistant encryption, and urge your company or organizatio= n > > > or blockchain or standards body to do the same. >=20 > https://scottaaronson.blog/?p=3D9718 >=20 > Personally, that leaves me at a minimum very skeptical of the utility > of introducing either P2MR or P2TRv2 (etc) approaches that don't also > introduce a quantum-safe spending path on day one. >=20 > > First a meta-point here: the reason I like separating the discussion in= to different dimensions than just "P2TRv2 vs P2MR" is because there are mor= e options than those two, and not every argument applies to the same separa= tion into two classes. Let me list them explicitly here, roughly in decreas= ing order of how strongly I feel about them: > > - We need at least a "Later" option for meaningful migration, i.e. P2TR= v2 or P2MR+ED. > > - Within the "Later" option, P2TRv2 is preferable. > > - A "Later" option benefits from being the only PQC migration strategy,= making it a Schelling point. >=20 > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the > "Later-dominant" scenario, and only to the degree that it's slightly > cheaper prior to Q-day. If it were the only available option, that would > increase the risk of loss involved with both the other approaches. (I > don't think P2TRv2 is meaningfully more private than P2MR in the way > taproot v1 is, as presumably you'd only adopt that address format if > you wanted to have a post-quantum script path) >=20 > > > You'd have to convince everyone to deploy and then adopt P2TRv2 today= under the public knowledge that it is insecure and their coins are more li= kely to be stolen. That's a hard sell. > >=20 > > > How does one pitch P2TRv2 to users? "It will be quantum secure one da= y we promise because everyone is incentivized to fix it later as Bitcoin wi= ll die if we don't." > > >=20 > > > How do you pitch P2MR? "It's quantum secure if you use it correctly." > > > To me, the pitch is "Bitcoin can only remain valuable if we mostly/al= l migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or= any "Never" output type) fundamentally requires many users to change their= workflows entirely. >=20 > Let's call NoEC-day the earlier of activation of a soft-fork disabling > EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably > equal to "the day the bitcoin ecosystem has finally agreed that CRQCs > are inevitable". >=20 > My (cynical?) view is the only people who will adopt either P2TRv2 or > P2MR prior to NoEC-day being schedule will be people who are willign > to use those features in a quantum-safe way -- that is, keeping their > EC pubkeys secret, and only revealing those EC pubkeys to spend them > immediately, prior to NoEC-day. In that view, the EC-spend-paths of such > coins prior to NoEC-day are only an opportunistic "make spends cheaper" > shortcut, they don't allow the funds to be used in lightning channels > or to let your wallet be audited via sharing an xpub or anything similar. >=20 > Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible > that lightning software could get an upgrade to generate post-quantum > signatures for channel commitments or HTLC claims, I just think it's > pretty unlikely that that will happen at a meaningful scale when everyone > has much more immediate and less theoretical things to work on prior to > NoEC-day, especially when the efficiency/performance of such changes is > likely to be very low. >=20 > > This focus on allowing individual users the ability to safeguard their > > coins just feels like a red herring: [...] >=20 > While I appreciate your point, I also feel that "allowing individual > users the ability to safeguard their coins" is pretty close to the entire > point of Bitcoin. :) >=20 > > In either case, I consider anything that requires hardcoding > > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus > > rules (and only allowing those coins to survive) to be squarely in > > disaster-recovery land. It feels like embracing arbitrariness, and > > giving up on the permissionlessness that makes Bitcoin interesting - > > if the community shows it can get consensus on effectively burning > > coins except those that match a whitelist, it feels hard to maintain > > censorship-freeness as a value, even if the whitelist includes most of > > the (active) coins. That is of course not to say such techniques aren't > > interesting to work on, but to me, their place is in disaster recovery > > scenarios to save what's left, after Q-day, if migration attempts were > > unsuccessful. In such a setting, I think we're already in effectively a= n > > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly > > growing) set of ways to recover burned coins can be hardforked in. >=20 > Just for the record, I think the above is an accurate description of the > "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant > of bitcoin would be fairly described as a utxo-bootstrapped altcoin, > would compete in the market with the "quantum-unsafe" bitcoin that > existing nodes would continue to follow, and possibly there would be > many slightly varying such altcoins competing with each other, eg on > exactly what height the utxo snapshot was taken or what coins become > spendable. It would not be a fun time for holders of affected utxos. >=20 > > My impression is that your approach is to have an answer for many > > possible futures, including ones where Q-day arrives within just a few > > years. >=20 > "The key of strategy... is not to choose a path to victory, but to choose > so that all paths lead to a victory." >=20 > -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit >=20 > > But optimizing for disaster-recovery also means reducing the > > chances of preserving Bitcoin as we know it in the scenarios where a > > successful migration is still possible. And if Q-day does arrive that > > soon, I don't see what we can do today that would preserve Bitcoin in > > a form we care about anyway. By accepting that, we can focus on the > > futures where our choices today can still materially improve the outcom= e. >=20 > Preserving bitcoin as a personally-possessible inflation resistant > store of value seems both possible and worth caring about, even if other > constraints means that many people can't afford to personally hold it > (and have to go through ETFs/exchanges/banks) and that it can't be used > for day-to-day transactions. Would be very disappointing if true, and > even given Q-day in a few years I expect we could do better than just > that, but it doesn't feel like a throw-in-the-towel event to me. >=20 > > > Essentially yes though, I expect the majority of holders will probabl= y > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a = fork > > > thereof. Even if we can't come to consensus and deploy a new output t= ype, > > > we'll still be able to rescue most coins. It's just that we'd have no= where > > > to rescue them to, so we ought to make PQ wallets available soon, so = we're > > > not in a rush to build them later when we need them. If a PQ wallet c= an > > > use cheap EC signatures while they're still trustworthy, all the bett= er >=20 > FWIW, that's my guess on how things would play out if the near-term Q-day > timelines I've seen (ie, 2029 to 2035) match reality. I hope that's > pessimistic (either because the Q-day timelines are bad estimates, or > because migration happens in a more orderly fashion), but I guess we'll > see. I don't rate my ability to evaluate Q-day predictions very highly. >=20 > > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say. >=20 > I'm not in a position to judge, but the google paper claims: >=20 > "Indeed, if a leading quantum architecture encounters and overcomes > all its scaling challenges before producing a device able to > solve (for example) 32-bit ECDLP, then there may be little time > between the breaking of 32-bit ECDLP and the breaking of 256-bit > ECDLP. Furthermore, the community should not expect to see published > demonstrations of the most advanced quantum error-correction > architectures and quantum algorithms deployed to cryptanalytic > problems. Thus, a successful public demonstration of Shor=E2=80=99s > algorithm on a 32-bit elliptic curve should not be seen as a wake-up > call to adopt PQC as much as a potential signal that PQC adoption > has already failed." >=20 > and places the required tiffoli gates and logical qubits for a 32-bit > break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100) > for 256-bit. >=20 > > Of course, if you believe it's the only possible future, I understand > > you'd come to a different conclusion. But is it really? Do you think > > this isn't a plausible future: >=20 > > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too)= gets introduced in the next few years, with hash-based PQC opcodes. > > - Over the course of the next decade or so, it gets adopted by practica= lly all active users. >=20 > I think it might be better to look at that scenario in a more fine-graine= d > way? I think your "Late-ish" scenario is: >=20 > 1) P2TRv2 (or whatever) is introduced > 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-path= s > via those outputs > 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TR= v2, > but EC spend paths continue to be what's used in practice. > 4) Some better PQ solutions become available, allowing cheap PQ-safe spen= d-paths > 5) Everyone switches from EC paths to the new PQ paths. > 6) NoEC-day happens, but no one is impacted. >=20 > I think your "Soon-ish" scenario differs as of step (4): >=20 > 4) NoEC-day happens. Massive disruption because the "what's used in pract= ice" > path breaks, but everything is recoverable. > 5) Post-quantum approaches get even higher priority >=20 > I'm skeptical of step 3 here; and would expect to see something more like= : >=20 > 3') Only a small proportion of users (ie, the most conscientious/fearful) > switch to P2TRv2 with most preferring to stick with what works >=20 > That has no real impact on the Late-ish scenario, but changes the Soon-is= h > scenario to either: >=20 > 4'a) NoEC-day happens substantially before Q-day; people hurry to migrate > to P2TRv2, but it mostly works. >=20 > or >=20 > 4'b) NoEC-day happens essentially at the same time as Q-day; coins get > stolen and we hit the disaster-recovery scenario. >=20 > Perhaps the difference between (3') and (3) playing out in reality > is just having nearly everyone agree that the upgrade is essential, > and rather than leaving it to self-interest/market-dynamics, having a > consistent push that every single wallet/service that doesn't deprecate > every current address type is a danger to the entire ecosystem, even > absent widespread agreement on when/if Q-day will happen. Arguably that > would be easier to agree on if the incremental cost of EC spend paths > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to > zero, rather than up to ~14% per input. >=20 > Cheers, > aj >=20 > -- > You received this message because you are subscribed to a topic in the Go= ogle Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/b= itcoindev/p8AVEmAtWdA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/ajN9be00Br-O3-9R%40erisian.com.au. --=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/= xXllZpuSNUfmizNVhO9lt8q7Wi-l5-7RsHBHnO2FmenEj52K8FF2hhoW1fg_UMRMkhYzzrXS9sG= DsKaYfKxviiaQ3mIuesm-bfEII79EI8g%3D%40proton.me. -----------------------811102703eecb224bf020894c167c71d Content-Type: multipart/related;boundary=---------------------a21b1a119dd39c1d89f1fbdb590c92c8 -----------------------a21b1a119dd39c1d89f1fbdb590c92c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Now I have some points I'd like to respond to about rescue protocols. = This is largely tangential to the P2MR/P2TRv2 question.
=

In either case, I cons= ider anything that requires hardcoding specific wallet designs (BIP32 or ot= herwise) into Bitcoin's consensus rules (and only allowing those coins to s= urvive) to be squarely in disaster-recovery land. It feels like embracing a= rbitrariness, and giving up on the permissionlessness that makes Bitcoin in= teresting

It's fair to say such a solution is arbitrary, insofar as the knowledg= e asymmetries like BIP32 CKD are arbitrary. But can you propose any alterna= tives which are not arbitrary?

I would not count = hoping for major= ity migration to be a valid soluti= on. We ought to consider and plan for the contingency that migration to the= PQ output type is underwhelming, even if that is not the best outcome, b= ecause such an outcome is still likely even if the new output type were mag= ically 10x cheaper and more private than P2TR.


My impress= ion is that your approach is to have an answer for many possible futures, i= ncluding ones where Q-day arrives within just a few years. But optimizing f= or disaster-recovery also means reducing the chances of preserving Bitcoin = as we know it in the scenarios where a successful migration is still possib= le. And if Q-day does arrive that soon, I don't see what we can do today th= at would preserve Bitcoin in a form we care about anyway. By accepting that= , we can focus on the futures where our choices today can still materially = improve the outcome.

Mostly yes. I gotta agree with AJ's quote here. In chess= , one wins by forcing the worst possible outcome to be victory. In probabil= istic games, one wins by maximizing the chance of success and minimizing th= e cost of failure. We should be doing the same thing here.

A quantum "disaster recovery" scen= ario, as you put it, is absolutely worth optimizing for IMO, because with o= ur current trajectory it seems very plausible, and yet its severe consequen= ces can be mostly mitigated at little cost. I don't think we should abandon= such survivable scenarios just because they're less palatable than others.=

I dispute that re= scue protocols would discourage PQ migration. Quite the opposite: They force PQ migration even for= inactive users, by turning vulnerable UTXOs into PQ-safe ones retroactivel= y.

Even if rescue = protocols do massively discourage migration to PQ outputs, this would be of= little consequence exactly because rescue protocols would=  exist (which is their beauty). Even in the most extreme case w= here we deploy a PQ output type and exactly nobody migrates to it, we can still = use rescue protocols to achieve the same rate of ownership-preservation as = if all quantum-recoverable coins (BIP32, hashed addr, etc) had migrated to = PQ outputs immediately. It'll be= less efficient and more awkward, but far from hopeless.

Again, the real tar= get demographic that we need to focus on migrating is the quantum unrecoverable subset, i.e. coins w= hich have no quantum-hard knowledge asymmetry, like satoshi's coins, P2PK w= allets, and JBOK wallets with exposed pubkeys. If we expect to have rescue = protocols, then we don't really care what address format these coins move t= o, as long as it's to something&nbs= p;quantum-recoverable. But convincing them to move at all seems hard= , because their owners are probably dead or the keys are lost. How to handl= e such coins after Q-day is an open question, and it seems to boil down to = the good old "freeze-or-steal" debate.


If Q-day comes before migration can reach meaningful levels (what t= hose are is probably a matter of perspective), then I think there isn't muc= h of an interesting future for Bitcoin anyway.
The future is only as i= nteresting as we make it. Even if Q-Day comes before most coins migrate, we= have an opportunity to make that future interesting, using rescue protocol= s. Maybe some folks don't want to work on them or would rather sell their c= oins first, and that's totally valid, but I implore you to at least keep yo= ur mind open to the possible futures that rescue protocols open up, because= it is unclear exactly which future we are bound for and I'd rather that ne= utral internet money still exists in each of them.

<= p style=3D"scrollbar-width: thin; scrollbar-color: rgba(0, 0, 0, 0.35) rgba= (0, 0, 0, 0); background-color: rgb(255, 255, 255);">We have to play the ca= rds we are dealt, and right now we've been dealt a very fortunate hand because of BIP32 (thanks to yo= u sipa!): Most users have at least s= ome secret knowledge that a CRQC cannot forge, and that's a pretty= awesome privilege, one which even extends to other blockchains whose walle= ts use BIP32, or its derivatives. You should be very proud of that IMO = ;=F0=9F=99=82


Disaster-recovery: n= either the "predictable/planned consensus change" of Later nor = the "everyone takes responsiblity for their own funds" works, and the only = way to avoid a large percentage of bitcoin becoming a reward for quantum re= search is to replace EC spend paths with a ZK proof of knowledge of a BIP32= seed or similar, requiring a hard fork.

@AJ rescue protocols can be depl= oyed via soft fork, because we'd be constricting rules and not relaxing the= m. We'd require any EC spends to also satisfy the rescue protoc= ol in addition to the existing consensus rules (signatures etc). Of co= urse, there might be external reasons to deploy it as a hard fork, e.g. to = roll back mass theft if we don't time things right, or to disentangl= e from quantum-theft advocates, but I think we should aim for s= oft fork compatibility if possible.


the "quantum-safe= " hard-fork variant of bitcoin would be fairly described as a u= txo-bootstrapped altcoin, would compete in the market with the "quantum-uns= afe" bitcoin thatexisting nodes would continue to follow, and possibly ther= e would be many slightly varying such altcoins competing with each oth= er, eg on exactly what height the utxo snapshot was taken or what coins bec= ome spendable. It would not be a fun time for holders of affected utxos.
I = really hope we do not end up in a situation with competing rescue protocol = deployments. I don't think snapshots are necessary so that's not really a f= actor.
As for= the exact conditions which permit rescue... that could indeed get dicey if= we need to collate a bunch of different rescue protocols into one Frankens= teinian mess. The most popular proposal will probably be one which covers a= ll the most common hard-relations, but this still needs more research.
If we think of re= scue protocols more abstractly, the spender just needs to prove their scrip= t pubkey commited to a quantum-hard relation, and that the spender knows th= e witness to that relation. It doesn't actually matter which exact relation= - BIP32, hashed address, musig, whatever - just that it's quantum-hard. Ma= ybe there is a way to formulate a two-step proof system general enough to r= escue UTXOs with any such relation, by first proving the relation is quantu= m-hard, then proving you know the witness to the relation. That would be aw= esome but still an open problem.

regards,
conduition



On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns aj@erisian.com.au wrote:

On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:

I want to first correct a potential misunderstanding here, because
I realize the terms "Later" and "Never" aren't very descriptive. They
are specifically about an expected and relied-upon expectation that an
EC-disabling fork will happen that at least applies to the output type
itself, in time. "Later" is the expectation that such a disabling will
happen after the output type is introduced, but still in time (so, before Q-day). Outputs without a strong expectation that their EC paths/opcodes will be disabled, or not in time, I classify under "Never".

I believe here you're instead arguing for P2MR ("Merkle-Never")
over all "Later" options. That was my previous point: I think (solely)
having "Never" output types like P2MR is just utterly insufficient for
any worthwhile migration. It's so incompatible with today's workflows
that it either won't be adopted, or (possibly inadvertently) adopted
in an insecure fashion. Yes, it gives people the option to safeguard
their own coins, but to me that's disaster recovery territory - I think
we ought to prioritize maximizing the chances for saving the currency
as a whole in case Q-day comes, not a small subset of individual users'
coins. P2MR (alone) doesn't really achieve much in that regard in my view,<= br> thus we at least need something of the "Later" class in addition.

I'm not sure I follow/agree with the logic here. I think the general ide= a
is:

1) we create some new address types that allow post-quantum spending, bu= t
also allow efficient quantum-vulnerable spending that can be used prior
to Q-day

2) many people migrate to these new address types

3) Q-day arrives

4) all spending goes via the post-quantum paths, and everyone's funds ar= e
safe

There are three main variations to this, I think:

Later-dominant: towards the end of (2) but prior to (3), the
quantum-vulnerable spend paths are disabled in a predictable, planned
manner, preventing coin theft, but not disrupting active usage
significantly (or not disrupting it any more than the proximity of
Q-day already is).

Self-reliance: Q-day goes from maybe to definitely faster than consensus=
changes can be coordinated, and the only reason people's funds remain
safe is that they can (and do) keep the quantum-vulnerable spend
paths secret.

Disaster-recovery: neither the "predictable/planned consensus change" of=
Later nor the "everyone takes responsiblity for their own funds"
works, and the only way to avoid a large percentage of bitcoin
becoming a reward for quantum research is to replace EC spend paths
with a ZK proof of knowledge of a BIP32 seed or similar, requiring
a hard fork. Such a hard fork would be certain to be controversial
("why at this height: I received a payment five blocks after //
my funds were stolen by a quantum attacker five blocks earlier //
why are only BIP32 funds recoverable not scheme X"), but if no other
approach works, might still be the ultimately outcome.

So the point here was just: if you already accept the need for a "Later"=
output type (=3D one with builtin-in EC disabling expected from the start),=
P2TRv2 is preferable over P2MR+ED, because:

As far as I can see, only having P2TRv2 addresses would rule out the
"self-reliance" path here.

Picking when Q-day will occur, either individually for determining
your own security posture, or collectively for organising a consensus
change seems very difficulty: it involves evaluating both complex state
of the art physics research, but also estimating the covert abilities
of national governments and the incentives to attack bitcoin prior to
revealing their capabilities. To me, that doesn't bode well for a smooth and fast deployment of a consensus change in advance of problems occuring.<= /p>

It's possible that general carelessness on behalf of users would also rule out the effectiveness of a self-reliance approach: if only the most conscientious 1% of users make use of P2MR securely, that might secure 10%<= br> of funds, but having 90% of the bitcoin supply crash probably wouldn't be very valuable either. But even then, that may make the "disaster-recovery"<= br> approach less problematic, by ensuring the 1%/10% who were conscientious can avoid being part of the "my funds were stolen by a quantum attacker" contingent, eg.

Theorycrafting for a second here. It's reasonable to conjecture fee
rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
over P2TRv2 will yield significant savings for end-users in absolute
terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes significant (100 sats per spend or more).

I don't think that is the right way to look at. 8vb/input is about
an additional 14% today (vs a taproot key-path spend), but with the
post-quantum signatures we have available now that's likely to reduce
to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
you're only getting an expected savings in fees / increase in block
capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
for sure, but doesn't compare to introducing a new address type that
puts the PQ sigs in an extension block, or one that uses ZK proofs to
do cross-input or cross-transaction signature aggregation, eg. So a 32B
witness overhead for an unused/unusable key-path post-Q-day doesn't seem very relevant to me.

FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
perfectly. The expectation should be just that it happens before Q-day,
and when it looks inevitable or the fear about that is large enough.

FWIW, I would define "timed perfectly" precisely as "EC disabling
fork happens before Q-day". Maybe allowing some additional months of
EC-efficiency would be a win while not taking out too much migration time,<= br> but for me "perfection" here means "no one who upgraded lost money via
quantum-related vulnerabilities".

One reason I'm doubtful is that I think for some the "it looks inevitabl= e"
threshold has already been crossed, eg:

So let me attempt to partially fill the silence, similarly to what
Scott Aaronson did in his April 29 post. Given everything I know,
including scary non-public information, I now put the odds of qday by
2032 at 50%. 10% by 2030.

IMO a good target date for migration is 2029, roughly 3.5 years
out. 2029 happens to be the date selected by Google, Cloudflare, and
the Ethereum Foundation.

https:= //x.com/drakefjustin/status/2061793725299224676

So, here it is: if quantum computers start breaking cryptography a
few years from now, don=E2=80=99t you dare come to this blog and tell me th= at
I failed to warn you. This post is your warning. Please start switching
to quantum-resistant encryption, and urge your company or organization
or blockchain or standards body to do the same.

https://scottaaronson.b= log/?p=3D9718

Personally, that leaves me at a minimum very skeptical of the utility of introducing either P2MR or P2TRv2 (etc) approaches that don't also
introduce a quantum-safe spending path on day one.

First a meta-point here: the reason I like separating the discussion int= o different dimensions than just "P2TRv2 vs P2MR" is because there are more= options than those two, and not every argument applies to the same separat= ion into two classes. Let me list them explicitly here, roughly in decreasi= ng order of how strongly I feel about them:
- We need at least a "Later" option for meaningful migration, i.e. P2TRv2 o= r P2MR+ED.
- Within the "Later" option, P2TRv2 is preferable.
- A "Later" option benefits from being the only PQC migration strategy, mak= ing it a Schelling point.

Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the=
"Later-dominant" scenario, and only to the degree that it's slightly
cheaper prior to Q-day. If it were the only available option, that would increase the risk of loss involved with both the other approaches. (I
don't think P2TRv2 is meaningfully more private than P2MR in the way
taproot v1 is, as presumably you'd only adopt that address format if
you wanted to have a post-quantum script path)

You'd have to convince everyone to deploy and then adopt P2TRv2 today un= der the public knowledge that it is insecure and their coins are more likel= y to be stolen. That's a hard sell.

How does one pitch P2TRv2 to users? "It will be quantum secure one day w= e promise because everyone is incentivized to fix it later as Bitcoin will = die if we don't."

How do you pitch P2MR? "It's quantum secure if you use it correctly." To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migr= ate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "= Never" output type) fundamentally requires many users to change their workf= lows entirely.

Let's call NoEC-day the earlier of activation of a soft-fork disabling EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
are inevitable".

My (cynical?) view is the only people who will adopt either P2TRv2 or P2MR prior to NoEC-day being schedule will be people who are willign
to use those features in a quantum-safe way -- that is, keeping their
EC pubkeys secret, and only revealing those EC pubkeys to spend them
immediately, prior to NoEC-day. In that view, the EC-spend-paths of such coins prior to NoEC-day are only an opportunistic "make spends cheaper"
shortcut, they don't allow the funds to be used in lightning channels
or to let your wallet be audited via sharing an xpub or anything similar.

Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible<= br> that lightning software could get an upgrade to generate post-quantum
signatures for channel commitments or HTLC claims, I just think it's
pretty unlikely that that will happen at a meaningful scale when everyone has much more immediate and less theoretical things to work on prior to
NoEC-day, especially when the efficiency/performance of such changes is
likely to be very low.

This focus on allowing individual users the ability to safeguard their coins just feels like a red herring: [...]

While I appreciate your point, I also feel that "allowing individual
users the ability to safeguard their coins" is pretty close to the entire point of Bitcoin. :)

In either case, I consider anything that requires hardcoding
specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
rules (and only allowing those coins to survive) to be squarely in
disaster-recovery land. It feels like embracing arbitrariness, and
giving up on the permissionlessness that makes Bitcoin interesting -
if the community shows it can get consensus on effectively burning
coins except those that match a whitelist, it feels hard to maintain
censorship-freeness as a value, even if the whitelist includes most of
the (active) coins. That is of course not to say such techniques aren't
interesting to work on, but to me, their place is in disaster recovery
scenarios to save what's left, after Q-day, if migration attempts were
unsuccessful. In such a setting, I think we're already in effectively an altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
growing) set of ways to recover burned coins can be hardforked in.

Just for the record, I think the above is an accurate description of the=
"disaster-recovery" scenario above: the "quantum-safe" hard-fork variant of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
would compete in the market with the "quantum-unsafe" bitcoin that
existing nodes would continue to follow, and possibly there would be
many slightly varying such altcoins competing with each other, eg on
exactly what height the utxo snapshot was taken or what coins become
spendable. It would not be a fun time for holders of affected utxos.

My impression is that your approach is to have an answer for many
possible futures, including ones where Q-day arrives within just a few
years.

"The key of strategy... is not to choose a path to victory, but to choos= e
so that all paths lead to a victory."

-- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit

But optimizing for disaster-recovery also means reducing the
chances of preserving Bitcoin as we know it in the scenarios where a
successful migration is still possible. And if Q-day does arrive that
soon, I don't see what we can do today that would preserve Bitcoin in
a form we care about anyway. By accepting that, we can focus on the
futures where our choices today can still materially improve the outcome.

Preserving bitcoin as a personally-possessible inflation resistant
store of value seems both possible and worth caring about, even if other constraints means that many people can't afford to personally hold it
(and have to go through ETFs/exchanges/banks) and that it can't be used
for day-to-day transactions. Would be very disappointing if true, and
even given Q-day in a few years I expect we could do better than just
that, but it doesn't feel like a throw-in-the-towel event to me.

Essentially yes though, I expect the majority of holders will probably migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork thereof. Even if we can't come to consensus and deploy a new output type, we'll still be able to rescue most coins. It's just that we'd have nowhere<= br> to rescue them to, so we ought to make PQ wallets available soon, so we're<= br> not in a rush to build them later when we need them. If a PQ wallet can
use cheap EC signatures while they're still trustworthy, all the better

FWIW, that's my guess on how things would play out if the near-term Q-da= y
timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
pessimistic (either because the Q-day timelines are bad estimates, or
because migration happens in a more orderly fashion), but I guess we'll
see. I don't rate my ability to evaluate Q-day predictions very highly.

- A (not-quite-CR)-QC breaks 128-bit ECDLP, say.

I'm not in a position to judge, but the google paper claims:

"Indeed, if a leading quantum architecture encounters and overcomes
all its scaling challenges before producing a device able to
solve (for example) 32-bit ECDLP, then there may be little time
between the breaking of 32-bit ECDLP and the breaking of 256-bit
ECDLP. Furthermore, the community should not expect to see published
demonstrations of the most advanced quantum error-correction
architectures and quantum algorithms deployed to cryptanalytic
problems. Thus, a successful public demonstration of Shor=E2=80=99s
algorithm on a 32-bit elliptic curve should not be seen as a wake-up
call to adopt PQC as much as a potential signal that PQC adoption
has already failed."

and places the required tiffoli gates and logical qubits for a 32-bit break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
for 256-bit.

Of course, if you believe it's the only possible future, I understand you'd come to a different conclusion. But is it really? Do you think
this isn't a plausible future:

- A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) = gets introduced in the next few years, with hash-based PQC opcodes.
- Over the course of the next decade or so, it gets adopted by practically = all active users.

I think it might be better to look at that scenario in a more fine-grain= ed
way? I think your "Late-ish" scenario is:

1) P2TRv2 (or whatever) is introduced
2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths<= br> via those outputs
3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TRv2= ,
but EC spend paths continue to be what's used in practice.
4) Some better PQ solutions become available, allowing cheap PQ-safe spend-= paths
5) Everyone switches from EC paths to the new PQ paths.
6) NoEC-day happens, but no one is impacted.

I think your "Soon-ish" scenario differs as of step (4):

4) NoEC-day happens. Massive disruption because the "what's used in prac= tice"
path breaks, but everything is recoverable.
5) Post-quantum approaches get even higher priority

I'm skeptical of step 3 here; and would expect to see something more lik= e:

3') Only a small proportion of users (ie, the most conscientious/fearful= )
switch to P2TRv2 with most preferring to stick with what works

That has no real impact on the Late-ish scenario, but changes the Soon-i= sh
scenario to either:

4'a) NoEC-day happens substantially before Q-day; people hurry to migrat= e
to P2TRv2, but it mostly works.

or

4'b) NoEC-day happens essentially at the same time as Q-day; coins get stolen and we hit the disaster-recovery scenario.

Perhaps the difference between (3') and (3) playing out in reality
is just having nearly everyone agree that the upgrade is essential,
and rather than leaving it to self-interest/market-dynamics, having a
consistent push that every single wallet/service that doesn't deprecate
every current address type is a danger to the entire ecosystem, even
absent widespread agreement on when/if Q-day will happen. Arguably that
would be easier to agree on if the incremental cost of EC spend paths
in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
zero, rather than up to ~14% per input.

Cheers,
aj

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/top= ic/bitcoindev/p8AVEmAtWdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@= googlegroups.com.
To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/ajN9be00Br-O3-9R%40erisian.com.au.

--
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/xXllZp= uSNUfmizNVhO9lt8q7Wi-l5-7RsHBHnO2FmenEj52K8FF2hhoW1fg_UMRMkhYzzrXS9sGDsKaYf= KxviiaQ3mIuesm-bfEII79EI8g%3D%40proton.me.
-----------------------a21b1a119dd39c1d89f1fbdb590c92c8-- -----------------------811102703eecb224bf020894c167c71d-- -----------------------d35c7cfa3fcfe2844cce13b70b038c0e 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== -----------------------d35c7cfa3fcfe2844cce13b70b038c0e-- --------5d3a6e60565ce036229a51209e114575cf5cf627d0008839270e08236506812d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmo0j3QJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfBHk63V/SPX0OWXN5wkByOudHdz7tw9u81VCtp hbBlDBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAB5nwEAwZgd8e6gLrqresOV wsoliRW2qLjG2eCEL6LlVlc6/loBAMS2ZDAQKE/ney7l8Yk7zP4AB9OqzxVb 7DlFmGEJR1UN =rmpb -----END PGP SIGNATURE----- --------5d3a6e60565ce036229a51209e114575cf5cf627d0008839270e08236506812d--