From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 25 Jun 2026 08:34:06 -0700 Received: from mail-ot1-f62.google.com ([209.85.210.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wcm5a-00054q-LK for bitcoindev@gnusha.org; Thu, 25 Jun 2026 08:34:06 -0700 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7e93b1b8b52sf2958091a34.2 for ; Thu, 25 Jun 2026 08:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782401636; x=1783006436; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=WGlD+ntIIIL7VFCn2EBDSquHugCh8kd/YSa+Mnooc20=; b=xaLKXTJ1mkfQpZG026IYBOH1v9Sn8kyZRceqpZYKAtz8L/XpFZPQUevh5uBMAbwzfN Xfi5+tlxx2bAiAg2RcPrA7GL4hzOMZM36f3MMhndZ1eSKk0dfshThsgLZVU7hV0MUssB Y3ntiGBMN1nJi7EY2AAAdWTMK83a3qd/m3LCst5MfyMzbiD6H87SYUhuKGw51l9P9jlG I8yBvzeH4i/niVm4EHDLWWhlGEwiDnUMgV9hHYBLzdxJ0b1VpMPAOI2cSYFD0t4mcpi2 aTq16pmSC1KaadqW6b3+t5Bha+AL4SvicEA/PPV1Oq+R0vv0vQzP/g1dTKWd6p9nGREa jKWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782401636; x=1783006436; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=WGlD+ntIIIL7VFCn2EBDSquHugCh8kd/YSa+Mnooc20=; b=KIR5mwyDfgrtXBvjuwcrVt6R7iMbqFyOVZxYL0tLO7rr7vPg5Mvxl9uG2DVf3H+GUd bKD5YFL/ryS3iCmVAmr2204bf4A9NxIpDD8E+ZFZfMD1O4xu0Uz5sCvaUDPMkJGTy2XA 8/OpWX3KGvRciK7E3F48sGHCBYqz50olSKkOkxs34W5wK6FIDAqnD2qKaSMXc6vcUMa0 tpCnsWZjb5lX8j8QCIjLaplGg84U7SJIFCLI15EkCX77ObtP6tRtFu7b42xmVxeam+nf Z1FGkw3UF2FUPEeb7um/ht6jpayg340wVBJiDVwca1yO8xDjT6r8mIf3SHiHfyKxu6Sk Yqzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782401636; x=1783006436; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=WGlD+ntIIIL7VFCn2EBDSquHugCh8kd/YSa+Mnooc20=; b=n6DNhUvwK6iMOLWxSfCyOvYrDisdhajl2t2COHQYC809uuDSr1uFVgNoLF00rQ2Rih arNjZsPx1vfyQKWzWhfneTk02XEmsqaswqsExiW9kG9sCCv9tzshkico4R5geFta0PNw S1Nwc5DBgFKRR1eQzN6cdAFXdzsruK0Np4kKZvK0KgtuESU3CNuedGeyyxY++7ete/Vi eRJn9WF8uMxlzjKq3axdvqwzWd8+UHkHsCjtCS0fATtqR/6jybDdrWyrQ7i/JcdlgBbH tW+/6ciLMVpxbmzD68loP/8HTIg/TMidWUDydSrDUvyC+WDAfULddQtm6BrKtYlkJLO0 SGvQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ99K0zazThNLMpvEmU7eI8JvXJ1RbV6ofFMGN5p5RqUq14S/iorHZzOn5eNpu3sJAJNinK9giTiKp4f@gnusha.org X-Gm-Message-State: AOJu0YzqwbZoD11QX1ojSbrA004sUlvnDRUify38u1yHaT938NTSR3UB OAHx4PftVYgroiqOK4WabOOZylxrZoha3Ag5AjjrYeTxiAis//Gb21Sl X-Received: by 2002:a05:6820:16a3:b0:69e:b7f4:2a14 with SMTP id 006d021491bc7-6a13520e850mr2501416eaf.26.1782401636036; Thu, 25 Jun 2026 08:33:56 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUcX6EH6gKhrrkqVWChj350xfNZdpWhJHf8+1AJ8Xi3XgQ==" Received: by 2002:a05:6871:3212:b0:447:408b:42a7 with SMTP id 586e51a60fabf-447408b4f05ls2795588fac.1.-pod-prod-05-us; Thu, 25 Jun 2026 08:33:50 -0700 (PDT) X-Received: by 2002:a05:6808:16a6:b0:48a:b49e:2317 with SMTP id 5614622812f47-4921900550emr2485349b6e.12.1782401630072; Thu, 25 Jun 2026 08:33:50 -0700 (PDT) Received: by 2002:a05:690c:3105:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-80abe426ce5ms7b3; Thu, 25 Jun 2026 08:24:58 -0700 (PDT) X-Received: by 2002:a05:690c:3503:b0:7fd:cf65:16c2 with SMTP id 00721157ae682-80a6a4a0f9fmr28119977b3.46.1782401097937; Thu, 25 Jun 2026 08:24:57 -0700 (PDT) Date: Thu, 25 Jun 2026 08:24:57 -0700 (PDT) From: Alex To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> <81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg=@wuille.net> Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_50438_604337863.1782401097414" X-Original-Sender: alexhultman@gmail.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.5 (/) ------=_Part_50438_604337863.1782401097414 Content-Type: multipart/alternative; boundary="----=_Part_50439_1603164098.1782401097414" ------=_Part_50439_1603164098.1782401097414 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Systems such as Lightning and ProofnetBTC Plugging your own L2 is not going to change the fact Bitcoin will need PQC= =20 to even allow those L2s to settle securely. Everything else is make belief. > allowing innovation without requiring the Bitcoin mainnet itself to=20 absorb that additional complexity You're essentially sweeping the problem under the rug without actually=20 solving it, it's just a word salad that doesn't add up logically. Bitcoin= =20 (the L1) will absolutely need PQC otherwise whatever you build on top has= =20 no better security than what we began with, even if those L2s have , if they settle in Bitcoin they are no more secure than Bitcoin= =20 itself. The complexity introduced into Bitcoin will grow as we drag our feet: 1. If Bitcoin gets hash based PQC before Q-day, very little complexity and= =20 security assumptions are added. These are 1970s kind of algos that build on= =20 existing hashes in Bitcoin. 2. If Bitcoin does not get any PQC before Q-day, then we need to introduce= =20 severely more complex and prone to bugs (see Zcash recent break) ZK-STARK= =20 Circuits which are orders of magnitude more complex than a simple hash=20 based signature algo. The more we reject the QC problem, the bigger in complexity the solutions= =20 will have to be. torsdag 25 juni 2026 kl. 00:35:38 UTC+2 skrev Anthony Derbidge: > I agree with the core point that Bitcoin=E2=80=99s post-quantum transitio= n cannot=20 > rely primarily on self-reliance. If the migration requires most users to= =20 > understand Q-Day timing, keep EC spend paths secret, or react quickly und= er=20 > pressure, then it is unlikely to protect Bitcoin as a system. The safer= =20 > path needs to be low-friction and close to the default experience long=20 > before the threat becomes urgent. > > That is why a "Later" style strategy seems compelling: ordinary users can= =20 > opt into a future migration path without immediately adopting restrictive= =20 > post-quantum workflows, while consensus can still act when the risk becom= es=20 > concrete. Bitcoin mainnet should remain simple and conservative, while mo= re=20 > complex identity, recovery, coordination, and enhanced post-quantum=20 > workflows can exist in optional Bitcoin-aligned layers rather than the ba= se=20 > layer. > > Systems such as Lightning and ProofnetBTC can experiment with those=20 > optional workflows and recovery models while continuing to settle to=20 > Bitcoin, allowing innovation without requiring the Bitcoin mainnet itself= =20 > to absorb that additional complexity. > > Best, > Anthony D. > > On Wed, Jun 24, 2026 at 3:50=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Dev= elopment=20 > Mailing List wrote: > >> Hi AJ, >> >> > There are three main variations to this, I think: >> > >> > [...] >> > >> > Self-reliance: Q-day goes from maybe to definitely faster than consens= us >> > 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. >> >> I think that scenario may only result in a successful migration if the= =20 >> vast >> majority of users have updated their workflows to keep said quantum=20 >> vulnerable >> paths secret. >> >> This may only happen if the vast majority of users either: >> 1. have preemptively updated their workflows during the "maybe" period; >> 2. react promptly enough (within weeks? a couple months?) to migrate all= =20 >> their wealth. >> >> Option (1) is utterly implausible. As Pieter explained in his email, we= =20 >> can't >> expect users to adopt workflows radically at odds with how they use=20 >> Bitcoin >> today in response to a (still --at the time they need to migrate)=20 >> speculative >> threat. >> >> I believe Bitcoin is successful precisely because users are not required= =20 >> to be >> active bitcoiners and pay close attention to avoid losing their funds. A >> substantial share of users value and rely on this property, and therefor= e=20 >> Option >> (2) is likewise implausible. >> >> Therefore i don't think the "Self-reliance" variation can result in a=20 >> successful >> migration. >> >> > As far as I can see, only having P2TRv2 addresses would rule out the= =20 >> "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 stat= e >> > 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 smoo= th >> > and fast deployment of a consensus change in advance of problems=20 >> occuring. >> >> Yes. P2TRv2 optimizes for the "Later dominant" path at the expense of th= e >> "self-reliance" path. I think this is good, because our best (only?) sho= t=20 >> at >> fully migrating large amounts of users is to provide them with a=20 >> virtually free >> way to opt into a future consensus-triggered migration. >> >> The follow-up step does not require predicting with precision the day on= =20 >> which >> an attack would be set up, but to be done before a CRQC could=20 >> realistically >> threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In= =20 >> fact if >> P2TRv2 does become the Schelling point for PQ migration, i would be more >> concerned about the follow-up step happening too soon rather than too=20 >> late. >> >> Of course, if a full CRQC is built in secret, with no reliable=20 >> information about >> the progress getting out whatsoever, and subsequently starts attacking= =20 >> Bitcoin >> overnight, then this migration strategy would fail. But so would any oth= er >> migration strategy! >> >> > It's possible that general carelessness on behalf of users would also >> > rule out the effectiveness of a self-reliance approach: if only the mo= st >> > conscientious 1% of users make use of P2MR securely, that might secure= =20 >> 10% >> > of funds, but having 90% of the bitcoin supply crash probably wouldn't= =20 >> be >> > very valuable either. >> >> For what it=E2=80=99s worth, while the supply at risk matters, i think t= he primary >> metric we should optimize for is the share of users at risk. Widespread, >> indiscriminate theft would fatally undermine trust in Bitcoin, whereas= =20 >> more >> concentrated sweeps (such as that of early, presumed-lost coins) *could*= =20 >> cause >> severe price shocks without necessarily destroying confidence in the=20 >> system >> itself. >> >> > > > Theorycrafting for a second here. It's reasonable to conjecture fe= e >> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte=20 >> advantage >> > > > over P2TRv2 will yield significant savings for end-users in absolu= te >> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes= =20 >> 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). >> >> Yes. Also, our goal here is to mitigate the risk that a CRQC materialize= s=20 >> by >> providing a path for Bitcoin to survive it. We shouldn't take the risk= =20 >> for a >> certainty and shift the goal to designing the best possible PQ-Bitcoin.= =20 >> This can >> be done if/when it becomes clearer that CRQCs will become a reality. >> >> > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed >> > > perfectly. The expectation should be just that it happens before=20 >> 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= =20 >> time, >> > but for me "perfection" here means "no one who upgraded lost money via >> > quantum-related vulnerabilities". >> >> I don't think that's a good definition of "timed perfectly". By your=20 >> definition, >> EC could be disabled from the get-go, Bitcoin's migration would=20 >> spectacularly >> fail because very few users switched to the new output type, and it woul= d=20 >> still >> be "timed perfectly". :) >> >> I would define "timed perfectly" as maximizing the number of migrated=20 >> users >> without any of them losing money to a CRQC. But it's not quite the right >> definition, because there is also probably an aspect of not doing it >> prematurely, i.e. in the scenario where the CRQC threat never=20 >> materializes, no >> P2TRv2 user is forced to use heavily restrictive PQ worklows. >> >> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in t= he >> > "Later-dominant" scenario, and only to the degree that it's slightly >> > cheaper prior to Q-day. >> >> From the perspective that a successful migration hinges on virtually all= =20 >> users >> opting into a (full) migration to CRQC-safe workflows, this difference i= n=20 >> costs >> is material. Especially since users would presumably need to opt in long= =20 >> before >> we know whether CRQCs will become a reality anytime soon. >> >> > 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. >> >> How can this apply to P2TRv2, where EC pubkeys are always public? >> >> I think i disagree that most users of P2MR, were it made available, woul= d=20 >> treat >> their EC public keys as secrets. But more importantly, the whole point o= f >> P2TRv2, or more generally of what Pieter labels "Later" type strategies,= =20 >> is >> precisely to avoid imposing on individual users the costs of treating=20 >> their >> public keys as secrets. P2TRv2 (compared to other "Later" options) also= =20 >> ensures >> that using it is no more costly than using any other available output=20 >> type. >> Together, these properties may make users who are not yet particularly >> concerned, or are simply unaware, indifferent to opting in: they bear th= e >> additional costs only if the CRQC threat materializes and are no worse= =20 >> off if it >> does not. >> >> > > This focus on allowing individual users the ability to safeguard the= ir >> > > 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=20 >> entire >> > point of Bitcoin. :) >> >> Cherry-picking this part of Pieter's sentence does not do it justice. Of= =20 >> course >> we all agree about this. But as he says in the part you left out, not=20 >> addressing >> this issue as a systemic one is exactly how we lose that property: "I'm= =20 >> not >> worried about my own coins being stolen. I'm worried about (fear of) a= =20 >> CRQC >> undermining trust in the currency as a whole, or through a fear-driven= =20 >> consensus >> change the ecosystem destroying its own values beforehand." >> >> > having a consistent push that every single wallet/service that doesn't= =20 >> deprecate every current >> > address type is a danger to the entire ecosystem, even absent=20 >> widespread agreement on when/if >> > Q-day will happen. Arguably that would be easier to agree on if the= =20 >> incremental cost of EC spend >> > paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is= =20 >> near to zero, rather than up >> > to ~14% per input. >> >> Yes, that's essentially the case for P2TRv2. >> >> Best, >> Antoine >> >> >> >> On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns < >> a...@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. The= y >> > > are specifically about an expected and relied-upon expectation that = an >> > > EC-disabling fork will happen that at least applies to the output ty= pe >> > > itself, in time. "Later" is the expectation that such a disabling wi= ll >> > > happen after the output type is introduced, but still in time (so,= =20 >> before >> > > Q-day). Outputs without a strong expectation that their EC=20 >> paths/opcodes >> > > 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 (solel= y) >> > > having "Never" output types like P2MR is just utterly insufficient f= or >> > > any worthwhile migration. It's so incompatible with today's workflow= s >> > > 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=20 >> think >> > > we ought to prioritize maximizing the chances for saving the currenc= y >> > > as a whole in case Q-day comes, not a small subset of individual=20 >> users' >> > > coins. P2MR (alone) doesn't really achieve much in that regard in my= =20 >> view, >> > > 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= =20 >> idea >> > is: >> >=20 >> > 1) we create some new address types that allow post-quantum spending,= =20 >> but >> > also allow efficient quantum-vulnerable spending that can be used= =20 >> 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= =20 >> 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,=20 >> 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=20 >> consensus >> > changes can be coordinated, and the only reason people's funds rema= in >> > safe is that they can (and do) keep the quantum-vulnerable spend >> > paths secret. >> >=20 >> > Disaster-recovery: neither the "predictable/planned consensus change"= =20 >> 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 othe= r >> > approach works, might still be the ultimately outcome. >> >=20 >> > > So the point here was just: if you already accept the need for a=20 >> "Later" >> > > output type (=3D one with builtin-in EC disabling expected from the= =20 >> start), >> > > 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 stat= e >> > 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 smoo= th >> > and fast deployment of a consensus change in advance of problems=20 >> 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 mo= st >> > conscientious 1% of users make use of P2MR securely, that might secure= =20 >> 10% >> > of funds, but having 90% of the bitcoin supply crash probably wouldn't= =20 >> be >> > very valuable either. But even then, that may make the=20 >> "disaster-recovery" >> > approach less problematic, by ensuring the 1%/10% who were conscientio= us >> > can avoid being part of the "my funds were stolen by a quantum attacke= r" >> > contingent, eg. >> >=20 >> > > > Theorycrafting for a second here. It's reasonable to conjecture fe= e >> > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte=20 >> advantage >> > > > over P2TRv2 will yield significant savings for end-users in absolu= te >> > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes= =20 >> becomes >> > > > 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 32= B >> > witness overhead for an unused/unusable key-path post-Q-day doesn't se= em >> > 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=20 >> 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= =20 >> 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=20 >> 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, an= d >> > >> 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 te= ll me that >> > >> I failed to warn you. This post is your warning. Please start=20 >> switching >> > >> to quantum-resistant encryption, and urge your company or=20 >> organization >> > >> 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= =20 >> into different dimensions than just "P2TRv2 vs P2MR" is because there ar= e=20 >> more options than those two, and not every argument applies to the same= =20 >> separation into two classes. Let me list them explicitly here, roughly i= n=20 >> decreasing order of how strongly I feel about them: >> > > - We need at least a "Later" option for meaningful migration, i.e.= =20 >> P2TRv2 or P2MR+ED. >> > > - Within the "Later" option, P2TRv2 is preferable. >> > > - A "Later" option benefits from being the only PQC migration=20 >> strategy, making it a Schelling point. >> >=20 >> > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in t= he >> > "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 wou= ld >> > 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=20 >> today under the public knowledge that it is insecure and their coins are= =20 >> more likely to be stolen. That's a hard sell. >> > > >> > > > How does one pitch P2TRv2 to users? "It will be quantum secure one= =20 >> day we promise because everyone is incentivized to fix it later as Bitco= in=20 >> will die if we don't." >> > > > >> > > > How do you pitch P2MR? "It's quantum secure if you use it=20 >> correctly." >> > > To me, the pitch is "Bitcoin can only remain valuable if we=20 >> mostly/all migrate." for both. P2TRv2 is just much easier to adopt, beca= use=20 >> P2MR (or any "Never" output type) fundamentally requires many users to= =20 >> 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 presumab= ly >> > 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 su= ch >> > 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=20 >> similar. >> >=20 >> > Perhaps I'm wrong: it's my opinion, not a technical fact; it's possibl= e >> > 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=20 >> everyone >> > has much more immediate and less theoretical things to work on prior t= o >> > NoEC-day, especially when the efficiency/performance of such changes i= s >> > likely to be very low. >> >=20 >> > > This focus on allowing individual users the ability to safeguard the= ir >> > > 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=20 >> entire >> > point of Bitcoin. :) >> >=20 >> > > In either case, I consider anything that requires hardcoding >> > > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensu= s >> > > 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=20 >> aren't >> > > interesting to work on, but to me, their place is in disaster recove= ry >> > > scenarios to save what's left, after Q-day, if migration attempts we= re >> > > unsuccessful. In such a setting, I think we're already in effectivel= y=20 >> an >> > > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possib= ly >> > > 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 t= he >> > "disaster-recovery" scenario above: the "quantum-safe" hard-fork varia= nt >> > 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 f= ew >> > > years. >> >=20 >> > "The key of strategy... is not to choose a path to victory, but to=20 >> 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 tha= t >> > > soon, I don't see what we can do today that would preserve Bitcoin i= n >> > > a form we care about anyway. By accepting that, we can focus on the >> > > futures where our choices today can still materially improve the=20 >> outcome. >> >=20 >> > Preserving bitcoin as a personally-possessible inflation resistant >> > store of value seems both possible and worth caring about, even if oth= er >> > 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 use= d >> > 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=20 >> probably >> > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or= =20 >> a fork >> > > > thereof. Even if we can't come to consensus and deploy a new outpu= t=20 >> type, >> > > > we'll still be able to rescue most coins. It's just that we'd have= =20 >> nowhere >> > > > to rescue them to, so we ought to make PQ wallets available soon,= =20 >> so we're >> > > > not in a rush to build them later when we need them. If a PQ walle= t=20 >> can >> > > > use cheap EC signatures while they're still trustworthy, all the= =20 >> better >> >=20 >> > FWIW, that's my guess on how things would play out if the near-term=20 >> 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'l= l >> > 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 publishe= d >> > 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-u= p >> > 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 understan= d >> > > 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= =20 >> 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=20 >> practically all active users. >> >=20 >> > I think it might be better to look at that scenario in a more=20 >> fine-grained >> > 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=20 >> spend-paths >> > via those outputs >> > 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of= =20 >> P2TRv2, >> > but EC spend paths continue to be what's used in practice. >> > 4) Some better PQ solutions become available, allowing cheap PQ-safe= =20 >> spend-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= =20 >> practice" >> > 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= =20 >> like: >> >=20 >> > 3') Only a small proportion of users (ie, the most=20 >> 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=20 >> Soon-ish >> > scenario to either: >> >=20 >> > 4'a) NoEC-day happens substantially before Q-day; people hurry to=20 >> migrate >> > to P2TRv2, but it mostly works. >> >=20 >> > or >> >=20 >> > 4'b) NoEC-day happens essentially at the same time as Q-day; coins g= et >> > 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 deprecat= e >> > every current address type is a danger to the entire ecosystem, even >> > absent widespread agreement on when/if Q-day will happen. Arguably tha= t >> > 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 t= o >> > zero, rather than up to ~14% per input. >> >=20 >> > Cheers, >> > aj >> >=20 >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/SHKHzyvg1Rr2E-CBLdgNEinhsnd= gXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeV= Ziups%3D%40protonmail.com >> . >> > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= a57e3fa9-b137-4b5e-8656-d09d9e77b126n%40googlegroups.com. ------=_Part_50439_1603164098.1782401097414 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 Systems such as Lightning and ProofnetBTC

Plugging your own L2 i= s not going to change the fact Bitcoin will need PQC to even allow those L2= s to settle securely. Everything else is make belief.

= > allowing innovation without requiring the Bitcoin mainnet itself to ab= sorb that additional complexity

You're essential= ly sweeping the problem under the rug without actually solving it, it's jus= t a word salad that doesn't add up logically. Bitcoin (the L1) will absolut= ely need PQC otherwise whatever you build on top has no better security tha= n what we began with, even if those L2s have <hyper secure PQC>, if t= hey settle in Bitcoin they are no more secure than Bitcoin itself.

The complexity introduced into Bitcoin will grow as we d= rag our feet:

1. If Bitcoin gets hash based PQC before Q-day, ve= ry little complexity and security assumptions are added. These are 1970s ki= nd of algos that build on existing hashes in Bitcoin.
2. If Bitco= in does not get any PQC before Q-day, then we need to introduce severely mo= re complex and prone to bugs (see Zcash recent break) ZK-STARK Circuits whi= ch are orders of magnitude more complex than a simple hash based signature = algo.

The more we reject the QC problem, the bigger in complexit= y the solutions will have to be.

torsdag 25 juni 2026 kl. 00:35:38 = UTC+2 skrev Anthony Derbidge:

I agree with the core point that Bitco= in=E2=80=99s post-quantum transition cannot rely primarily on self-reliance= . If the migration requires most users to understand Q-Day timing, keep EC = spend paths secret, or react quickly under pressure, then it is unlikely to= protect Bitcoin as a system. The safer path needs to be low-friction and c= lose to the default experience long before the threat becomes urgent.

That is why a "Later" style strategy seems compelling: ordinary = users can opt into a future migration path without immediately adopting res= trictive post-quantum workflows, while consensus can still act when the ris= k becomes concrete. Bitcoin mainnet should remain simple and conservative, = while more complex identity, recovery, coordination, and enhanced post-quan= tum workflows can exist in optional Bitcoin-aligned layers rather than the = base layer.

Systems such as Lightning and ProofnetBTC can experiment = with those optional workflows and recovery models while continuing to settl= e to Bitcoin, allowing innovation without requiring the Bitcoin main= net itself to absorb that additional complexity.

Best,
Anthony D.=


<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 24, 2026 at 3:50=E2=80=AFP= M 'Antoine Poinsot' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrot= e:
Hi AJ,

> There are three main variations to this, I think:
>
> [...]
>
> Self-reliance: Q-day goes from maybe to definitely faster than consens= us
>=C2=A0 changes can be coordinated, and the only reason people's fun= ds remain
>=C2=A0 safe is that they can (and do) keep the quantum-vulnerable spend=
>=C2=A0 paths secret.

I think that scenario may only result in a successful migration if the vast=
majority of users have updated their workflows to keep said quantum vulnera= ble
paths secret.

This may only happen if the vast majority of users either:
1. have preemptively updated their workflows during the "maybe" p= eriod;
2. react promptly enough (within weeks? a couple months?) to migrate all th= eir wealth.

Option (1) is utterly implausible. As Pieter explained in his email, we can= 't
expect users to adopt workflows radically at odds with how they use Bitcoin=
today in response to a (still --at the time they need to migrate) speculati= ve
threat.

I believe Bitcoin is successful precisely because users are not required to= be
active bitcoiners and pay close attention to avoid losing their funds. A substantial share of users value and rely on this property, and therefore O= ption
(2) is likewise implausible.

Therefore i don't think the "Self-reliance" variation can res= ult in a successful
migration.

> As far as I can see, only having P2TRv2 addresses would rule out the &= quot;self-reliance" path here.
>
> Picking when Q-day will occur, either individually for determining
> your own security posture, or collectively for organising a consensus<= br> > change seems very difficulty: it involves evaluating both complex stat= e
> of the art physics research, but also estimating the covert abilities<= br> > of national governments and the incentives to attack bitcoin prior to<= br> > revealing their capabilities. To me, that doesn't bode well for a = smooth
> and fast deployment of a consensus change in advance of problems occur= ing.

Yes. P2TRv2 optimizes for the "Later dominant" path at the expens= e of the
"self-reliance" path. I think this is good, because our best (onl= y?) shot at
fully migrating large amounts of users is to provide them with a virtually = free
way to opt into a future consensus-triggered migration.

The follow-up step does not require predicting with precision the day on wh= ich
an attack would be set up, but to be done before a CRQC could realistically=
threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In fa= ct if
P2TRv2 does become the Schelling point for PQ migration, i would be more concerned about the follow-up step happening too soon rather than too late.=

Of course, if a full CRQC is built in secret, with no reliable information = about
the progress getting out whatsoever, and subsequently starts attacking Bitc= oin
overnight, then this migration strategy would fail. But so would any other<= br> migration strategy!

> It's possible that general carelessness on behalf of users would a= lso
> rule out the effectiveness of a self-reliance approach: if only the mo= st
> 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&#= 39;t be
> very valuable either.

For what it=E2=80=99s worth, while the supply at risk matters, i think the = primary
metric we should optimize for is the share of users at risk. Widespread, indiscriminate theft would fatally undermine trust in Bitcoin, whereas more=
concentrated sweeps (such as that of early, presumed-lost coins) *could* ca= use
severe price shocks without necessarily destroying confidence in the system=
itself.

> > > Theorycrafting for a second here. It's reasonable to con= jecture 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 v= bytes 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 red= uce
> to ~7% (SHRINCS) or ~1% (winternitz).

Yes. Also, our goal here is to mitigate the risk that a CRQC materializes b= y
providing a path for Bitcoin to survive it. We shouldn't take the risk = for a
certainty and shift the goal to designing the best possible PQ-Bitcoin. Thi= s can
be done if/when it becomes clearer that CRQCs will become a reality.

> > 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 enou= gh.
>
> 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 t= ime,
> but for me "perfection" here means "no one who upgraded= lost money via
> quantum-related vulnerabilities".

I don't think that's a good definition of "timed perfectly&quo= t;. By your definition,
EC could be disabled from the get-go, Bitcoin's migration would spectac= ularly
fail because very few users switched to the new output type, and it would s= till
be "timed perfectly". :)

I would define "timed perfectly" as maximizing the number of migr= ated users
without any of them losing money to a CRQC. But it's not quite the righ= t
definition, because there is also probably an aspect of not doing it
prematurely, i.e. in the scenario where the CRQC threat never materializes,= no
P2TRv2 user is forced to use heavily restrictive PQ worklows.

> 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= 9;s slightly
> cheaper prior to Q-day.

>From the perspective that a successful migration hinges on virtually all us= ers
opting into a (full) migration to CRQC-safe workflows, this difference in c= osts
is material. Especially since users would presumably need to opt in long be= fore
we know whether CRQCs will become a reality anytime soon.

> My (cynical?) view is the only people who will adopt either P2TRv2 or<= br> > 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<= br> > EC pubkeys secret, and only revealing those EC pubkeys to spend them > immediately, prior to NoEC-day.

How can this apply to P2TRv2, where EC pubkeys are always public?

I think i disagree that most users of P2MR, were it made available, would t= reat
their EC public keys as secrets. But more importantly, the whole point of P2TRv2, or more generally of what Pieter labels "Later" type stra= tegies, is
precisely to avoid imposing on individual users the costs of treating their=
public keys as secrets. P2TRv2 (compared to other "Later" options= ) also ensures
that using it is no more costly than using any other available output type.=
Together, these properties may make users who are not yet particularly
concerned, or are simply unaware, indifferent to opting in: they bear the additional costs only if the CRQC threat materializes and are no worse off = if it
does not.

> > 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 individ= ual
> users the ability to safeguard their coins" is pretty close to th= e entire
> point of Bitcoin. :)

