From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 24 Jun 2026 15:35:52 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wcWCB-000502-Ei for bitcoindev@gnusha.org; Wed, 24 Jun 2026 15:35:52 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-4410cdeeecbsf1820639fac.2 for ; Wed, 24 Jun 2026 15:35:47 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1782340539; cv=pass; d=google.com; s=arc-20240605; b=hoBEPpLvFKpCDRkVzwh2GhFmRcaopLDwwNHXvlWgW0oKVMUKC+OJyhhWmRpOSkQsVw r8VRE9pNvk5VnK1xBR/LkiyBsJedJv6LqlIRmmsoBO+5ojw5pSYuTB5J4WaaUsC9RJgG 52CXzYzziVuBxrcSEiNIORBvOndMr/Y6UzrB3uoqc//lrxgHyaiCqh/aiA8N2aDwqd// g7RTW66lQR8y0yIbwOJe5M1W5gnJ7gCH9dNtSnefmMF7TnUqtfnSysYUfB6Il41PiHkC OLEKh+JfAV7y6G4nT0A2WyohRnBZ6GdX9pwazJZZ72NKmnYXgSvMgd0fEQJjAKXHiw0C Ic7w== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=MgJytmV6Qdj4MoP4KNLenMxl4JZLmUndQP0aYcfXR3k=; fh=Uc028AwQA0Hxh1W6OEyP/Y5bpX9nl9jk5rLC8ijvXUo=; b=Hb+eScOuCGM2tHaXgsaUcf0rk4c2ha+58253oghQo7VVBA0pVCQVDQqpNXzMwSF51T V2SKsrlUXHISIKop0mrMhyx8AvkmKdogVrbr6ASbYQBG1WyAAYS8oGxdJFf6JG4JWdso QdaNh7gDn1IM3T2buvVA/NcfT5PcYAPrymRg/xIYKMDPCgEVJZfCHWo+0GBrSixM2nnF EtXM+lZv/CxfP+H/rx0IyJLSXuRDvmBxOh9ndr/fn0SDAzi/okApMWwV8KjtYuno/AD4 nW5U4+Yxdg1fny07GO41NyDHdxpfcPI1yhJRsSXDm8TSWsGI7gbMKCJpUxpYEDvzWFQs BrVg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=iMjouhs9; arc=pass (i=1); spf=pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=aderb001@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782340539; x=1782945339; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=MgJytmV6Qdj4MoP4KNLenMxl4JZLmUndQP0aYcfXR3k=; b=V041GmJ5gW7v2woD0nQXT5rcsbvTp2OQySt5B0YGyrcZSJ/emMzJ/VJ0t6oaA5JE1l 3wugy6r/QA9uqhz3ldu9ZOorfCSfWHvQa6aT2dHvV9EGJhOiUWKr/AmO3BTcij70nzLA licz45H2cCnDFPY8Jfhs3j3s7xiOTI59HgVPsE2sbppuGw8LBDqqzq2feUny+WVc6OJI o8CLDET7g4ovANftW3jBMl3iXvshd4P5F9MGbVmi7p2tiQNdp+LnrMDEc/LxFH9ho7V2 fqRosxWmR16AHhtUqXO3JeEbeCflTXqaw+4RI0LuONP9VNUMS7JfnEytqtSxIt+S450t cT9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782340539; x=1782945339; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MgJytmV6Qdj4MoP4KNLenMxl4JZLmUndQP0aYcfXR3k=; b=hD2Z3GfHVo+cc7Mw+2KQGEOxtb0uQMQmgyFY0Qtenoyr6GLH6WjqWvwaSkE4Y0Wrgh 94QqwxzUA9FAG0cq1K0fzQIowsSUTpGIZbH6QsgBktbUl3NO9U1L9vm/cdAqd6JJeeRk qTY68ev6cwzf22MoPgHj0qcH58mvJ+bFa9ql8l/aJty41VXnuuHwOMTSTm3RzHKmN4sh mJOc+t/QE2WG3h8EEcMBm6CKzPgEL1Xt7/eHwMf09pZFVcWd9/hwUJNW7FDwxDB9QAix 7vCNzdaD2or3Uq9j1X6dL678RMRT0tohV4SH/HX3HDHrEwfujYWTpFAg6iYa7Yh7cbIa HHYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782340539; x=1782945339; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=MgJytmV6Qdj4MoP4KNLenMxl4JZLmUndQP0aYcfXR3k=; b=iftJCwCeE16voNnamh41urTnQPlCnHeVsSGALmOoduxV4zac73Z86Bo93m+fUYtC79 YQ89M/FR7YdfHaSuoyseMwwUOHtpND19pEK0TqLlkrmE1UxwTxzVAsVeJhOaF0HVTad2 10zNE21d8+sE57t0vpS+xjBK4heQEzdrHGN/AinaL7/1nDDHPb7k0PvZSWaSvJMfW+eF m0uK5ps8SJPfewc8ioG2ZthNHnpfVKpZbhFZ4QZWP1tp1n6KCI5X3oaLuKGF0lAWd0rz YuVAcr3OuWrcGHauQj8yKrR7tLrddzMKfcrXBF8crz29/6sKMDJot9SbFMeKgFi/CjA0 IVag== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AHgh+RoiUpjzpXM2qk75tk9MfZhYGXAqvl+/kvD/yAJQyaNxkA7LnFLBWM11g0xZzDmT68S3DHY0Wli/IHEg@gnusha.org X-Gm-Message-State: AOJu0YydiSeIMrQDqS3luEvs8bijxy7X0uEIJM0CosAv3cu/jI28s4Gu CIsuuTBZ2+kgsjdBx820h/+M6z/68XxeAVsI9nwRsRD2I27wTYGiwJtU X-Received: by 2002:a05:6870:961d:b0:43d:1fcb:3dc7 with SMTP id 586e51a60fabf-447dc4711c5mr3940447fac.12.1782340538300; Wed, 24 Jun 2026 15:35:38 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdA4YwnXGTtUUa3n2SAz2jTqGP4QkP55Jr4tkYhVOzi+g==" Received: by 2002:a05:6870:8e15:b0:43d:b8f:a6db with SMTP id 586e51a60fabf-446dfb2777als4917809fac.1.-pod-prod-08-us; Wed, 24 Jun 2026 15:35:33 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9IOeDVgbiwjotoi/PpP+dMdAhWQB5daCoBOKRaM19Siho8zOFXKFCC7sLChuzNWLm0nnEEMoBHu2gB@googlegroups.com X-Received: by 2002:a05:6809:30f:10b0:48a:3a11:6228 with SMTP id 5614622812f47-49078f8817fmr2445683b6e.23.1782340533658; Wed, 24 Jun 2026 15:35:33 -0700 (PDT) Received: by 2002:a05:600c:2e55:b0:490:3d60:134 with SMTP id 5b1f17b1804b1-4925f6acce4ms5e9; Wed, 24 Jun 2026 15:01:13 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9wMmGPl0WLsAp094Pf+AJI+5I/cEFU1mTE6nGKgtdaEUeyzXH1zux8FG1vCowIyrN9R/EekjML4ygM@googlegroups.com X-Received: by 2002:a17:907:7e64:b0:bf4:189f:8812 with SMTP id a640c23a62f3a-c102eec42b7mr507379366b.7.1782338472032; Wed, 24 Jun 2026 15:01:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1782338472; cv=pass; d=google.com; s=arc-20260327; b=bxJT5ImOMmONQaIZhTYsneOSnJ9SYjIOq7Wexj7kins/OA6mS9vziPD9arnXcGWh1c wfnf9/XnfJnCpfkKUaNPUzcf6sviqIhIegg7mnsPEOWzp+UEI3KNuEJoo62GFvlkCpSG p4oRJLv91mxnQ2EqWVwYPMWK3yDwdWsy+ykd2pD2ZQFrzAAEQV5uv27EFeDdGvY6zYkz KNoKAymdT8IOaD6cTtCKMUcgjvmxZQansQASmPhyC4VrQ201jcs26z5IqHyKipdICzrR WeQa1mpy2D5tL8bKP06KuMVLLV3GwCC5C04CU31qU9oy0vejKo8sZv4CpNFRxYhUJbO2 Xr0g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=wFeUc/ZlxT48x0tbdSRUgn3d3lMOSirhsgcQmc+jlxw=; fh=t+naC8sNaTkS5VGYQ6L+QrTXMwvDtStu37lrcbSb2WY=; b=A0G7slJP+Ly8TVtsWzPtuUaM6g1wpKMHDNGZpg4SycG+6m2rmcNveYMauzl9Brl/CQ 2eTXge8qFp7D/0LxSHn1Wuzx1jQm89H5OxdpLfaFWdyq1NjlOWhKp55TKrMfCevCgAIC HZRuiuj4r+myuhz2FuWXTAgJ7fM1UnMPHYWxts7TJpJoxf0WgfTE98VyscdQkDNAnF8D G+scz2X5twHqnn7bsVxv1x5Nd14eUuX1z3bdzf40RrYqsMfCVcWEuezjP8HwtcSGJThO bZwB8apTqunBcUTsU55MHMHs8ekILrsp9k6YrML6qUwMuKsWK9bAHlhgfFqamIUaeDwq oKeg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=iMjouhs9; arc=pass (i=1); spf=pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=aderb001@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com. [2a00:1450:4864:20::632]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-c11fbd5013asi1674866b.4.2026.06.24.15.01.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2026 15:01:12 -0700 (PDT) Received-SPF: pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) client-ip=2a00:1450:4864:20::632; Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-c029505b389so57786166b.1 for ; Wed, 24 Jun 2026 15:01:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782338471; cv=none; d=google.com; s=arc-20240605; b=WuFpRmobI+n5KFnIy2ECFEq//LKjH0xmEiBNSLTZTfSDqe2FDnAMvJsC23/0/vmLfu wU4edQm2bGVwGt/XNb0DA+BKFkxQAgOpQsaMEoatQ9WmzekH1pAkHG1CymMrSU5lYPsQ nkR88WnJr5AuRGdt0SYrbvvUV7/U0BXtAJE+A9UT49SSrYRKUQMZctky/uyNtMzfor37 9IF1qSJohyM2Yy5+PEqbIdaaIKTqQimeRv+XTaXPR+FKjFsQTOjHigmMu+zlYUe+9+vg r2Nc2sYmyIdhTlkNyx/OtC6N+FUPOe4FNEeZPbs5ghSHZ2eUf6W2OMZxAK6XHhZEtGGK xuyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=wFeUc/ZlxT48x0tbdSRUgn3d3lMOSirhsgcQmc+jlxw=; fh=t+naC8sNaTkS5VGYQ6L+QrTXMwvDtStu37lrcbSb2WY=; b=KZ1sBmB0Kk+fEDfGY/OU2WkzNcTAO4tvBwdGOa6ic8GFcTW1nxsUAv8644eaYr4CcV z3B2gqPuOlTpT+vmxHARr+fsqbQZ/i8KPUDEVFh4ykx9F4gvxQoa0p1guyflsfiXPB9O k4Styp80GTuHCIORWU6xRM5SsFySuAo2StpwfAJRCxXjhyLNq7pswBtoVY859ovVACNB 6LRMdsuVheN+s6mkrpiR2zJJeo5oIT8xxdCLLw66psVd00vhNmfKIKqmA7ll1yuz2SGK CQNKFs8h0aKUILZByTkEd5uPQNo3pvQB75TrAqZjPcVfhPayPrxYAOxG4N2F7SonoGUq pJCg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ/2HliGBLh31muJq4z3afY0x2P/gPPjoW4zyZt8AppW/Os+WHWQSgTrMSYKBJqjST08KJZs2qDxSwcG@googlegroups.com X-Gm-Gg: AfdE7ckuI95T1cZNitWzGn+tr8Kcoh4anZuHaBp/hgMTKth6qIVRkhCmOmO8nDZ1r46 gxRs2xGM1ahfW3Cc4Mx2WQxBrImBlYF3eRp9o9I9GbxhAIZWLytqrYdiHNNB1bxfxt/uirzEcIE m4op4iEzR0sgaP5fGmOZpCWa0NnUZI+IgpIXRvJay4tUtaVw8VsGio5/jenGtKeOZki553Uaapw WhcAb3jbM/bIwXLlTH9KQHZ+KXS9MVz+VcvipH3dNl+btqALOmHxbt5OATXg4G8xG8odp0IxvYb AV0tHxN4RYdVCz/pqg5HR55pMBPuYFQkLZ+X+59jNDgkX+6Y+IXP6YBjzdtkXIqZvLIb0tn2RFs LYDym/FY/zw2JCJ2e9mFO6hixBw== X-Received: by 2002:a17:907:960f:b0:c0f:d9c7:6627 with SMTP id a640c23a62f3a-c11f8e6d194mr149826566b.20.1782338470769; Wed, 24 Jun 2026 15:01:10 -0700 (PDT) MIME-Version: 1.0 References: <_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM=@wuille.net> <81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg=@wuille.net> In-Reply-To: From: Anthony Derbidge Date: Wed, 24 Jun 2026 16:00:59 -0600 X-Gm-Features: AVVi8CeEqybTDMpkVyF3AUXTrrfjUqVJQCso-GF-M-fvywo1msVX080VzBYdLGE Message-ID: Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR To: Antoine Poinsot Cc: Anthony Towns , Pieter Wuille , conduition , "bitcoindev@googlegroups.com" Content-Type: multipart/alternative; boundary="0000000000006b7b0306550703f7" X-Original-Sender: aderb001@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=iMjouhs9; arc=pass (i=1); spf=pass (google.com: domain of aderb001@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=aderb001@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --0000000000006b7b0306550703f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 protect 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 restrictive post-quantum workflows, while consensus can still act when the risk becomes concrete. Bitcoin mainnet should remain simple and conservative, while more complex identity, recovery, coordination, and enhanced post-quantum workflows can exist in optional Bitcoin-aligned layers rather than the base layer. Systems such as Lightning and ProofnetBTC can experiment with those optional workflows and recovery models while continuing to settle to Bitcoi= n, allowing innovation without requiring the Bitcoin mainnet itself to absorb that additional complexity. Best, Anthony D. On Wed, Jun 24, 2026 at 3:50=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Devel= opment 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 va= st > majority of users have updated their workflows to keep said quantum > 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 > 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 Bitco= in > today in response to a (still --at the time they need to migrate) > speculative > 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 > Option > (2) is likewise implausible. > > Therefore i don't think the "Self-reliance" variation can result in a > successful > 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 > > 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 > occuring. > > 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 > at > fully migrating large amounts of users is to provide them with a virtuall= y > 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 realistical= ly > 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 lat= e. > > Of course, if a full CRQC is built in secret, with no reliable informatio= n > about > the progress getting out whatsoever, and subsequently starts attacking > Bitcoin > overnight, then this migration strategy would fail. But so would any othe= r > 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 th= e primary > metric we should optimize for is the share of users at risk. Widespread, > indiscriminate theft would fatally undermine trust in Bitcoin, whereas mo= re > concentrated sweeps (such as that of early, presumed-lost coins) *could* > cause > severe price shocks without necessarily destroying confidence in the syst= em > 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 > advantage > > > > 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 > 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 materializes > by > providing a path for Bitcoin to survive it. We shouldn't take the risk fo= r > 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 > 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 > definition, > EC could be disabled from the get-go, Bitcoin's migration would > spectacularly > fail because very few users switched to the new output type, and it would > still > be "timed perfectly". :) > > I would define "timed perfectly" as maximizing the number of migrated use= rs > 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 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 in > 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, would > treat > 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 the= ir > 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 typ= e. > 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 of= f > 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 > addressing > this issue as a systemic one is exactly how we lose that property: "I'm n= ot > worried about my own coins being stolen. I'm worried about (fear of) a CR= QC > undermining trust in the currency as a whole, or through a fear-driven > consensus > 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 > incremental cost of EC spend > > paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is > near to zero, rather than up > > to ~14% per input. > > Yes, that's essentially the case for P2TRv2. > > Best, > Antoine > > > > On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns > 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, > before > > > Q-day). Outputs without a strong expectation that their EC > paths/opcodes > > > will be disabled, or not in time, I classify under "Never". > > > > > I believe here you're instead arguing for P2MR ("Merkle-Never") > > > over all "Later" options. That was my previous point: I think (solely= ) > > > having "Never" output types like P2MR is just utterly insufficient 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, > 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, plann= ed > > 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 consens= us > > changes can be coordinated, and the only reason people's funds remai= n > > safe is that they can (and do) keep the quantum-vulnerable spend > > paths secret. > > > > Disaster-recovery: neither the "predictable/planned consensus change" = of > > Later nor the "everyone takes responsiblity for their own funds" > > works, and the only way to avoid a large percentage of bitcoin > > becoming a reward for quantum research is to replace EC spend paths > > with a ZK proof of knowledge of a BIP32 seed or similar, requiring > > a hard fork. Such a hard fork would be certain to be controversial > > ("why at this height: I received a payment five blocks after // > > my funds were stolen by a quantum attacker five blocks earlier // > > why are only BIP32 funds recoverable not scheme X"), but if no other > > approach works, might still be the ultimately outcome. > > > > > So the point here was just: if you already accept the need for a > "Later" > > > output type (=3D one with builtin-in EC disabling expected from the > start), > > > P2TRv2 is preferable over P2MR+ED, because: > > > > As far as I can see, only having P2TRv2 addresses would rule out the > > "self-reliance" path here. > > > > Picking when Q-day will occur, either individually for determining > > your own security posture, or collectively for organising a consensus > > change seems very difficulty: it involves evaluating both complex state > > of the art physics research, but also estimating the covert abilities > > of national governments and the incentives to attack bitcoin prior to > > revealing their capabilities. To me, that doesn't bode well for a smoot= h > > and fast deployment of a consensus change in advance of problems > occuring. > > > > 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-recovery" > > 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 > advantage > > > > 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 > becomes > > > > significant (100 sats per spend or more). > > > > I don't think that is the right way to look at. 8vb/input is about > > an additional 14% today (vs a taproot key-path spend), but with the > > post-quantum signatures we have available now that's likely to reduce > > to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B, > > you're only getting an expected savings in fees / increase in block > > capacity on that order of magnitude, ie: 1%-7%. That's nice to have, > > for sure, but doesn't compare to introducing a new address type that > > puts the PQ sigs in an extension block, or one that uses ZK proofs to > > do cross-input or cross-transaction signature aggregation, eg. So a 32B > > witness overhead for an unused/unusable key-path post-Q-day doesn't 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 > time, > > 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 > 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 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 > switching > > >> 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 > 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 > decreasing 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 > strategy, 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 > today 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 Bitcoi= n > 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 thei= r > 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 > outcome. > > > > 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 > probably > > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or = a > fork > > > > thereof. Even if we can't come to consensus and deploy a new output > type, > > > > we'll still be able to rescue most coins. It's just that we'd have > nowhere > > > > 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 > better > > > > 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 > too) gets introduced in the next few years, with hash-based PQC opcodes. > > > - Over the course of the next decade or so, it gets adopted by > practically all active users. > > > > I think it might be better to look at that scenario in a more > fine-grained > > 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 > 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 to > migrate > > to P2TRv2, but it mostly works. > > > > or > > > > 4'b) NoEC-day happens essentially at the same time as Q-day; coins ge= t > > 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 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/bitcoindev/SHKHzyvg1Rr2E-CBLdgNEinhsndg= Xog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsBrTgumAVwsZPHHnwrx7FcpZeVZ= iups%3D%40protonmail.com > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CACja%3DNz%3DA2wV68MMBYcgOMDjwcXpKNQsptdP2NVqXske%3DONG6w%40mail.gmail.com. --0000000000006b7b0306550703f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

