From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 26 Jun 2026 02:42:14 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wd34d-0000kJ-17 for bitcoindev@gnusha.org; Fri, 26 Jun 2026 02:42:14 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-43d052ba649sf946153fac.1 for ; Fri, 26 Jun 2026 02:42:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1782466925; cv=pass; d=google.com; s=arc-20260327; b=VrM3mYYRBsMXSwPHGaMoa8DlYAQkEMp+GwIZ2XSqO/RSPFDMGvnspAGQVajB6Xr3qz Se/HeTjcGTKeMAw8zDmLlVChAmktUmMFHePRkT1kfVCZNS12KvwBjlv2BWb7DZDLvTP0 yYD4vk9ahyaigTA689Smuc54iwYW0IvZPHsLoYoeePwfvdjj6XRhPuj5HvbcsPQPIZkb FNS81bj9A1ChzvjqshNekyNdB5mXElE64uYg1wyNJalHDSuGsGf6r909hdoZr0nqCmwh CYAdceBBTb+4ghTtr7o49NuKYJ1zYlucFv512o0srlgInk7I+dcORciSjitpaQkqMf56 Ri7A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:from:to:date :dkim-signature; bh=fxvkKj+RVbnyE2syx9FGlqWb1YqnYDWwMRxGvUgqSHs=; fh=FlW+Nk0Q9vQ8jEzrBkuCrqBVzCDM21sVGeMehmOijsA=; b=UOZgcGy4LjYOasFp7iqhOQLz4pn7NgdYMw6k/gJ7xiFIoCXR5Chs0IHW+lUEjrPDcw 5rSUW5YQt0J2CYYk2ouuxWdg/CAScYGAZO2WvrgZO+rvnGI/djUcS29Vd18S0KYgzx9Q imgkMEdrZ951U+1A5pDIm2tsMzSWjILEQhx545HZqX84tiPjCV4ju5pCYNa53noh1Ww7 Y0jYy/IKmTj91fZaGVW5Ae07PGP/F/qu1buEERxN2SYzLFUeQjlu7xREyOj/j5y1UeGD 8GVRNHhMndWjZ2MSaoWN7eX1Qxkh0AXVOLeKHQBC9fWY3our7KLG933UWQPkgEHpSx+0 QJXw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="L/o4QZqq"; spf=pass (google.com: domain of armchaircryptologist@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=ArmchairCryptologist@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782466925; x=1783071725; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:from:to:date :from:to:cc:subject:date:message-id:reply-to; bh=fxvkKj+RVbnyE2syx9FGlqWb1YqnYDWwMRxGvUgqSHs=; b=kQqLvPhz3d4GQkzAO+xLe/pE6S68DQRfTF/ToMy+JV8d4gKJf7SfRI6salFUcV/cjy zmD+Hyy8wRFIPds9B6/kl/qphkIqdjes2EA5o1kLvGo3XF8dDFYZbtqTacjdniXhrBa3 KQONVDhcMTC+RWAM5PXRTgOpw9C0APiv+FiTntOkLHeaaj1GPgqLNtyXJx97RKTSEMxL xypqCfjd4phe1wYlH1jFSSdsu/V70btBynwdse07la1p8R3tKW+f2yQM2dcDtqoeNrJS RV6+OC/QEXzyayzkcuq6i/ujaaATLb6TG2wELWkVbV+AblQ6w136NUR1ZHT+YEsrZUpi eiiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782466925; x=1783071725; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fxvkKj+RVbnyE2syx9FGlqWb1YqnYDWwMRxGvUgqSHs=; b=Lq9A9qjdh+DG2KMObuWnljm7nI4ULmJ0B4Scj3r7TSKiWZ21EPwFgnenyoHkBIWgu8 QbVJg/SJQXg+KzSvStE89MeVjD0AvKneCzAMxlgHkG+noTkajzbU0i8nD6GJAx6VQihJ JUfBw9Bv1pWWfbYs9jbYM/X/rOTqDUhlGp+LbTmMP7NM8UTcv6/ZRn4X0ATaLeJOdr5b ggeb0G4awyx+dC6uaWw3sVMwvDbIyJuOs1RIyJ55prpXNLNAFdMemG9ji08vtTcfaDMm w38DjcWs0ywclQz+YbAGJWnF1OZu7BIYnBEMOnf+1J7hiJRKLyJyLOmFs0YnXzUYpWI9 RK+g== X-Forwarded-Encrypted: i=2; AHgh+RobRqiytQ+sNYHy+iAtbASrXFbPVIkmqXS3occwDGz5asErun87MhrcyEHKpfQvzVag5AfybK/2XW0z@gnusha.org X-Gm-Message-State: AOJu0Yw5YCymcV2eYSOUcAmt9ULswKEgry9XHoZvS48OjPiHNp+qObu0 MV7/qBvNzqkOjgFjdw1d+bxxtUEyB9xo3MJkbrntU2gCqIlvYxbxJoZb X-Received: by 2002:a05:6870:45a7:b0:447:cc92:3c31 with SMTP id 586e51a60fabf-448117bab8cmr4868343fac.1.1782466924975; Fri, 26 Jun 2026 02:42:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdrGPlmIUSVV9FEVWewGysMazHajD/lWNI2Omqs2pG/Gg==" Received: by 2002:a05:6871:78c:b0:41c:64c3:46be with SMTP id 586e51a60fabf-446dfb16a9cls6062640fac.1.-pod-prod-07-us; Fri, 26 Jun 2026 02:42:01 -0700 (PDT) X-Received: by 2002:a05:6808:4e0e:b0:492:32d3:fdd2 with SMTP id 5614622812f47-49232d414e9mr4652582b6e.5.1782466921589; Fri, 26 Jun 2026 02:42:01 -0700 (PDT) Received: by 2002:a05:600c:4652:b0:492:6724:fce8 with SMTP id 5b1f17b1804b1-4926b60364cms5e9; Fri, 26 Jun 2026 02:27:17 -0700 (PDT) X-Received: by 2002:a05:600c:524c:b0:490:bd1d:472a with SMTP id 5b1f17b1804b1-49266850121mr87543025e9.15.1782466036145; Fri, 26 Jun 2026 02:27:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782466036; cv=none; d=google.com; s=arc-20260327; b=G8slRLMuZhIocGotnob/3sJNngxugQ6PQKnEEc0rUhh+Xb0ZKkHepx2ET/iXHXazJa ySSZX2P7QV8FVj9aH5k2FMCKeJn7ZZXcVhbhrjaTASzNxj7bGefvdRpcPBo/X03Kx3uM d4HSHMA13KEWAs0HtjeYlHB/fiubkzp7nBAbMA72ARVamvlHSiV+vmdfUsegvagUlt5B iGVr4hqGPNEuoXlQRRvZfqwNEQ1PW7VkY026xSPWWEmJmR8FZ1cPFyH/XUJcUSJ2n9PT b2tOXh2ydOv2pymYhsEcu2UcM5gxj6Fiw9fM0fNP2q7rHiEuxTTbOaU2Fu8fPW2rPPqU fbpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:dkim-signature; bh=rhRy20ilTdbaSxMnBKGF2C729znAArLd1pVUr51m3yA=; fh=lhFSo2W/mHC0QoJ9oNg3A35n0DTltt3CQl1/0RggJlk=; b=lT6WCee1LMywZZnuGXMCEQ5rc4nr8a9tKnuuIsivV9eizKaIevUPmEpRkulbfyOrme RvvkQwxRRXlBLBlu3/gRqfOK1QVUwbGMYbvvFdzM02lLwcOpf4GLlIPvWVhMiJNLlTm6 lLyPS1Uo8A78ag0pXZ0AsjlF5HEIJDJ3ckiEBSG4c/j6kqbAfmNSlIqR4l9XVxnATF3e MwKRXKbbFqreERk/TpXcM6FKXsCXYwcnija49AGp5vSgDvYEgAw3f9rvEdriRBgq3mpC oUmO6DZ1ALCdZ+PZSDS3LXuQWYgutrTgroRMz4KPBuNzV0PfE2Gal+d1HHQg4y8mDczx vOPA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="L/o4QZqq"; spf=pass (google.com: domain of armchaircryptologist@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=ArmchairCryptologist@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch. [185.70.43.16]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-49269025193si480055e9.1.2026.06.26.02.27.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2026 02:27:15 -0700 (PDT) Received-SPF: pass (google.com: domain of armchaircryptologist@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16; Date: Fri, 26 Jun 2026 09:27:09 +0000 To: "bitcoindev@googlegroups.com" From: "'ArmchairCryptologist' via Bitcoin Development Mailing List" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: <2UBm2dVIs3jNHvlZtgXA_7Pfa09T6bK0BBkpvEZUMV8CNgeOwpG87vmUZ9vEnn0TQIfag2uIbiViizuDaND9UljX9LdDqHYXgJhTlW7OGqs=@protonmail.com> In-Reply-To: References: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> <81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg=@wuille.net> Feedback-ID: 24244585:user:proton X-Pm-Message-ID: d7dea6c82078f3fee3f86c73718ff7a41232eb77 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_4xlAhClERbHII96vMQidBB52R6LbDQD2vtIMuk8" X-Original-Sender: armchaircryptologist@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="L/o4QZqq"; spf=pass (google.com: domain of armchaircryptologist@protonmail.com designates 185.70.43.16 as permitted sender) smtp.mailfrom=ArmchairCryptologist@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: ArmchairCryptologist Reply-To: ArmchairCryptologist Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) --b1=_4xlAhClERbHII96vMQidBB52R6LbDQD2vtIMuk8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my humble opinion, I think the preference for P2MR vs P2TRv2 for users w= ould largely boil down to whether or not someone is a long-term holder, or = someone who actively makes frequent transactions on the network. On one hand, if I were a self-reliant long-term holder of significant asset= s (which I may or may not be), I would be reluctant to use P2TRv2 for this,= since the funds would always be fully exposed to CRQCs until such a time E= C spending is disabled by a third party, which may or may not happen in tim= e. On the other, if I were making frequent transactions on the network (which = I may or may not do), I would be reluctant to use P2MR for this due to the = additional transaction cost, which would be wasteful before CRQCs exist - a= nd especially considering that they might never exist. As such, unless someone were to come up with a different scheme that has th= e best of both worlds, I feel like the discussion should be more along the = lines of "one, or possibly both if it is beneficial" rather than "we have t= o pick just one no matter what". Personally, using the ideas Pieter Wuille presented in the other thread, my= preference would be to add both: - P2TRv2 using one or both of the Tripwire and Miner Lockdown triggers (P2T= Rv2-T / P2TRv2-ML / P2TRv2-T-ML) to emergency-disable EC spending, while st= ill leaving the ability to disable it with a soft fork, for frequent transa= ctors and people who trust miners to act responsibly. - P2MR (plain), with EC spending only disabled with a soft fork, for the se= lf-reliant holders who know (how) to not expose their EC public key and wan= t full control over their funds. This would leave EC spending available for P2MR while it is still in the "d= anger zone" and after it has been initially disabled for P2TRv2, but when/i= f EC spending is considered by the developers to be completely broken, a fo= llow-up soft fork would disable it for both address types. I feel like this should be worth the trade-offs of easier wallet fingerprin= ting as well as the increase in implementation complexity and long-term mai= ntenance cost - but then again, I'm not the one paying that cost, and the p= eople who will might disagree. -- Best,ArmchairCryptologist On Thursday, June 25th, 2026 at 12:35 AM, Anthony Derbidge wrote: > I agree with the core point that Bitcoin=E2=80=99s post-quantum transitio= n cannot rely primarily on self-reliance. If the migration requires most us= ers to understand Q-Day timing, keep EC spend paths secret, or react quickl= y under pressure, then it is unlikely to protect Bitcoin as a system. The s= afer 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 restrictive = post-quantum workflows, while consensus can still act when the risk becomes= concrete. Bitcoin mainnet should remain simple and conservative, while mor= e complex identity, recovery, coordination, and enhanced post-quantum workf= lows can exist in optional Bitcoin-aligned layers rather than the base laye= r. > > Systems such as Lightning and ProofnetBTC can experiment with those optio= nal workflows and recovery models while continuing to settle to Bitcoin, al= lowing innovation without requiring the Bitcoin mainnet itself to absorb th= at additional complexity. > > Best, > Anthony D. > > On Wed, Jun 24, 2026 at 3:50=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Dev= elopment 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 consensu= s >>> 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 v= ast >> majority of users have updated their workflows to keep said quantum vuln= erable >> 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= their 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 Bitc= oin >> today in response to a (still --at the time they need to migrate) specul= ative >> 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 therefor= e Option >> (2) is likewise implausible. >> >> Therefore i don't think the "Self-reliance" variation can result in a su= ccessful >> migration. >> >>> As far as I can see, only having P2TRv2 addresses would rule out the "s= elf-reliance" path here. >>> >>> Picking when Q-day will occur, either individually for determining >>> your own security posture, or collectively for organising a consensus >>> change seems very difficulty: it involves evaluating both complex state >>> of the art physics research, but also estimating the covert abilities >>> of national governments and the incentives to attack bitcoin prior to >>> revealing their capabilities. To me, that doesn't bode well for a smoot= h >>> and fast deployment of a consensus change in advance of problems occuri= ng. >> >> 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 at >> fully migrating large amounts of users is to provide them with a virtual= ly free >> way to opt into a future consensus-triggered migration. >> >> The follow-up step does not require predicting with precision the day on= which >> an attack would be set up, but to be done before a CRQC could realistica= lly >> threaten Bitcoin. Definitely not a piece of cake, but not infeasible. In= 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 la= te. >> >> Of course, if a full CRQC is built in secret, with no reliable informati= on about >> the progress getting out whatsoever, and subsequently starts attacking B= itcoin >> 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 mos= t >>> conscientious 1% of users make use of P2MR securely, that might secure = 10% >>> of funds, but having 90% of the bitcoin supply crash probably wouldn't = be >>> very valuable either. >> >> 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 m= ore >> concentrated sweeps (such as that of early, presumed-lost coins) *could*= cause >> severe price shocks without necessarily destroying confidence in the sys= tem >> itself. >> >>> > > Theorycrafting for a second here. It's reasonable to conjecture fee >>> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advan= tage >>> > > over P2TRv2 will yield significant savings for end-users in absolut= e >>> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes b= ecomes >>> > > 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 by >> providing a path for Bitcoin to survive it. We shouldn't take the risk f= or a >> certainty and shift the goal to designing the best possible PQ-Bitcoin. = 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 Q-da= y, >>> > 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 ti= me, >>> 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 def= inition, >> EC could be disabled from the get-go, Bitcoin's migration would spectacu= larly >> fail because very few users switched to the new output type, and it woul= d still >> be "timed perfectly". :) >> >> I would define "timed perfectly" as maximizing the number of migrated us= ers >> 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 materializ= es, 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 th= e >>> "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= users >> opting into a (full) migration to CRQC-safe workflows, this difference i= n costs >> is material. Especially since users would presumably need to opt in long= 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 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,= is >> precisely to avoid imposing on individual users the costs of treating th= eir >> 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 ty= pe. >> 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 o= ff if it >> does not. >> >>> > This focus on allowing individual users the ability to safeguard thei= r >>> > 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 enti= re >>> point of Bitcoin. :) >> >> Cherry-picking this part of Pieter's sentence does not do it justice. Of= course >> we all agree about this. But as he says in the part you left out, not ad= dressing >> this issue as a systemic one is exactly how we lose that property: "I'm = not >> worried about my own coins being stolen. I'm worried about (fear of) a C= RQC >> undermining trust in the currency as a whole, or through a fear-driven c= onsensus >> change the ecosystem destroying its own values beforehand." >> >>> having a consistent push that every single wallet/service that doesn't = deprecate every current >>> address type is a danger to the entire ecosystem, even absent widesprea= d agreement on when/if >>> Q-day will happen. Arguably that would be easier to agree on if the inc= remental cost of EC spend >>> paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is n= ear 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 wrote: >> >>> On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote: >>> > I want to first correct a potential misunderstanding here, because >>> > I realize the terms "Later" and "Never" aren't very descriptive. They >>> > are specifically about an expected and relied-upon expectation that a= n >>> > EC-disabling fork will happen that at least applies to the output typ= e >>> > itself, in time. "Later" is the expectation that such a disabling wil= l >>> > happen after the output type is introduced, but still in time (so, be= fore >>> > Q-day). Outputs without a strong expectation that their EC paths/opco= des >>> > will be disabled, or not in time, I classify under "Never". >>> >>> > I believe here you're instead arguing for P2MR ("Merkle-Never") >>> > over all "Later" options. That was my previous point: I think (solely= ) >>> > having "Never" output types like P2MR is just utterly insufficient fo= r >>> > any worthwhile migration. It's so incompatible with today's workflows >>> > that it either won't be adopted, or (possibly inadvertently) adopted >>> > in an insecure fashion. Yes, it gives people the option to safeguard >>> > their own coins, but to me that's disaster recovery territory - I thi= nk >>> > we ought to prioritize maximizing the chances for saving the currency >>> > as a whole in case Q-day comes, not a small subset of individual user= s' >>> > coins. P2MR (alone) doesn't really achieve much in that regard 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 general id= ea >>> is: >>> >>> 1) we create some new address types that allow post-quantum spending, b= ut >>> also allow efficient quantum-vulnerable spending that can be used prior >>> to Q-day >>> >>> 2) many people migrate to these new address types >>> >>> 3) Q-day arrives >>> >>> 4) all spending goes via the post-quantum paths, and everyone's funds a= re >>> safe >>> >>> There are three main variations to this, I think: >>> >>> Later-dominant: towards the end of (2) but prior to (3), the >>> quantum-vulnerable spend paths are disabled in a predictable, planned >>> manner, preventing coin theft, but not disrupting active usage >>> significantly (or not disrupting it any more than the proximity of >>> Q-day already is). >>> >>> Self-reliance: Q-day goes from maybe to definitely faster than consensu= s >>> changes can be coordinated, and the only reason people's funds remain >>> safe is that they can (and do) keep the quantum-vulnerable spend >>> paths secret. >>> >>> Disaster-recovery: neither the "predictable/planned consensus change" o= f >>> Later nor the "everyone takes responsiblity for their own funds" >>> works, and the only way to avoid a large percentage of bitcoin >>> becoming a reward for quantum research is to replace EC spend paths >>> with a ZK proof of knowledge of a BIP32 seed or similar, requiring >>> a hard fork. Such a hard fork would be certain to be controversial >>> ("why at this height: I received a payment five blocks after // >>> my funds were stolen by a quantum attacker five blocks earlier // >>> why are only BIP32 funds recoverable not scheme X"), but if no other >>> approach works, might still be the ultimately outcome. >>> >>> > So the point here was just: if you already accept the need for a "Lat= er" >>> > output type (=3D one with builtin-in EC disabling expected from the s= tart), >>> > P2TRv2 is preferable over P2MR+ED, because: >>> >>> As far as I can see, only having P2TRv2 addresses would rule out the >>> "self-reliance" path here. >>> >>> Picking when Q-day will occur, either individually for determining >>> your own security posture, or collectively for organising a consensus >>> change seems very difficulty: it involves evaluating both complex state >>> of the art physics research, but also estimating the covert abilities >>> of national governments and the incentives to attack bitcoin prior to >>> revealing their capabilities. To me, that doesn't bode well for a smoot= h >>> and fast deployment of a consensus change in advance of problems occuri= ng. >>> >>> It's possible that general carelessness on behalf of users would also >>> rule out the effectiveness of a self-reliance approach: if only the mos= t >>> conscientious 1% of users make use of P2MR securely, that might secure = 10% >>> of funds, but having 90% of the bitcoin supply crash probably wouldn't = be >>> very valuable either. But even then, that may make the "disaster-recove= ry" >>> approach less problematic, by ensuring the 1%/10% who were conscientiou= s >>> can avoid being part of the "my funds were stolen by a quantum attacker= " >>> contingent, eg. >>> >>> > > Theorycrafting for a second here. It's reasonable to conjecture fee >>> > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advan= tage >>> > > over P2TRv2 will yield significant savings for end-users in absolut= e >>> > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes b= ecomes >>> > > significant (100 sats per spend or more). >>> >>> I don't think that is the right way to look at. 8vb/input is about >>> an additional 14% today (vs a taproot key-path spend), but with the >>> post-quantum signatures we have available now that's likely to reduce >>> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B, >>> you're only getting an expected savings in fees / increase in block >>> capacity on that order of magnitude, ie: 1%-7%. That's nice to have, >>> for sure, but doesn't compare to introducing a new address type that >>> puts the PQ sigs in an extension block, or one that uses ZK proofs to >>> do cross-input or cross-transaction signature aggregation, eg. So a 32B >>> witness overhead for an unused/unusable key-path post-Q-day doesn't see= m >>> 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-da= y, >>> > 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 ti= me, >>> but for me "perfection" here means "no one who upgraded lost money via >>> quantum-related vulnerabilities". >>> >>> One reason I'm doubtful is that I think for some the "it looks inevitab= le" >>> threshold has already been crossed, eg: >>> >>> >> So let me attempt to partially fill the silence, similarly to what >>> >> Scott Aaronson did in his April 29 post. Given everything I know, >>> >> including scary non-public information, I now put the odds of qday b= y >>> >> 2032 at 50%. 10% by 2030. >>> >>> >> IMO a good target date for migration is 2029, roughly 3.5 years >>> >> out. 2029 happens to be the date selected by Google, Cloudflare, and >>> >> the Ethereum Foundation. >>> >>> https://x.com/drakefjustin/status/2061793725299224676 >>> >>> >> So, here it is: if quantum computers start breaking cryptography a >>> >> few years from now, don=E2=80=99t you dare come to this blog and tel= l me that >>> >> I failed to warn you. This post is your warning. Please start switch= ing >>> >> to quantum-resistant encryption, and urge your company or organizati= on >>> >> 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 >>> of introducing either P2MR or P2TRv2 (etc) approaches that don't also >>> introduce a quantum-safe spending path on day one. >>> >>> > First a meta-point here: the reason I like separating the discussion = into different dimensions than just "P2TRv2 vs P2MR" is because there are m= ore options than those two, and not every argument applies to the same sepa= ration into two classes. Let me list them explicitly here, roughly in decre= asing order of how strongly I feel about them: >>> > - We need at least a "Later" option for meaningful migration, i.e. P2= TRv2 or P2MR+ED. >>> > - Within the "Later" option, P2TRv2 is preferable. >>> > - A "Later" option benefits from being the only PQC migration strateg= y, making it a Schelling point. >>> >>> Correct me if I'm mistaken, but I think P2TRv2 is preferable only in th= e >>> "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 woul= d >>> increase the risk of loss involved with both the other approaches. (I >>> don't think P2TRv2 is meaningfully more private than P2MR in the way >>> taproot v1 is, as presumably you'd only adopt that address format if >>> you wanted to have a post-quantum script path) >>> >>> > > You'd have to convince everyone to deploy and then adopt P2TRv2 tod= ay under the public knowledge that it is insecure and their coins 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/al= l migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or= any "Never" output type) fundamentally requires many users to change their= workflows entirely. >>> >>> 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 presumabl= y >>> equal to "the day the bitcoin ecosystem has finally agreed that CRQCs >>> are inevitable". >>> >>> My (cynical?) view is the only people who will adopt either P2TRv2 or >>> P2MR prior to NoEC-day being schedule will be people who are willign >>> to use those features in a quantum-safe way -- that is, keeping their >>> EC pubkeys secret, and only revealing those EC pubkeys to spend them >>> immediately, prior to NoEC-day. In that view, the EC-spend-paths of suc= h >>> 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 simila= r. >>> >>> Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible >>> that lightning software could get an upgrade to generate post-quantum >>> signatures for channel commitments or HTLC claims, I just think it's >>> pretty unlikely that that will happen at a meaningful scale when everyo= ne >>> has much more immediate and less theoretical things to work on prior to >>> NoEC-day, especially when the efficiency/performance of such changes is >>> likely to be very low. >>> >>> > This focus on allowing individual users the ability to safeguard thei= r >>> > 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 enti= re >>> point of Bitcoin. :) >>> >>> > In either case, I consider anything that requires hardcoding >>> > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus >>> > rules (and only allowing those coins to survive) to be squarely in >>> > disaster-recovery land. It feels like embracing arbitrariness, and >>> > giving up on the permissionlessness that makes Bitcoin interesting - >>> > if the community shows it can get consensus on effectively burning >>> > coins except those that match a whitelist, it feels hard to maintain >>> > censorship-freeness as a value, even if the whitelist includes most o= f >>> > 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 recover= y >>> > scenarios to save what's left, after Q-day, if migration attempts wer= e >>> > unsuccessful. In such a setting, I think we're already in effectively= an >>> > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibl= y >>> > 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 th= e >>> "disaster-recovery" scenario above: the "quantum-safe" hard-fork varian= t >>> of bitcoin would be fairly described as a utxo-bootstrapped altcoin, >>> would compete in the market with the "quantum-unsafe" bitcoin that >>> existing nodes would continue to follow, and possibly there would be >>> many slightly varying such altcoins competing with each other, eg on >>> exactly what height the utxo snapshot was taken or what coins become >>> spendable. It would not be a fun time for holders of affected utxos. >>> >>> > My impression is that your approach is to have an answer for many >>> > possible futures, including ones where Q-day arrives within just a fe= w >>> > years. >>> >>> "The key of strategy... is not to choose a path to victory, but to choo= se >>> so that all paths lead to a victory." >>> >>> -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit >>> >>> > But optimizing for disaster-recovery also means reducing the >>> > chances of preserving Bitcoin as we know it in the scenarios where a >>> > successful migration is still possible. And if Q-day does arrive that >>> > soon, I don't see what we can do today that would preserve Bitcoin in >>> > a form we care about anyway. By accepting that, we can focus on the >>> > futures where our choices today can still materially improve the outc= ome. >>> >>> Preserving bitcoin as a personally-possessible inflation resistant >>> store of value seems both possible and worth caring about, even if othe= r >>> constraints means that many people can't afford to personally hold it >>> (and have to go through ETFs/exchanges/banks) and that it can't be used >>> for day-to-day transactions. Would be very disappointing if true, and >>> even given Q-day in a few years I expect we could do better than just >>> that, but it doesn't feel like a throw-in-the-towel event to me. >>> >>> > > Essentially yes though, I expect the majority of holders will proba= bly >>> > > migrate to PQ addresses via rescue protocols, either on Bitcoin or = a fork >>> > > thereof. Even if we can't come to consensus and deploy a new output= type, >>> > > we'll still be able to rescue most coins. It's just that we'd have = nowhere >>> > > to rescue them to, so we ought to make PQ wallets available soon, s= o 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 be= tter >>> >>> FWIW, that's my guess on how things would play out if the near-term Q-d= ay >>> timelines I've seen (ie, 2029 to 2035) match reality. I hope that's >>> pessimistic (either because the Q-day timelines are bad estimates, or >>> because migration happens in a more orderly fashion), but I guess we'll >>> see. I don't rate my ability to evaluate Q-day predictions very highly. >>> >>> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say. >>> >>> I'm not in a position to judge, but the google paper claims: >>> >>> "Indeed, if a leading quantum architecture encounters and overcomes >>> all its scaling challenges before producing a device able to >>> solve (for example) 32-bit ECDLP, then there may be little time >>> between the breaking of 32-bit ECDLP and the breaking of 256-bit >>> ECDLP. Furthermore, the community should not expect to see published >>> demonstrations of the most advanced quantum error-correction >>> architectures and quantum algorithms deployed to cryptanalytic >>> problems. Thus, a successful public demonstration of Shor=E2=80=99s >>> algorithm on a 32-bit elliptic curve should not be seen as a wake-up >>> call to adopt PQC as much as a potential signal that PQC adoption >>> has already failed." >>> >>> and places the required tiffoli gates and logical qubits for a 32-bit >>> break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100) >>> for 256-bit. >>> >>> > Of course, if you believe it's the only possible future, I understand >>> > you'd come to a different conclusion. But is it really? Do you think >>> > this isn't a plausible future: >>> >>> > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added to= o) 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 practi= cally all active users. >>> >>> I think it might be better to look at that scenario in a more fine-grai= ned >>> 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-pa= ths >>> via those outputs >>> 3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2= TRv2, >>> but EC spend paths continue to be what's used in practice. >>> 4) Some better PQ solutions become available, allowing cheap PQ-safe sp= end-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 pra= ctice" >>> path breaks, but everything is recoverable. >>> 5) Post-quantum approaches get even higher priority >>> >>> I'm skeptical of step 3 here; and would expect to see something more li= ke: >>> >>> 3') Only a small proportion of users (ie, the most conscientious/fearfu= l) >>> 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 to migra= te >>> to P2TRv2, but it mostly works. >>> >>> or >>> >>> 4'b) NoEC-day happens essentially at the same time as Q-day; coins get >>> stolen and we hit the disaster-recovery scenario. >>> >>> Perhaps the difference between (3') and (3) playing out in reality >>> is just having nearly everyone agree that the upgrade is essential, >>> and rather than leaving it to self-interest/market-dynamics, having a >>> consistent push that every single wallet/service that doesn't deprecate >>> every current address type is a danger to the entire ecosystem, even >>> absent widespread agreement on when/if Q-day will happen. Arguably that >>> would be easier to agree on if the incremental cost of EC spend paths >>> in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to >>> zero, rather than up to ~14% per input. >>> >>> Cheers, >>> aj >>> >> >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%2Bun= subscribe@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= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/CACja%3DNz%3DA2wV68MMBYcgOMDjwcXpKNQsptdP2NVqXske%3DONG6w%40mail.gmail.co= m. --=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/= 2UBm2dVIs3jNHvlZtgXA_7Pfa09T6bK0BBkpvEZUMV8CNgeOwpG87vmUZ9vEnn0TQIfag2uIbiV= iizuDaND9UljX9LdDqHYXgJhTlW7OGqs%3D%40protonmail.com. --b1=_4xlAhClERbHII96vMQidBB52R6LbDQD2vtIMuk8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my= humble opinion, I think the preference for P2MR vs P2TRv2 for users would = largely boil down to whether or not someone is a long-term holder, or someo= ne who actively makes frequent transactions on the network.