Cherry-picking this part of Pieter's sentence does not do it justice. O= f course
we all agree about this. But as he says in the part you left out, not addre= ssing
this issue as a systemic one is exactly how we lose that property: "I&= #39;m not
worried about my own coins being stolen. I'm worried about (fear of) a = CRQC
undermining trust in the currency as a whole, or through a fear-driven cons= ensus
change the ecosystem destroying its own values beforehand."

> having a consistent push that every single wallet/service that doesn&#= 39;t deprecate every current
> address type is a danger to the entire ecosystem, even absent widespre= ad agreement on when/if
> Q-day will happen.=C2=A0 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.

Yes, that's essentially the case for P2TRv2.

Best,
Antoine



On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns <a...@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, becaus= e
> > I realize the terms "Later" and "Never" aren&= #39;t very descriptive. They
> > are specifically about an expected and relied-upon expectation th= at 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&qu= ot;.
>
> > 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 i= nsufficient 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 safegu= ard
> > their own coins, but to me that's disaster recovery territory= - I think
> > we ought to prioritize maximizing the chances for saving the curr= ency
> > 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 regar= d in my view,
> > 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 gener= al idea
> is:
>
>=C2=A0 1) we create some new address types that allow post-quantum spen= ding, but
>=C2=A0 =C2=A0 =C2=A0also allow efficient quantum-vulnerable spending th= at can be used prior
>=C2=A0 =C2=A0 =C2=A0to Q-day
>
>=C2=A0 2) many people migrate to these new address types
>
>=C2=A0 3) Q-day arrives
>
>=C2=A0 4) all spending goes via the post-quantum paths, and everyone= 9;s funds are
>=C2=A0 =C2=A0 =C2=A0safe
>
> There are three main variations to this, I think:
>
>=C2=A0 Later-dominant: towards the end of (2) but prior to (3), the
>=C2=A0 =C2=A0 =C2=A0quantum-vulnerable spend paths are disabled in a pr= edictable, planned
>=C2=A0 =C2=A0 =C2=A0manner, preventing coin theft, but not disrupting a= ctive usage
>=C2=A0 =C2=A0 =C2=A0significantly (or not disrupting it any more than t= he proximity of
>=C2=A0 =C2=A0 =C2=A0Q-day already is).
>
>=C2=A0 Self-reliance: Q-day goes from maybe to definitely faster than c= onsensus
>=C2=A0 =C2=A0 changes can be coordinated, and the only reason people= 9;s funds remain
>=C2=A0 =C2=A0 safe is that they can (and do) keep the quantum-vulnerabl= e spend
>=C2=A0 =C2=A0 paths secret.
>
>=C2=A0 Disaster-recovery: neither the "predictable/planned consens= us change" of
>=C2=A0 =C2=A0 Later nor the "everyone takes responsiblity for thei= r own funds"
>=C2=A0 =C2=A0 works, and the only way to avoid a large percentage of bi= tcoin
>=C2=A0 =C2=A0 becoming a reward for quantum research is to replace EC s= pend paths
>=C2=A0 =C2=A0 with a ZK proof of knowledge of a BIP32 seed or similar, = requiring
>=C2=A0 =C2=A0 a hard fork.=C2=A0 Such a hard fork would be certain to b= e controversial
>=C2=A0 =C2=A0 ("why at this height: I received a payment five bloc= ks after //
>=C2=A0 =C2=A0 my funds were stolen by a quantum attacker five blocks ea= rlier //
>=C2=A0 =C2=A0 why are only BIP32 funds recoverable not scheme X"),= but if no other
>=C2=A0 =C2=A0 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 t= he 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<= br> > change seems very difficulty: it involves evaluating both complex stat= e
> of the art physics research, but also estimating the covert abilities<= br> > of national governments and the incentives to attack bitcoin prior to<= br> > revealing their capabilities. To me, that doesn't bode well for a = smooth
> and fast deployment of a consensus change in advance of problems occur= ing.
>
> It's possible that general carelessness on behalf of users would a= lso
> rule out the effectiveness of a self-reliance approach: if only the mo= st
> 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&#= 39;t be
> very valuable either. But even then, that may make the "disaster-= recovery"
> approach less problematic, by ensuring the 1%/10% who were conscientio= us
> can avoid being part of the "my funds were stolen by a quantum at= tacker"
> contingent, eg.
>
> > > Theorycrafting for a second here. It's reasonable to con= jecture 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 v= bytes 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 red= uce
> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,=
> you're only getting an expected savings in fees / increase in bloc= k
> capacity on that order of magnitude, ie: 1%-7%. That's nice to hav= e,
> for sure, but doesn't compare to introducing a new address type th= at
> puts the PQ sigs in an extension block, or one that uses ZK proofs to<= br> > do cross-input or cross-transaction signature aggregation, eg. So a 32= B
> 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 enou= gh.
>
> 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 t= ime,
> 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 look= s inevitable"
> 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 k= now,
> >> 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 yea= rs
> >> out. 2029 happens to be the date selected by Google, Cloudfla= re, and
> >> the Ethereum Foundation.
>
> https://x.com/drakefjustin/status/2061793725299224= 676
>
> >> So, here it is: if quantum computers start breaking cryptogra= phy 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= switching
> >> to quantum-resistant encryption, and urge your company or org= anization
> >> or blockchain or standards body to do the same.
>
> https://sc= ottaaronson.blog/?p=3D9718
>
> Personally, that leaves me at a minimum very skeptical of the utility<= br> > of introducing either P2MR or P2TRv2 (etc) approaches that don't a= lso
> introduce a quantum-safe spending path on day one.
>
> > First a meta-point here: the reason I like separating the discuss= ion into different dimensions than just "P2TRv2 vs P2MR" is becau= se there are more options than those two, and not every argument applies to= the same separation into two classes. Let me list them explicitly here, ro= ughly in decreasing order of how strongly I feel about them:
> > - We need at least a "Later" option for meaningful migr= ation, i.e. P2TRv2 or P2MR+ED.
> > - Within the "Later" option, P2TRv2 is preferable.
> > - A "Later" option benefits from being the only PQC mig= ration strategy, making 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= 9;s slightly
> cheaper prior to Q-day. If it were the only available option, that wou= ld
> increase the risk of loss involved with both the other approaches. (I<= br> > don't think P2TRv2 is meaningfully more private than P2MR in the w= ay
> 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 under the public knowledge that it is insecure and their coin= s are more likely to be stolen. That's a hard sell.
> >
> > > How does one pitch P2TRv2 to users? "It will be quantum= secure one day we 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 migrate." for both. P2TRv2 is just much easier to adopt, be= cause P2MR (or any "Never" output type) fundamentally requires ma= ny users to change their workflows entirely.
>
> Let's call NoEC-day the earlier of activation of a soft-fork disab= ling
> EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumab= ly
> equal to "the day the bitcoin ecosystem has finally agreed that C= RQCs
> are inevitable".
>
> My (cynical?) view is the only people who will adopt either P2TRv2 or<= br> > 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<= br> > 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 su= ch
> coins prior to NoEC-day are only an opportunistic "make spends ch= eaper"
> shortcut, they don't allow the funds to be used in lightning chann= els
> or to let your wallet be audited via sharing an xpub or anything simil= ar.
>
> Perhaps I'm wrong: it's my opinion, not a technical fact; it&#= 39;s possible
> that lightning software could get an upgrade to generate post-quantum<= br> > signatures for channel commitments or HTLC claims, I just think it'= ;s
> pretty unlikely that that will happen at a meaningful scale when every= one
> has much more immediate and less theoretical things to work on prior t= o
> NoEC-day, especially when the efficiency/performance of such changes i= s
> 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 individ= ual
> users the ability to safeguard their coins" is pretty close to th= e entire
> point of Bitcoin. :)
>
> > In either case, I consider anything that requires hardcoding
> > specific wallet designs (BIP32 or otherwise) into Bitcoin's c= onsensus
> > rules (and only allowing those coins to survive) to be squarely i= n
> > disaster-recovery land. It feels like embracing arbitrariness, an= d
> > giving up on the permissionlessness that makes Bitcoin interestin= g -
> > if the community shows it can get consensus on effectively burnin= g
> > coins except those that match a whitelist, it feels hard to maint= ain
> > censorship-freeness as a value, even if the whitelist includes mo= st 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 rec= overy
> > scenarios to save what's left, after Q-day, if migration atte= mpts were
> > unsuccessful. In such a setting, I think we're already in eff= ectively an
> > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (pos= sibly
> > 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 t= he
> "disaster-recovery" scenario above: the "quantum-safe&q= uot; hard-fork variant
> of bitcoin would be fairly described as a utxo-bootstrapped altcoin, > would compete in the market with the "quantum-unsafe" bitcoi= n 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 t= o choose
> so that all paths lead to a victory."
>
>=C2=A0 -- 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 wher= e 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 Bi= tcoin in
> > a form we care about anyway. By accepting that, we can focus on t= he
> > 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 oth= er
> 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<= br> > even given Q-day in a few years I expect we could do better than just<= br> > that, but it doesn't feel like a throw-in-the-towel event to me. >
> > > Essentially yes though, I expect the majority of holders wil= l probably
> > > migrate to PQ addresses via rescue protocols, either on Bitc= oin 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
> > > 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 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-ter= m Q-day
> timelines I've seen (ie, 2029 to 2035) match reality. I hope that&= #39;s
> pessimistic (either because the Q-day timelines are bad estimates, or<= br> > because migration happens in a more orderly fashion), but I guess we&#= 39;ll
> see. I don't rate my ability to evaluate Q-day predictions very hi= ghly.
>
> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>
> I'm not in a position to judge, but the google paper claims:
>
>=C2=A0 =C2=A0 "Indeed, if a leading quantum architecture encounter= s and overcomes
>=C2=A0 =C2=A0 all its scaling challenges before producing a device able= to
>=C2=A0 =C2=A0 solve (for example) 32-bit ECDLP, then there may be littl= e time
>=C2=A0 =C2=A0 between the breaking of 32-bit ECDLP and the breaking of = 256-bit
>=C2=A0 =C2=A0 ECDLP. Furthermore, the community should not expect to se= e published
>=C2=A0 =C2=A0 demonstrations of the most advanced quantum error-correct= ion
>=C2=A0 =C2=A0 architectures and quantum algorithms deployed to cryptana= lytic
>=C2=A0 =C2=A0 problems. Thus, a successful public demonstration of Shor= =E2=80=99s
>=C2=A0 =C2=A0 algorithm on a 32-bit elliptic curve should not be seen a= s a wake-up
>=C2=A0 =C2=A0 call to adopt PQC as much as a potential signal that PQC = adoption
>=C2=A0 =C2=A0 has already failed."
>
> and places the required tiffoli gates and logical qubits for a 32-bit<= br> > 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 un= derstand
> > you'd come to a different conclusion. But is it really? Do yo= u 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 opcod= es.
> > - Over the course of the next decade or so, it gets adopted by pr= actically all active users.
>
> I think it might be better to look at that scenario in a more fine-gra= ined
> way? I think your "Late-ish" scenario is:
>
>=C2=A0 =C2=A01) P2TRv2 (or whatever) is introduced
>=C2=A0 =C2=A02) Some PQ opcodes get enabled, allowing expensive but PQ-= safe spend-paths
>=C2=A0 =C2=A0 =C2=A0 via those outputs
>=C2=A0 =C2=A03) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in= favour of P2TRv2,
>=C2=A0 =C2=A0 =C2=A0 but EC spend paths continue to be what's used = in practice.
>=C2=A0 =C2=A04) Some better PQ solutions become available, allowing che= ap PQ-safe spend-paths
>=C2=A0 =C2=A05) Everyone switches from EC paths to the new PQ paths. >=C2=A0 =C2=A06) NoEC-day happens, but no one is impacted.
>
> I think your "Soon-ish" scenario differs as of step (4):
>
>=C2=A0 =C2=A04) NoEC-day happens. Massive disruption because the "= what's used in practice"
>=C2=A0 =C2=A0 =C2=A0 path breaks, but everything is recoverable.
>=C2=A0 =C2=A05) Post-quantum approaches get even higher priority
>
> I'm skeptical of step 3 here; and would expect to see something mo= re like:
>
>=C2=A0 =C2=A03') Only a small proportion of users (ie, the most con= scientious/fearful)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0switch to P2TRv2 with most preferring to sti= ck with what works
>
> That has no real impact on the Late-ish scenario, but changes the Soon= -ish
> scenario to either:
>
>=C2=A0 =C2=A04'a) NoEC-day happens substantially before Q-day; peop= le hurry to migrate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 to P2TRv2, but it mostly works.
>
> or
>
>=C2=A0 =C2=A04'b) NoEC-day happens essentially at the same time as = Q-day; coins get
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 stolen and we hit the disaster-recovery sce= nario.
>
> 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<= br> > consistent push that every single wallet/service that doesn't depr= ecate
> every current address type is a danger to the entire ecosystem, even > absent widespread agreement on when/if Q-day will happen. Arguably tha= t
> would be easier to agree on if the incremental cost of EC spend paths<= br> > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near t= o
> zero, rather than up to ~14% per input.
>
> Cheers,
> aj
>

--
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 bitcoindev+...@googlegro= ups.com.
To view this discussion visit https://g= roups.google.com/d/msgid/bitcoindev/SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDB= JAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40p= rotonmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/a57e3fa9-b137-4b5e-8656-d09d9e77b126n%40googlegroups.com.
------=_Part_50439_1603164098.1782401097414-- ------=_Part_50438_604337863.1782401097414--