That is why a &q= uot;Later" style strategy seems compelling: ordinary users can opt int= o a future migration path without immediately adopting restrictive post-qua= ntum workflows, while consensus can still act when the risk becomes concret= e. Bitcoin mainnet should remain simple and conservative, while more comple= x identity, recovery, coordination, and enhanced post-quantum workflows can= exist in optional Bitcoin-aligned layers rather than the base layer.

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

Best,
Anthony D.<= /p>

On Wed, Jun 24, 2026 at 3:50=E2=80=AFPM 'Antoi= ne 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
>=C2=A0 changes can be coordinated, and the only reason people's fun= ds remain
>=C2=A0 safe is that they can (and do) keep the quantum-vulnerable spend=
>=C2=A0 paths secret.

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

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

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

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

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

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

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

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

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

> It's possible that general carelessness on behalf of users would a= lso
> rule out the effectiveness of a self-reliance approach: if only the mo= st
> conscientious 1% of users make use of P2MR securely, that might secure= 10%
> of funds, but having 90% of the bitcoin supply crash probably wouldn&#= 39;t be
> very valuable either.

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

> > > Theorycrafting for a second here. It's reasonable to con= jecture fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32= byte advantage
> > > over P2TRv2 will yield significant savings for end-users in = absolute
> > > terms. If fee rates inflate 10x higher after Q-day, then 8 v= bytes becomes
> > > significant (100 sats per spend or more).
>
> I don't think that is the right way to look at. 8vb/input is about=
> an additional 14% today (vs a taproot key-path spend), but with the > post-quantum signatures we have available now that's likely to red= uce
> to ~7% (SHRINCS) or ~1% (winternitz).

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

> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be = timed
> > perfectly. The expectation should be just that it happens before = Q-day,
> > and when it looks inevitable or the fear about that is large enou= gh.
>
> FWIW, I would define "timed perfectly" precisely as "EC= disabling
> fork happens before Q-day". Maybe allowing some additional months= of
> EC-efficiency would be a win while not taking out too much migration t= ime,
> but for me "perfection" here means "no one who upgraded= lost money via
> quantum-related vulnerabilities".

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

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

> Correct me if I'm mistaken, but I think P2TRv2 is preferable only = in the
> "Later-dominant" scenario, and only to the degree that it= 9;s slightly
> cheaper prior to Q-day.

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

> My (cynical?) view is the only people who will adopt either P2TRv2 or<= br> > P2MR prior to NoEC-day being schedule will be people who are willign > to use those features in a quantum-safe way -- that is, keeping their<= br> > EC pubkeys secret, and only revealing those EC pubkeys to spend them > immediately, prior to NoEC-day.

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

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

> > This focus on allowing individual users the ability to safeguard = their
> > coins just feels like a red herring: [...]
>
> While I appreciate your point, I also feel that "allowing individ= ual
> users the ability to safeguard their coins" is pretty close to th= e entire
> point of Bitcoin. :)

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

> having a consistent push that every single wallet/service that doesn&#= 39;t deprecate every current
> address type is a danger to the entire ecosystem, even absent widespre= ad agreement on when/if
> Q-day will happen.=C2=A0 Arguably that would be easier to agree on if = the incremental cost of EC spend
> paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is = near to zero, rather than up
> to ~14% per input.

