From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 26 Jun 2026 10:16:10 -0700 Received: from mail-oo1-f62.google.com ([209.85.161.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 1wdA9u-0005Qg-Jw for bitcoindev@gnusha.org; Fri, 26 Jun 2026 10:16:10 -0700 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-6a15126a0c8sf479296eaf.0 for ; Fri, 26 Jun 2026 10:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782494160; x=1783098960; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=uUKWY5gFevhvGyrebE+zPl9PSQ2lmG5LcXemi0zUftw=; b=Y/0H6wSlumHKHE8VoJRAMbiKkgJFwjLYTVBVfWsT3Dtv3aBpkJqIUysOTabATDXQ78 hg2ayyEoEROdmR/zSVHoAXDjEcRkwZ3wTwbXrd/7pLgdSIZ2mwPGDQO8gWpbTUXcD6uw q/Inojf9RkIMgjJWfP8nnFSC8Yw6KTpQKdkKA3opYbAJ5iOjA4ulwkb9D7y2KhZ2Q33t ep3bAZkFAeTT9tvj2+0VnpdQmaDeW9l9j6NQbPJ/88m2PV8aj4fPImFfq3GujK37xv0v yqYQX8iLUvy+Piv8x0Q+oGAGNPRRss3BR275/5dMFKD7jnHv+PGFiuTrM9/1gjpll9FT 03kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782494160; x=1783098960; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uUKWY5gFevhvGyrebE+zPl9PSQ2lmG5LcXemi0zUftw=; b=IwkoToUzWXeYtxab5vONX3OzIPtvfIzkIB/ra3VV9bDtluoJE1gcI5cfxyvwjRY6uE SckglgfWxUaMqfWRr631uexNd6oXis0oh87U/Fes8sSZt7aQ7e8cLcTZWk621XT44n/U sa6bKO4klR+dSDZge8h+8rRuIuqbS9ibg+lgycv6EYYbDWQYu1ouPRmX3UTLan77wFTp Ek63oeQLmLtPZW/DgNyv/AEMONHDUHbURGOkya/Ju9LpGnvkfHo1clHpff9I8Ldb7Vtx vOZhwlLmQrYKfLu4x1GbbjFsRrAZnMIrtxRRCj1KVMnuv2BVotNhcmsQ3XhZht98Jpdx pVxw== X-Forwarded-Encrypted: i=1; AFNElJ9RO1fyT5uT1zVkfuknDzToPphT2Q47Bu1MbDNLkkE4ZcR3jPec0+m59za7C+M3WZA/TWep2gvI5m88@gnusha.org X-Gm-Message-State: AOJu0Yy1UULyt5GZewsltONPLKet6ul7xzJQFxARDH2zX1nRfkvaBGD7 ohEc9X6fARsWfIjaPO+vWSIH4NcfXZjgiTWf82eCNdmguhw8FZuqQjs6 X-Received: by 2002:a05:6820:f010:b0:6a1:50bb:5fe0 with SMTP id 006d021491bc7-6a150bb8689mr897641eaf.23.1782494160193; Fri, 26 Jun 2026 10:16:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUd9ODi5yM7rw1Z74vmO1A/dsSfAbZE5bhINBKvQ/0twUA==" Received: by 2002:a05:6820:1c81:b0:6a0:dfb6:717c with SMTP id 006d021491bc7-6a0dfb68545ls1382478eaf.2.-pod-prod-04-us; Fri, 26 Jun 2026 10:15:54 -0700 (PDT) X-Received: by 2002:a05:6808:508c:b0:489:6c3b:eea7 with SMTP id 5614622812f47-4921890ade0mr7057915b6e.41.1782494154692; Fri, 26 Jun 2026 10:15:54 -0700 (PDT) Received: by 2002:a05:690c:e64d:b0:7ba:f1b3:9504 with SMTP id 00721157ae682-80ba40ed445ms7b3; Fri, 26 Jun 2026 09:11:18 -0700 (PDT) X-Received: by 2002:a05:690c:4989:b0:80c:85e5:872d with SMTP id 00721157ae682-80c85e58b08mr10784897b3.59.1782490277365; Fri, 26 Jun 2026 09:11:17 -0700 (PDT) Date: Fri, 26 Jun 2026 09:11:16 -0700 (PDT) From: "'conduition' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <88207cb2-e266-4f84-be3f-f245a3e2724en@googlegroups.com> In-Reply-To: <2UBm2dVIs3jNHvlZtgXA_7Pfa09T6bK0BBkpvEZUMV8CNgeOwpG87vmUZ9vEnn0TQIfag2uIbiViizuDaND9UljX9LdDqHYXgJhTlW7OGqs=@protonmail.com> References: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> <81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg=@wuille.net> <2UBm2dVIs3jNHvlZtgXA_7Pfa09T6bK0BBkpvEZUMV8CNgeOwpG87vmUZ9vEnn0TQIfag2uIbiViizuDaND9UljX9LdDqHYXgJhTlW7OGqs=@protonmail.com> Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_42322_34069597.1782490276937" X-Original-Sender: conduition@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 (-) ------=_Part_42322_34069597.1782490276937 Content-Type: multipart/alternative; boundary="----=_Part_42323_372764369.1782490276937" ------=_Part_42323_372764369.1782490276937 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey list, Following up on my original post, a PR has been filed and merged into=20 BIP360 which amends the spec to change depth-zero trees to be=20 anyone-can-spend. Kudos to Ethan Heilman for this excellent suggestion in= =20 response to my OP. P2MR is now much more closely aligned with P2TR in terms= =20 of privacy (though still not perfectly). https://github.com/bitcoin/bips/pull/2198 I would also like to point out that a much more secure candidate than=20 P2TRv2 exists. In this delving thread=20 ,=20 Ruben, AJ, and I discussed the option of using Boris Nagaev's EC recovery= =20 idea to implement "P2TRH" (essentially P2TR but with the output key hidden= =20 behind a hash). Thanks to EC recovery, key-spend witnesses would still be= =20 only 64 bytes as in P2TR. We would lose Schnorr batch verification, but=20 gain protection against long-exposure attacks, because bare EC pubkeys are= =20 no longer posted in the script pubkey. A PQ leaf can be hidden in a script= =20 tree commitment just like in P2TRv2. I think this is a much more compelling candidate than P2TRv2. It still=20 requires a follow-up soft-fork to at least disable EC key-spending, but=20 until then users with funds in such hashed addresses would be safe provided= =20 they do not attempt to spend their coins before the disabling fork is=20 activated. Ultimately I still suspect the community will favor P2MR, because P2MR will= =20 still be desirable to deploy one way or the other after Q-day, with or=20 without EC disabling, and regardless of how that disabling is triggered. It= =20 requires no follow-up and incentivizes migration due to its security=20 properties, now with negligible (32b) cost thanks to recoverable EC leaves. I would be fine with ArmchairCryptologist's idea of deploying two output=20 types, although it seems redundant to me personally: Anyone doing=20 high-volume transacting who cares so much about fees is probably reactive= =20 enough to move coins to P2MR when a CRQC threat is apparent, and could do= =20 so much faster than we can deploy any EC-disabling soft-fork. Also, if fees= =20 are indeed so important, then why has only a tiny fraction of the UTXO set= =20 migrated to P2TR? (I've made these points in earlier emails) regards, conduition On Friday, June 26, 2026 at 3:42:05=E2=80=AFAM UTC-6 ArmchairCryptologist w= rote: > In my humble opinion, I think the preference for P2MR vs P2TRv2 for users= =20 > would largely boil down to whether or not someone is a long-term holder, = or=20 > someone who actively makes frequent transactions on the network. > > On one hand, if I were a self-reliant long-term holder of significant=20 > assets (which I may or may not be), I would be reluctant to use P2TRv2 fo= r=20 > this, since the funds would always be fully exposed to CRQCs until such a= =20 > time EC spending is disabled by a third party, which may or may not happe= n=20 > in time. > > On the other, if I were making frequent transactions on the network (whic= h=20 > I may or may not do), I would be reluctant to use P2MR for this due to th= e=20 > additional transaction cost, which would be wasteful before CRQCs exist -= =20 > and especially considering that they might never exist. > > As such, unless someone were to come up with a different scheme that has= =20 > the best of both worlds, I feel like the discussion should be more along= =20 > the lines of "one, or possibly both if it is beneficial" rather than "we= =20 > have to pick just one no matter what". > > Personally, using the ideas Pieter Wuille presented in the other thread,= =20 > my preference would be to add both: > > - P2TRv2 using one or both of the Tripwire and Miner Lockdown triggers=20 > (P2TRv2-T / P2TRv2-ML / P2TRv2-T-ML) to emergency-disable EC spending,=20 > while still leaving the ability to disable it with a soft fork, for=20 > frequent transactors and people who trust miners to act responsibly. > > - P2MR (plain), with EC spending only disabled with a soft fork, for the= =20 > self-reliant holders who know (how) to not expose their EC public key and= =20 > want full control over their funds. > > This would leave EC spending available for P2MR while it is still in the= =20 > "danger zone" and after it has been initially disabled for P2TRv2, but=20 > when/if EC spending is considered by the developers to be completely=20 > broken, a follow-up soft fork would disable it for both address types. > > I feel like this should be worth the trade-offs of easier wallet=20 > fingerprinting as well as the increase in implementation complexity and= =20 > long-term maintenance cost - but then again, I'm not the one paying that= =20 > cost, and the people who will might disagree. > > -- > Best, > ArmchairCryptologist > > On Thursday, June 25th, 2026 at 12:35 AM, Anthony Derbidge < > ader...@gmail.com> wrote: > > 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 prio= r >> > 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, 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 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. >> >=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=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 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 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 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 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= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/CACja%3DNz%3DA2wV68MMBYcgOMD= jwcXpKNQsptdP2NVqXske%3DONG6w%40mail.gmail.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/= 88207cb2-e266-4f84-be3f-f245a3e2724en%40googlegroups.com. ------=_Part_42323_372764369.1782490276937 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey list,

Following up on my original post, a PR has b= een filed and merged into BIP360 which amends the spec to change depth-zero= trees to be anyone-can-spend. Kudos to Ethan Heilman for this excellent su= ggestion in response to my OP. P2MR is now much more closely aligned with P= 2TR in terms of privacy (though still not perfectly).

https://github.com/bitcoin/bips/pull/2198

= I would also like to point out that a much more secure candidate than P2TRv= 2 exists. In this delving thread, Ruben, AJ, and I= discussed the option of using Boris Nagaev's EC recovery idea to implement= "P2TRH" (essentially P2TR but with the output key hidden behind a hash). T= hanks to EC recovery, key-spend witnesses would still be only 64 bytes as i= n P2TR. We would lose Schnorr batch verification, but gain protection again= st long-exposure attacks, because bare EC pubkeys are no longer posted in t= he script pubkey. A PQ leaf can be hidden in a script tree commitment just = like in P2TRv2.

I think this is a much more comp= elling candidate than P2TRv2. It still requires a follow-up soft-fork to at= least disable EC key-spending, but until then users with funds in such has= hed addresses would be safe provided they do not attempt to spend their coi= ns before the disabling fork is activated.

Ultim= ately I still suspect the community will favor P2MR, because P2MR will stil= l be desirable to deploy one way or the other after Q-day, with or without = EC disabling, and regardless of how that disabling is triggered. It require= s no follow-up and incentivizes migration due to its security properties, n= ow with negligible (32b) cost thanks to recoverable EC leaves.
I would be fine with ArmchairCryptologist's idea of deployin= g two output types, although it seems redundant to me personally: Anyone do= ing high-volume transacting who cares so much about fees is probably reacti= ve enough to move coins to P2MR when a CRQC threat is apparent, and could d= o so much faster than we can deploy any EC-disabling soft-fork. Also, if fe= es are indeed so important, then why has only a tiny fraction of the UTXO s= et migrated to P2TR? (I've made these points in earlier emails)
<= br />
regards,
conduition
On Friday, June 26, 2026 at 3:42:= 05=E2=80=AFAM UTC-6 ArmchairCryptologist wrote:
In my humble opinion, I think the preference for P= 2MR vs P2TRv2 for users would largely boil down to whether or not someone i= s a long-term holder, or someone who actively makes frequent transactions o= n the network.

On one hand, if I were a sel= f-reliant long-term holder of significant assets (which I may or may not be= ), I would be reluctant to use P2TRv2 for this, since the funds would alway= s be fully exposed to CRQCs until such a time EC spending is disabled by a = third party, which may or may not happen in time.

On the other, if I were making frequent transactions on the ne= twork (which I may or may not do), I would be reluctant to use P2MR for thi= s due to the additional transaction cost, which would be wasteful before CR= QCs exist - and especially considering that they might never exist.<= /div>

As such, unless someone were to come up with= a different scheme that has the best of both worlds, I feel like the discu= ssion should be more along the lines of "one, or possibly both if it i= s beneficial" rather than "we have to pick just one no matter wha= t".

Personally, using the ideas = Pieter Wuille presented in the other t= hread, my preference would be to add both:

= - P2TRv2 using one or both of the Tripwire and Miner Lockdown trigger= s (P2TRv2-T / P2TRv2-ML / P2TRv2-T-ML) to emergency-disable EC spending, wh= ile still leaving the ability to disable it with a soft fork, for frequent = transactors and people who trust miners to act responsibly.

- P2MR (plain), with EC spending only disabled with = a soft fork, for the self-reliant holders who know (how) to no= t expose their EC public key and want full control over their funds.=

This would leave EC spending available for = P2MR while it is still in the "danger zone" and after it has been= initially disabled for P2TRv2, but when/if EC spending is considered by th= e developers to be completely broken, a follow-up soft fork would disable i= t for both address types.

I feel like= this should be worth the trade-offs of easier wallet fingerprinting as wel= l as the increase in implementation complexity and long-term maintenance co= st - but then again, I'm not the one paying that cost, and the people w= ho will might disagree.

--
Best,
ArmchairCryptologist
=20
=20
=20

<= /div>
On Thursday, June 25th, 2026 at 12:35 AM, Anthony Derbidge <ader...@gmail.com> wrote:

I agree with the core point that Bitcoin=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 prot= ect Bitcoin as a system. The safer path needs to be low-friction and close = 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 restrict= ive post-quantum workflows, while consensus can still act when the risk bec= omes concrete. Bitcoin mainnet should remain simple and conservative, while= more complex identity, recovery, coordination, and enhanced post-quantum w= orkflows 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 settle to = Bitcoin, allowing innovation without requiring the Bitcoin mainnet i= tself to absorb that additional complexity.

Best,
Anthony D.

<= /div>
O= n Wed, Jun 24, 2026 at 3:50=E2=80=AFPM 'Antoine Poinsot' via Bitcoi= n Development Mailing List <bitco...@googlegroups.com> 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 re= main
> 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 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. Arguably that would be easier to agree on if the i= ncremental 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:
>
> 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
>
> 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 f= unds are
> 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, plan= ned
> 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 consen= sus
> 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 ch= ange" of
> Later nor the "everyone takes responsiblity for their own fund= s"
> 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<= br> > 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 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/2061793725299224676
>
> >> 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://scottaaronson.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."
>
> -- 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:
>
> "Indeed, if a leading quantum architecture encounters and over= comes
> 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."
>
> 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:
>
> 1) P2TRv2 (or whatever) is introduced
> 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend= -paths
> 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 practice"
> 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 mo= re like:
>
> 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= -ish
> scenario to either:
>
> 4'a) NoEC-day happens substantially before Q-day; people hurry t= o migrate
> to P2TRv2, but it mostly works.
>
> or
>
> 4'b) NoEC-day happens essentially at the same time as Q-day; coi= ns 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<= 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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOK= HSqjsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40protonmail.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 bitcoindev+...@googlegroups.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/88207cb2-e266-4f84-be3f-f245a3e2724en%40googlegroups.com.
------=_Part_42323_372764369.1782490276937-- ------=_Part_42322_34069597.1782490276937--