=
On one hand, if I were a self-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 always be fully exposed to CRQCs un= til 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 network (which I may or may not = do), I would be reluctant to use P2MR for this due to the additional transa= ction cost, which would be wasteful before CRQCs exist - and especially con= sidering that they might never exist.

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

Per= sonally, using the ideas Pieter Wuille= presented in the other thread, my preference would be to add both:<= /div>

- P2TRv2 using one or both of the Tripwire a= nd Miner Lockdown triggers (P2TRv2-T / P2TRv2-ML / P2TRv2-T-ML) to emergenc= y-disable EC spending, while still leaving the ability to disable it with a= soft fork, for frequent transactors and people who trust miners to act res= ponsibly.

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

This would leave E= C spending available for P2MR while it is still in the "danger zone" and af= ter it has been initially disabled for P2TRv2, but when/if EC spending is c= onsidered by the developers to be completely 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 finger= printing as well as the increase in implementation complexity and long-term= maintenance cost - but then again, I'm not the one paying that cost, and t= he people who will might disagree.

--=
Best,
ArmchairCryptologist=
=20
=20
=20

On Thursday, June 25th, 2026 at 12:35 AM, Anthony Derbidge <ader= b001@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 i= nto a future migration path without immediately adopting restrictive post-q= uantum workflows, while consensus can still act when the risk becomes concr= ete. Bitcoin mainnet should remain simple and conservative, while more comp= lex identity, recovery, coordination, and enhanced post-quantum workflows c= an exist in optional Bitcoin-aligned layers rather than the base layer.