Yes, that's essentially the case for P2TRv2.

Best,
Antoine



On Thursday, June 18th, 2026 at 1:09 AM, Anthony Towns <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&= #39;t very descriptive. They
> > are specifically about an expected and relied-upon expectation th= at an
> > EC-disabling fork will happen that at least applies to the output= type
> > itself, in time. "Later" is the expectation that such a= disabling will
> > happen after the output type is introduced, but still in time (so= , before
> > Q-day). Outputs without a strong expectation that their EC paths/= opcodes
> > will be disabled, or not in time, I classify under "Never&qu= ot;.
>
> > I believe here you're instead arguing for P2MR ("Merkle-= Never")
> > over all "Later" options. That was my previous point: I= think (solely)
> > having "Never" output types like P2MR is just utterly i= nsufficient for
> > any worthwhile migration. It's so incompatible with today'= ;s workflows
> > that it either won't be adopted, or (possibly inadvertently) = adopted
> > in an insecure fashion. Yes, it gives people the option to safegu= ard
> > their own coins, but to me that's disaster recovery territory= - I think
> > we ought to prioritize maximizing the chances for saving the curr= ency
> > as a whole in case Q-day comes, not a small subset of individual = users'
> > coins. P2MR (alone) doesn't really achieve much in that regar= d in my view,
> > thus we at least need something of the "Later" class in= addition.
>
> I'm not sure I follow/agree with the logic here. I think the gener= al idea
> is:
>
>=C2=A0 1) we create some new address types that allow post-quantum spen= ding, but
>=C2=A0 =C2=A0 =C2=A0also allow efficient quantum-vulnerable spending th= at can be used prior
>=C2=A0 =C2=A0 =C2=A0to Q-day
>
>=C2=A0 2) many people migrate to these new address types
>
>=C2=A0 3) Q-day arrives
>
>=C2=A0 4) all spending goes via the post-quantum paths, and everyone= 9;s funds are
>=C2=A0 =C2=A0 =C2=A0safe
>
> There are three main variations to this, I think:
>
>=C2=A0 Later-dominant: towards the end of (2) but prior to (3), the
>=C2=A0 =C2=A0 =C2=A0quantum-vulnerable spend paths are disabled in a pr= edictable, planned
>=C2=A0 =C2=A0 =C2=A0manner, preventing coin theft, but not disrupting a= ctive usage
>=C2=A0 =C2=A0 =C2=A0significantly (or not disrupting it any more than t= he proximity of
>=C2=A0 =C2=A0 =C2=A0Q-day already is).
>
>=C2=A0 Self-reliance: Q-day goes from maybe to definitely faster than c= onsensus
>=C2=A0 =C2=A0 changes can be coordinated, and the only reason people= 9;s funds remain
>=C2=A0 =C2=A0 safe is that they can (and do) keep the quantum-vulnerabl= e spend
>=C2=A0 =C2=A0 paths secret.
>
>=C2=A0 Disaster-recovery: neither the "predictable/planned consens= us change" of
>=C2=A0 =C2=A0 Later nor the "everyone takes responsiblity for thei= r own funds"
>=C2=A0 =C2=A0 works, and the only way to avoid a large percentage of bi= tcoin
>=C2=A0 =C2=A0 becoming a reward for quantum research is to replace EC s= pend paths
>=C2=A0 =C2=A0 with a ZK proof of knowledge of a BIP32 seed or similar, = requiring
>=C2=A0 =C2=A0 a hard fork.=C2=A0 Such a hard fork would be certain to b= e controversial
>=C2=A0 =C2=A0 ("why at this height: I received a payment five bloc= ks after //
>=C2=A0 =C2=A0 my funds were stolen by a quantum attacker five blocks ea= rlier //
>=C2=A0 =C2=A0 why are only BIP32 funds recoverable not scheme X"),= but if no other
>=C2=A0 =C2=A0 approach works, might still be the ultimately outcome. >
> > So the point here was just: if you already accept the need for a = "Later"
> > output type (=3D one with builtin-in EC disabling expected from t= he start),
> > P2TRv2 is preferable over P2MR+ED, because:
>
> As far as I can see, only having P2TRv2 addresses would rule out the > "self-reliance" path here.
>
> Picking when Q-day will occur, either individually for determining
> your own security posture, or collectively for organising a consensus<= br> > change seems very difficulty: it involves evaluating both complex stat= e
> of the art physics research, but also estimating the covert abilities<= br> > of national governments and the incentives to attack bitcoin prior to<= br> > revealing their capabilities. To me, that doesn't bode well for a = smooth
> and fast deployment of a consensus change in advance of problems occur= ing.
>
> It's possible that general carelessness on behalf of users would a= lso
> rule out the effectiveness of a self-reliance approach: if only the mo= st
> conscientious 1% of users make use of P2MR securely, that might secure= 10%
> of funds, but having 90% of the bitcoin supply crash probably wouldn&#= 39;t be
> very valuable either. But even then, that may make the "disaster-= recovery"
> approach less problematic, by ensuring the 1%/10% who were conscientio= us
> can avoid being part of the "my funds were stolen by a quantum at= tacker"
> contingent, eg.
>
> > > Theorycrafting for a second here. It's reasonable to con= jecture fee
> > > rates will be much higher post-Q-day, and thus P2MR's 32= byte advantage
> > > over P2TRv2 will yield significant savings for end-users in = absolute
> > > terms. If fee rates inflate 10x higher after Q-day, then 8 v= bytes becomes
> > > significant (100 sats per spend or more).
>
> I don't think that is the right way to look at. 8vb/input is about=
> an additional 14% today (vs a taproot key-path spend), but with the > post-quantum signatures we have available now that's likely to red= uce
> to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,=
> you're only getting an expected savings in fees / increase in bloc= k
> capacity on that order of magnitude, ie: 1%-7%. That's nice to hav= e,
> for sure, but doesn't compare to introducing a new address type th= at
> puts the PQ sigs in an extension block, or one that uses ZK proofs to<= br> > do cross-input or cross-transaction signature aggregation, eg. So a 32= B
> witness overhead for an unused/unusable key-path post-Q-day doesn'= t seem
> very relevant to me.
>
> > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be = timed
> > perfectly. The expectation should be just that it happens before = Q-day,
> > and when it looks inevitable or the fear about that is large enou= gh.
>
> FWIW, I would define "timed perfectly" precisely as "EC= disabling
> fork happens before Q-day". Maybe allowing some additional months= of
> EC-efficiency would be a win while not taking out too much migration t= ime,
> but for me "perfection" here means "no one who upgraded= lost money via
> quantum-related vulnerabilities".
>
> One reason I'm doubtful is that I think for some the "it look= s inevitable"
> threshold has already been crossed, eg:
>
> >> So let me attempt to partially fill the silence, similarly to= what
> >> Scott Aaronson did in his April 29 post. Given everything I k= now,
> >> including scary non-public information, I now put the odds of= qday by
> >> 2032 at 50%. 10% by 2030.
>
> >> IMO a good target date for migration is 2029, roughly 3.5 yea= rs
> >> out. 2029 happens to be the date selected by Google, Cloudfla= re, and
> >> the Ethereum Foundation.
>
> https://x.com/drakefjustin/status/2061793= 725299224676
>
> >> 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."
>
>=C2=A0 -- https://tvtropes.org/pmwiki/p= mwiki.php/Main/XanatosGambit
>
> > But optimizing for disaster-recovery also means reducing the
> > chances of preserving Bitcoin as we know it in the scenarios wher= e a
> > successful migration is still possible. And if Q-day does arrive = that
> > soon, I don't see what we can do today that would preserve Bi= tcoin in
> > a form we care about anyway. By accepting that, we can focus on t= he
> > futures where our choices today can still materially improve the = outcome.
>
> Preserving bitcoin as a personally-possessible inflation resistant
> store of value seems both possible and worth caring about, even if oth= er
> constraints means that many people can't afford to personally hold= it
> (and have to go through ETFs/exchanges/banks) and that it can't be= used
> for day-to-day transactions. Would be very disappointing if true, and<= br> > even given Q-day in a few years I expect we could do better than just<= br> > that, but it doesn't feel like a throw-in-the-towel event to me. >
> > > Essentially yes though, I expect the majority of holders wil= l probably
> > > migrate to PQ addresses via rescue protocols, either on Bitc= oin or a fork
> > > thereof. Even if we can't come to consensus and deploy a= new output type,
> > > we'll still be able to rescue most coins. It's just = that we'd have nowhere
> > > to rescue them to, so we ought to make PQ wallets available = soon, so we're
> > > not in a rush to build them later when we need them. If a PQ= wallet can
> > > use cheap EC signatures while they're still trustworthy,= all the better
>
> FWIW, that's my guess on how things would play out if the near-ter= m Q-day
> timelines I've seen (ie, 2029 to 2035) match reality. I hope that&= #39;s
> pessimistic (either because the Q-day timelines are bad estimates, or<= br> > because migration happens in a more orderly fashion), but I guess we&#= 39;ll
> see. I don't rate my ability to evaluate Q-day predictions very hi= ghly.
>
> > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
>
> I'm not in a position to judge, but the google paper claims:
>
>=C2=A0 =C2=A0 "Indeed, if a leading quantum architecture encounter= s and overcomes
>=C2=A0 =C2=A0 all its scaling challenges before producing a device able= to
>=C2=A0 =C2=A0 solve (for example) 32-bit ECDLP, then there may be littl= e time
>=C2=A0 =C2=A0 between the breaking of 32-bit ECDLP and the breaking of = 256-bit
>=C2=A0 =C2=A0 ECDLP. Furthermore, the community should not expect to se= e published
>=C2=A0 =C2=A0 demonstrations of the most advanced quantum error-correct= ion
>=C2=A0 =C2=A0 architectures and quantum algorithms deployed to cryptana= lytic
>=C2=A0 =C2=A0 problems. Thus, a successful public demonstration of Shor= =E2=80=99s
>=C2=A0 =C2=A0 algorithm on a 32-bit elliptic curve should not be seen a= s a wake-up
>=C2=A0 =C2=A0 call to adopt PQC as much as a potential signal that PQC = adoption
>=C2=A0 =C2=A0 has already failed."
>
> and places the required tiffoli gates and logical qubits for a 32-bit<= br> > break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100) > for 256-bit.
>
> > Of course, if you believe it's the only possible future, I un= derstand
> > you'd come to a different conclusion. But is it really? Do yo= u think
> > this isn't a plausible future:
>
> > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets = added too) gets introduced in the next few years, with hash-based PQC opcod= es.
> > - Over the course of the next decade or so, it gets adopted by pr= actically all active users.
>
> I think it might be better to look at that scenario in a more fine-gra= ined
> way? I think your "Late-ish" scenario is:
>
>=C2=A0 =C2=A01) P2TRv2 (or whatever) is introduced
>=C2=A0 =C2=A02) Some PQ opcodes get enabled, allowing expensive but PQ-= safe spend-paths
>=C2=A0 =C2=A0 =C2=A0 via those outputs
>=C2=A0 =C2=A03) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in= favour of P2TRv2,
>=C2=A0 =C2=A0 =C2=A0 but EC spend paths continue to be what's used = in practice.
>=C2=A0 =C2=A04) Some better PQ solutions become available, allowing che= ap PQ-safe spend-paths
>=C2=A0 =C2=A05) Everyone switches from EC paths to the new PQ paths. >=C2=A0 =C2=A06) NoEC-day happens, but no one is impacted.
>
> I think your "Soon-ish" scenario differs as of step (4):
>
>=C2=A0 =C2=A04) NoEC-day happens. Massive disruption because the "= what's used in practice"
>=C2=A0 =C2=A0 =C2=A0 path breaks, but everything is recoverable.
>=C2=A0 =C2=A05) Post-quantum approaches get even higher priority
>
> I'm skeptical of step 3 here; and would expect to see something mo= re like:
>
>=C2=A0 =C2=A03') Only a small proportion of users (ie, the most con= scientious/fearful)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0switch to P2TRv2 with most preferring to sti= ck with what works
>
> That has no real impact on the Late-ish scenario, but changes the Soon= -ish
> scenario to either:
>
>=C2=A0 =C2=A04'a) NoEC-day happens substantially before Q-day; peop= le hurry to migrate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 to P2TRv2, but it mostly works.
>
> or
>
>=C2=A0 =C2=A04'b) NoEC-day happens essentially at the same time as = Q-day; coins get
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 stolen and we hit the disaster-recovery sce= nario.
>
> Perhaps the difference between (3') and (3) playing out in reality=
> is just having nearly everyone agree that the upgrade is essential, > and rather than leaving it to self-interest/market-dynamics, having a<= br> > consistent push that every single wallet/service that doesn't depr= ecate
> every current address type is a danger to the entire ecosystem, even > absent widespread agreement on when/if Q-day will happen. Arguably tha= t
> would be easier to agree on if the incremental cost of EC spend paths<= br> > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near t= o
> zero, rather than up to ~14% per input.
>
> Cheers,
> aj
>

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/SHK= Hzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSqjsB= rTgumAVwsZPHHnwrx7FcpZeVZiups%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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.co= m/d/msgid/bitcoindev/CACja%3DNz%3DA2wV68MMBYcgOMDjwcXpKNQsptdP2NVqXske%3DON= G6w%40mail.gmail.com.
--0000000000006b7b0306550703f7--