=

Systems such as Lightning and ProofnetBTC can experiment with those opti= onal workflows and recovery models while continuing to settle to Bitcoin, allowing innovation without requiring the Bitcoin= mainnet itself to absorb that additional complexity.

Best,
Antho= ny D.


On Wed, Jun 24, 2026 at 3:50=E2=80=AFPM 'Ant= oine Poinsot' via Bitcoin Development Mailing List <bitcoindev@= 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 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 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" period;
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 result in a succe= ssful
migration.

> 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 smoo= th
> and fast deployment of a consensus change in advance of problems occur= ing.

Yes. P2TRv2 optimizes for the "Later dominant" path at the expense of the "self-reliance" path. I think this is good, because our best (only?) shot a= t
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 also<= br> > 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'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 conject= ure fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32 byt= e 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 reduce<= br> > 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 time= d
> > 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". By your defini= tion,
EC could be disabled from the get-go, Bitcoin's migration would spectacular= ly
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 migrated 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 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 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 strategies, is=
precisely to avoid imposing on individual users the costs of treating their=
public keys as secrets. P2TRv2 (compared to other "Later" options) also ens= ures
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 individual > users the ability to safeguard their coins" is pretty close to the ent= ire
> point of Bitcoin. :)

Cherry-picking this part of Pieter's sentence does not do it justice. Of co= urse
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'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'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 <aj@erisian.com.au> wrote:

> On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
> > I want to first correct a potential misunderstanding here, becaus= e
> > I realize the terms "Later" and "Never" aren'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".
>
> > I believe here you're instead arguing for P2MR ("Merkle-Never") > > over all "Later" options. That was my previous point: I think (so= lely)
> > having "Never" output types like P2MR is just utterly insufficien= t for
> > any worthwhile migration. It's so incompatible with today's workf= lows
> > that it either won't be adopted, or (possibly inadvertently) adop= ted
> > 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 regard 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 general i= dea
> 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 funds= 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 rema= in
> safe is that they can (and do) keep the quantum-vulnerable spend > paths secret.
>
> Disaster-recovery: neither the "predictable/planned consensus change"= of
> Later nor the "everyone takes responsiblity for their own funds" > works, and the only way to avoid a large percentage of bitcoin
> becoming a reward for quantum research is to replace EC spend paths=
> with a ZK proof of knowledge of a BIP32 seed or similar, requiring<= 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 othe= r
> 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 smoo= th
> and fast deployment of a consensus change in advance of problems occur= ing.
>
> It's possible that general carelessness on behalf of users would also<= br> > 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't= be
> very valuable either. But even then, that may make the "disaster-recov= ery"
> 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.
>
> > > Theorycrafting for a second here. It's reasonable to conject= ure fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32 byt= e 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 reduce<= br> > 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<= 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 se= em
> very relevant to me.
>
> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be time= d
> > 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 looks inevita= ble"
> 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 also<= br> > 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 because there a= re more options than those two, and not every argument applies to the same = separation into two classes. Let me list them explicitly here, roughly in d= ecreasing order of how strongly I feel about them:
> > - We need at least a "Later" option for meaningful migration, i.e= . P2TRv2 or P2MR+ED.
> > - Within the "Later" option, P2TRv2 is preferable.
> > - A "Later" option benefits from being the only PQC migration str= ategy, making it a Schelling point.
>
> 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<= br> > don't think P2TRv2 is meaningfully more private than P2MR in the way > taproot v1 is, as presumably you'd only adopt that address format if > you wanted to have a post-quantum script path)
>
> > > You'd have to convince everyone to deploy and then adopt P2T= Rv2 today under the public knowledge that it is insecure and their coins ar= e more likely to be stolen. That's a hard sell.
> >
> > > How does one pitch P2TRv2 to users? "It will be quantum secu= re one day we promise because everyone is incentivized to fix it later as B= itcoin will die if we don't."
> > >
> > > How do you pitch P2MR? "It's quantum secure if you use it co= rrectly."
> > To me, the pitch is "Bitcoin can only remain valuable if we mostl= y/all migrate." for both. P2TRv2 is just much easier to adopt, because P2MR= (or any "Never" output type) fundamentally requires many users to change t= heir workflows entirely.
>
> Let's call NoEC-day the earlier of activation of a soft-fork disabling=
> EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumab= ly
> equal to "the day the bitcoin ecosystem has finally agreed that CRQCs<= br> > 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 cheaper= "
> shortcut, they don't allow the funds to be used in lightning channels<= br> > 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's possibl= e
> 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 individual > users the ability to safeguard their coins" is pretty close to the ent= ire
> point of Bitcoin. :)
>
> > In either case, I consider anything that requires hardcoding
> > specific wallet designs (BIP32 or otherwise) into Bitcoin's conse= nsus
> > 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 attempts= were
> > unsuccessful. In such a setting, I think we're already in effecti= vely 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" 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. >
> > My impression is that your approach is to have an answer for many=
> > possible futures, including ones where Q-day arrives within just = a few
> > years.
>
> "The key of strategy... is not to choose a path to victory, but to cho= ose
> 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 Bitcoi= n 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<= br> > (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<= 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-term Q-= day
> timelines I've seen (ie, 2029 to 2035) match reality. I hope that's > pessimistic (either because the Q-day timelines are bad estimates, or<= br> > 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= .
>
> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>
> I'm not in a position to judge, but the google paper claims:
>
> "Indeed, if a leading quantum architecture encounters and overcomes=
> all its scaling challenges before producing a device able to
> solve (for example) 32-bit ECDLP, then there may be little time
> between the breaking of 32-bit ECDLP and the breaking of 256-bit > ECDLP. Furthermore, the community should not expect to see 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 unders= tand
> > you'd come to a different conclusion. But is it really? Do you th= ink
> > this isn't a plausible future:
>
> > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets adde= d too) gets introduced in the next few years, with hash-based PQC opcodes.<= br> > > - 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 more l= ike:
>
> 3') Only a small proportion of users (ie, the most conscientious/fea= rful)
> 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 to mi= grate
> to P2TRv2, but it mostly works.
>
> or
>
> 4'b) NoEC-day happens essentially at the same time as Q-day; coins g= et
> 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 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<= 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 "= 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/SHKHzyvg1Rr2E-CBLdgNEinhsn= dgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZe= VZiups%3D%40protonmail.com.

--
You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACj= a%3DNz%3DA2wV68MMBYcgOMDjwcXpKNQsptdP2NVqXske%3DONG6w%40mail.gmail.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/bitcoindev/= 2UBm2dVIs3jNHvlZtgXA_7Pfa09T6bK0BBkpvEZUMV8CNgeOwpG87vmUZ9vEnn0TQIfag2uIbiV= iizuDaND9UljX9LdDqHYXgJhTlW7OGqs%3D%40protonmail.com.
--b1=_4xlAhClERbHII96vMQidBB52R6LbDQD2vtIMuk8--