From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 24 Jun 2026 14:50:16 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wcVU6-00044t-9X for bitcoindev@gnusha.org; Wed, 24 Jun 2026 14:50:15 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-4474dd4f31dsf1951348fac.0 for ; Wed, 24 Jun 2026 14:50:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1782337808; cv=pass; d=google.com; s=arc-20240605; b=KK+HctolEfiXmOg6AMk0soP3RUQ7u4pfReO44Z6m6TXDQ7JofCcyfr0e1TCvbM3j24 Wl3tJRsFKQwSQyRI3YkVDi/W6JMsCIUa3HwWt6VIFIyVJixOnRaiDki+xbFQVgdAeGFa KDN6RIJDqSAJOh4sQTNGfo2IjT7k695LcaxNV+6tO6ooaHWtLDPcS4Y+t8zgFZnviKKi 5op/kvpDARPCYHlceeGi1xK7o6WyS3JtfHoCINLMZkMLVHcBx6DJzbu/es69QZPAvT1y rQQ0WqQMBcbf+7hKnohJI3vbgBooNSpJZzGGIqWUdHBwfQ+RXbih7X4VZvbXLvNVVbNC zrxw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=q+w14qiyHW1dKT3qPkL1rTYanRlE/p7GhpzeJxuYEAw=; fh=YZmd/8mjckOmCcLm+myIEQqM/EMIfvCVZKQZFH+OoiU=; b=kprrdzg14/FnejrbtUHdZL77gAQrgSVIizla01SffEvfLsKTT/d+g0Rfg9yWbVC0Or pflEXY/6IZ0vwpPY49ftj8qSG4wB33DliyKQv7RMHPDZe5JUyPG5/CRTAXCJFoZDrifT oDDQmuxFRVJNaBEeHnTRfZv1/rME/jOHvDyixqoqMumR7viWe+vZOMs+k8QnJmqZfbdu 9gPMTvMkl0xLKYMjcDU1HAU+LmuAoPKwtM0j10wYQO5r2xyTx40399OKAaXCnIF6/k1W KUC/icu3i8WMGnb7geM/Gqqj0eLphPsPuLaWQmc3Ibstt2R7yLhg1OM+o8mNy1OCHOkk iaww==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="QYo/rLjx"; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) smtp.mailfrom=darosior@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=1782337808; x=1782942608; 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 :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=q+w14qiyHW1dKT3qPkL1rTYanRlE/p7GhpzeJxuYEAw=; b=XP+ss8fdVh4q5RV4MewAJnVvEyTqnQQ10LKHT4w1tMYV/wEImQGYULUohzIZESaPGk bciNmGu1YzbbcY9dTqM1UFwWEHOkcW/OSe87PLIn9tN+H1PXiPKrTqhc8Weqw4y6NMtP Uh2xVsYI+nquA8BIepZvbZGV6KtGI7ZqmZJPSJnlXmEk7MHSeD6YduuHyy45cg3EScXI H71iTy5VXpvzPtbcA3F2SdVqYYvYMSC1EwzIjXES0c//GQ/00Vd/376qTZLxjw5Uss8P T//QI/LhHubJK+fbQJNQmFY+BC+LpYoPQsrh1DhE8TINzN7+SvkfMUoHg6+uAUMqadGv 5WfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782337808; x=1782942608; 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 :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=q+w14qiyHW1dKT3qPkL1rTYanRlE/p7GhpzeJxuYEAw=; b=VBGZJX37cIonHflyh5wxQEYtA7x0Amu7xLp5oHg78xxzjlt00cjIy+isenefHoIg4C 7RPKpPKN7tNdKpc5TJpvvjRVfwNo0gjNGN7CKKchtGLMKpKiFopezjtAyUjPZ3Xw0E44 AiIeDloDLlbg4hG+TB7uY37khZtUbDa2KvU7TzvyJp3nYlzf4yYYls3L1NdK27QPw8nf sz8uqV3Ppqtknjd2ssVqESH9epvsMQdYRFRnMtNB4O62dvnsKe7ylqebkVv4+kW7UGg2 DnPWEaumh8BXSAsOXIapCn08doAMzYbVApGVmAqFJNutLvA+gz5W1elezbot9wqwMrv/ tpQQ== X-Forwarded-Encrypted: i=2; AFNElJ/AIcQNvmuFKoZxk+oqsKsqkNBQL+oIVxTWZl0CMIJLUQ5GzN3tUIfjIZPnTcfADjVshoOErHhTtZt0@gnusha.org X-Gm-Message-State: AOJu0Yz3bu/jDywNxCq6ZOhFkxRxzpPN2LXqRSkXtzBn4CPcLxeB9Epl rs+Gpezaqw28Jj0ah0jkRrzPDXgvtbH+04NH9dNPjjvZzyrvm0hfGJOT X-Received: by 2002:a05:6871:ea83:b0:430:1519:5cf7 with SMTP id 586e51a60fabf-447dcde206amr3847781fac.14.1782337807659; Wed, 24 Jun 2026 14:50:07 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdCkuFBU5xNLbBugY8Ug58ZTdbKDIOM1Ip3ZtgZAdShyg==" Received: by 2002:a05:6871:3212:b0:447:408b:42a7 with SMTP id 586e51a60fabf-447408b4f05ls2261261fac.1.-pod-prod-05-us; Wed, 24 Jun 2026 14:50:02 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/xupXikNjVPnHLaSE12f6UWgbZgQoUVCzVQ7y6wf1vdsa2sISgxNubiRs8qz4IET4idQ84P/Q5KUuc@googlegroups.com X-Received: by 2002:a05:6808:1802:b0:48a:a657:267e with SMTP id 5614622812f47-49076ba709cmr3595478b6e.9.1782337801924; Wed, 24 Jun 2026 14:50:01 -0700 (PDT) Received: by 2002:a05:6808:8983:20b0:480:77ce:ad79 with SMTP id 5614622812f47-490457c66a2msb6e; Wed, 24 Jun 2026 13:24:17 -0700 (PDT) X-Forwarded-Encrypted: i=2; AHgh+RpYzwEvK4XJMADmLyfsRU+G2bivu+sPcDWI/ZcGG3qwCsIFK6KP+ACakjHYAXqsSL7+OICio2GZAkFP@googlegroups.com X-Received: by 2002:a05:6a00:8d8c:b0:842:3be7:4d55 with SMTP id d2e1a72fcca58-845a2700e91mr5921240b3a.11.1782332656359; Wed, 24 Jun 2026 13:24:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782332656; cv=none; d=google.com; s=arc-20260327; b=Ygev/t8bz6M/K9XdUp1TyRyjuaHUy2n7bfm3Jjl5C/xc5iOHAYzqOiboWaz8wt7S7L r1IFR6zn7P91eQrmCc9POWu3k9Xr4u1UV4X8SA5UMPLbR/nzNU5cizQyNanYQVgM5eIS FwWlp11ZBVLZbz+b631GWjew4bpsQwzF0+Bk3uS7qIF+iuv+Gus+lELmJpxf2+ms4cNw 9+20o1D2JfVZasqt21pLRcGRvS1V1bwOj8xSQ7n0YVhoINanfBrWs0GtUOhefTbpnM5n bpBU7VSmcyMcAQT/hmEO4xQKuvCuN/F1wohrFsTlRLzlU1zl+y6NzykiCbtyv2iI0I/k DTZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=33bp8pjVW+JGejfzCQpV+I+/KJ3rKq4eSMPGZJvO/i0=; fh=8ieLjFCfXunJ4CYRGdQ4+CzSjiVKuuIFjUMQIyB2rPU=; b=bbyKWfnn7/DNBQkUAJt/l/AVBhsuBpa8PaCsNtwcjBYxoeAjED4bt0VnkgvPW14njY 8C8UPLOH+uWn4+OcMmaB8SSOQG0ZRbdgBAMvvjyQHJFLlllpV71PIkO9ix/Ja7TCyJJU T6YUR0InpWdHqkO1rs1ssjP24CsoeiHSFe7Tbc6b3hoe5S62E8QUDsVb+41nJf+xJkFH fKCslzhgSoiTm1ucxQTliw9XJyqCIoagE9pVrcBKaCWdjoWOb17W0mCkOpdxDsU53TY1 9EthWjD4RK4JtAoa+Ok1xCvm8uYu1fgk+tN0gR261RIVhuwOFEdd1Gy55JTm3he00mIp NhcQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="QYo/rLjx"; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-244122.protonmail.ch (mail-244122.protonmail.ch. [109.224.244.122]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-845a40b1070si120958b3a.5.2026.06.24.13.24.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 13:24:16 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) client-ip=109.224.244.122; Date: Wed, 24 Jun 2026 20:24:09 +0000 To: Anthony Towns From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Pieter Wuille , conduition , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR Message-ID: In-Reply-To: References: =?us-ascii?Q?_____<=5Fz6=5FJUmphCkUYvI6gemSFMD9Sb=5FrDL03IQbtZQCNlk6pmioGEQBir=5FgMyZCfticFa8Ttfc0xoFHdxR07=5FMNuAfBu8do=5Fh5IDf2apVk1w1BM=3D@wuille.net>__<81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3U?= =?us-ascii?Q?e5E4zc2qWYn65gRxmmFLKg=3D@wuille.net>_?= Feedback-ID: 7060259:user:proton X-Pm-Message-ID: e1eb3da0854a5d5c836e042ae268f86c77aad42e MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="QYo/rLjx"; spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.122 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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 (-) Hi AJ, > There are three main variations to this, I think: > > [...] > > Self-reliance: Q-day goes from maybe to definitely faster than consensus > changes can be coordinated, and the only reason people's funds remain > safe is that they can (and do) keep the quantum-vulnerable spend > paths secret. 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 "sel= f-reliance" path here. > > Picking when Q-day will occur, either individually for determining > your own security posture, or collectively for organising a consensus > change seems very difficulty: it involves evaluating both complex state > of the art physics research, but also estimating the covert abilities > of national governments and the incentives to attack bitcoin prior to > revealing their capabilities. To me, that doesn't bode well for a smooth > and fast deployment of a consensus change in advance of problems occuring= . 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 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 most > conscientious 1% of users make use of P2MR securely, that might secure 10= % > of funds, but having 90% of the bitcoin supply crash probably wouldn't be > very valuable either. 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 conjecture fee > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advanta= ge > > > over P2TRv2 will yield significant savings for end-users in absolute > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes bec= omes > > > significant (100 sats per spend or more). > > 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 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 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 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 the > "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 > 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 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 entire > 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 de= precate 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 incr= emental cost of EC spend > paths in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is nea= r 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 an > > EC-disabling fork will happen that at least applies to the output type > > itself, in time. "Later" is the expectation that such a disabling will > > happen after the output type is introduced, but still in time (so, befo= re > > Q-day). Outputs without a strong expectation that their EC paths/opcode= s > > will be disabled, or not in time, I classify under "Never". >=20 > > I believe here you're instead arguing for P2MR ("Merkle-Never") > > over all "Later" options. That was my previous point: I think (solely) > > having "Never" output types like P2MR is just utterly insufficient for > > any worthwhile migration. It's so incompatible with today's workflows > > that it either won't be adopted, or (possibly inadvertently) adopted > > in an insecure fashion. Yes, it gives people the option to safeguard > > their own coins, but to me that's disaster recovery territory - I think > > we ought to prioritize maximizing the chances for saving the currency > > as a whole in case Q-day comes, not a small subset of individual users' > > coins. P2MR (alone) doesn't really achieve much in that regard in my vi= ew, > > thus we at least need something of the "Later" class in addition. >=20 > I'm not sure I follow/agree with the logic here. I think the general idea > is: >=20 > 1) we create some new address types that allow post-quantum spending, bu= t > also allow efficient quantum-vulnerable spending that can be used pri= or > to Q-day >=20 > 2) many people migrate to these new address types >=20 > 3) Q-day arrives >=20 > 4) all spending goes via the post-quantum paths, and everyone's funds ar= e > safe >=20 > There are three main variations to this, I think: >=20 > Later-dominant: towards the end of (2) but prior to (3), the > quantum-vulnerable spend paths are disabled in a predictable, planned > manner, preventing coin theft, but not disrupting active usage > significantly (or not disrupting it any more than the proximity of > Q-day already is). >=20 > Self-reliance: Q-day goes from maybe to definitely faster than consensus > changes can be coordinated, and the only reason people's funds remain > safe is that they can (and do) keep the quantum-vulnerable spend > paths secret. >=20 > Disaster-recovery: neither the "predictable/planned consensus change" of > Later nor the "everyone takes responsiblity for their own funds" > works, and the only way to avoid a large percentage of bitcoin > becoming a reward for quantum research is to replace EC spend paths > with a ZK proof of knowledge of a BIP32 seed or similar, requiring > a hard fork. Such a hard fork would be certain to be controversial > ("why at this height: I received a payment five blocks after // > my funds were stolen by a quantum attacker five blocks earlier // > why are only BIP32 funds recoverable not scheme X"), but if no other > approach works, might still be the ultimately outcome. >=20 > > So the point here was just: if you already accept the need for a "Later= " > > output type (=3D one with builtin-in EC disabling expected from the sta= rt), > > P2TRv2 is preferable over P2MR+ED, because: >=20 > As far as I can see, only having P2TRv2 addresses would rule out the > "self-reliance" path here. >=20 > Picking when Q-day will occur, either individually for determining > your own security posture, or collectively for organising a consensus > change seems very difficulty: it involves evaluating both complex state > of the art physics research, but also estimating the covert abilities > of national governments and the incentives to attack bitcoin prior to > revealing their capabilities. To me, that doesn't bode well for a smooth > and fast deployment of a consensus change in advance of problems occuring= . >=20 > It's possible that general carelessness on behalf of users would also > rule out the effectiveness of a self-reliance approach: if only the most > conscientious 1% of users make use of P2MR securely, that might secure 10= % > of funds, but having 90% of the bitcoin supply crash probably wouldn't be > very valuable either. But even then, that may make the "disaster-recovery= " > approach less problematic, by ensuring the 1%/10% who were conscientious > can avoid being part of the "my funds were stolen by a quantum attacker" > contingent, eg. >=20 > > > Theorycrafting for a second here. It's reasonable to conjecture fee > > > rates will be much higher post-Q-day, and thus P2MR's 32 byte advanta= ge > > > over P2TRv2 will yield significant savings for end-users in absolute > > > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes bec= omes > > > significant (100 sats per spend or more). >=20 > I don't think that is the right way to look at. 8vb/input is about > an additional 14% today (vs a taproot key-path spend), but with the > post-quantum signatures we have available now that's likely to reduce > to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B, > you're only getting an expected savings in fees / increase in block > capacity on that order of magnitude, ie: 1%-7%. That's nice to have, > for sure, but doesn't compare to introducing a new address type that > puts the PQ sigs in an extension block, or one that uses ZK proofs to > do cross-input or cross-transaction signature aggregation, eg. So a 32B > witness overhead for an unused/unusable key-path post-Q-day doesn't seem > very relevant to me. >=20 > > FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed > > perfectly. The expectation should be just that it happens before Q-day, > > and when it looks inevitable or the fear about that is large enough. >=20 > FWIW, I would define "timed perfectly" precisely as "EC disabling > fork happens before Q-day". Maybe allowing some additional months of > EC-efficiency would be a win while not taking out too much migration time= , > but for me "perfection" here means "no one who upgraded lost money via > quantum-related vulnerabilities". >=20 > One reason I'm doubtful is that I think for some the "it looks inevitable= " > threshold has already been crossed, eg: >=20 > >> So let me attempt to partially fill the silence, similarly to what > >> Scott Aaronson did in his April 29 post. Given everything I know, > >> including scary non-public information, I now put the odds of qday by > >> 2032 at 50%. 10% by 2030. >=20 > >> IMO a good target date for migration is 2029, roughly 3.5 years > >> out. 2029 happens to be the date selected by Google, Cloudflare, and > >> the Ethereum Foundation. >=20 > https://x.com/drakefjustin/status/2061793725299224676 >=20 > >> So, here it is: if quantum computers start breaking cryptography a > >> few years from now, don=E2=80=99t you dare come to this blog and tell = me that > >> I failed to warn you. This post is your warning. Please start switchin= g > >> to quantum-resistant encryption, and urge your company or organization > >> or blockchain or standards body to do the same. >=20 > https://scottaaronson.blog/?p=3D9718 >=20 > Personally, that leaves me at a minimum very skeptical of the utility > of introducing either P2MR or P2TRv2 (etc) approaches that don't also > introduce a quantum-safe spending path on day one. >=20 > > First a meta-point here: the reason I like separating the discussion in= to different dimensions than just "P2TRv2 vs P2MR" is because there are mor= e options than those two, and not every argument applies to the same separa= tion into two classes. Let me list them explicitly here, roughly in decreas= ing order of how strongly I feel about them: > > - We need at least a "Later" option for meaningful migration, i.e. P2TR= v2 or P2MR+ED. > > - Within the "Later" option, P2TRv2 is preferable. > > - A "Later" option benefits from being the only PQC migration strategy,= making it a Schelling point. >=20 > Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the > "Later-dominant" scenario, and only to the degree that it's slightly > cheaper prior to Q-day. If it were the only available option, that would > increase the risk of loss involved with both the other approaches. (I > don't think P2TRv2 is meaningfully more private than P2MR in the way > taproot v1 is, as presumably you'd only adopt that address format if > you wanted to have a post-quantum script path) >=20 > > > You'd have to convince everyone to deploy and then adopt P2TRv2 today= under the public knowledge that it is insecure and their coins are more li= kely to be stolen. That's a hard sell. > > > > > How does one pitch P2TRv2 to users? "It will be quantum secure one da= y we promise because everyone is incentivized to fix it later as Bitcoin wi= ll die if we don't." > > > > > > 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, because P2MR (or a= ny "Never" output type) fundamentally requires many users to change their w= orkflows entirely. >=20 > Let's call NoEC-day the earlier of activation of a soft-fork disabling > EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably > equal to "the day the bitcoin ecosystem has finally agreed that CRQCs > are inevitable". >=20 > My (cynical?) view is the only people who will adopt either P2TRv2 or > P2MR prior to NoEC-day being schedule will be people who are willign > to use those features in a quantum-safe way -- that is, keeping their > EC pubkeys secret, and only revealing those EC pubkeys to spend them > immediately, prior to NoEC-day. In that view, the EC-spend-paths of such > coins prior to NoEC-day are only an opportunistic "make spends cheaper" > shortcut, they don't allow the funds to be used in lightning channels > or to let your wallet be audited via sharing an xpub or anything similar. >=20 > Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible > that lightning software could get an upgrade to generate post-quantum > signatures for channel commitments or HTLC claims, I just think it's > pretty unlikely that that will happen at a meaningful scale when everyone > has much more immediate and less theoretical things to work on prior to > NoEC-day, especially when the efficiency/performance of such changes is > likely to be very low. >=20 > > This focus on allowing individual users the ability to safeguard their > > coins just feels like a red herring: [...] >=20 > While I appreciate your point, I also feel that "allowing individual > users the ability to safeguard their coins" is pretty close to the entire > point of Bitcoin. :) >=20 > > In either case, I consider anything that requires hardcoding > > specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus > > rules (and only allowing those coins to survive) to be squarely in > > disaster-recovery land. It feels like embracing arbitrariness, and > > giving up on the permissionlessness that makes Bitcoin interesting - > > if the community shows it can get consensus on effectively burning > > coins except those that match a whitelist, it feels hard to maintain > > censorship-freeness as a value, even if the whitelist includes most of > > the (active) coins. That is of course not to say such techniques aren't > > interesting to work on, but to me, their place is in disaster recovery > > scenarios to save what's left, after Q-day, if migration attempts were > > unsuccessful. In such a setting, I think we're already in effectively a= n > > altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly > > growing) set of ways to recover burned coins can be hardforked in. >=20 > Just for the record, I think the above is an accurate description of the > "disaster-recovery" scenario above: the "quantum-safe" hard-fork variant > of bitcoin would be fairly described as a utxo-bootstrapped altcoin, > would compete in the market with the "quantum-unsafe" bitcoin that > existing nodes would continue to follow, and possibly there would be > many slightly varying such altcoins competing with each other, eg on > exactly what height the utxo snapshot was taken or what coins become > spendable. It would not be a fun time for holders of affected utxos. >=20 > > My impression is that your approach is to have an answer for many > > possible futures, including ones where Q-day arrives within just a few > > years. >=20 > "The key of strategy... is not to choose a path to victory, but to choose > so that all paths lead to a victory." >=20 > -- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit >=20 > > But optimizing for disaster-recovery also means reducing the > > chances of preserving Bitcoin as we know it in the scenarios where a > > successful migration is still possible. And if Q-day does arrive that > > soon, I don't see what we can do today that would preserve Bitcoin in > > a form we care about anyway. By accepting that, we can focus on the > > futures where our choices today can still materially improve the outcom= e. >=20 > Preserving bitcoin as a personally-possessible inflation resistant > store of value seems both possible and worth caring about, even if other > constraints means that many people can't afford to personally hold it > (and have to go through ETFs/exchanges/banks) and that it can't be used > for day-to-day transactions. Would be very disappointing if true, and > even given Q-day in a few years I expect we could do better than just > that, but it doesn't feel like a throw-in-the-towel event to me. >=20 > > > Essentially yes though, I expect the majority of holders will probabl= y > > > migrate to PQ addresses via rescue protocols, either on Bitcoin or a = fork > > > thereof. Even if we can't come to consensus and deploy a new output t= ype, > > > we'll still be able to rescue most coins. It's just that we'd have no= where > > > to rescue them to, so we ought to make PQ wallets available soon, so = we're > > > not in a rush to build them later when we need them. If a PQ wallet c= an > > > use cheap EC signatures while they're still trustworthy, all the bett= er >=20 > FWIW, that's my guess on how things would play out if the near-term Q-day > timelines I've seen (ie, 2029 to 2035) match reality. I hope that's > pessimistic (either because the Q-day timelines are bad estimates, or > because migration happens in a more orderly fashion), but I guess we'll > see. I don't rate my ability to evaluate Q-day predictions very highly. >=20 > > - A (not-quite-CR)-QC breaks 128-bit ECDLP, say. >=20 > I'm not in a position to judge, but the google paper claims: >=20 > "Indeed, if a leading quantum architecture encounters and overcomes > all its scaling challenges before producing a device able to > solve (for example) 32-bit ECDLP, then there may be little time > between the breaking of 32-bit ECDLP and the breaking of 256-bit > ECDLP. Furthermore, the community should not expect to see published > demonstrations of the most advanced quantum error-correction > architectures and quantum algorithms deployed to cryptanalytic > problems. Thus, a successful public demonstration of Shor=E2=80=99s > algorithm on a 32-bit elliptic curve should not be seen as a wake-up > call to adopt PQC as much as a potential signal that PQC adoption > has already failed." >=20 > and places the required tiffoli gates and logical qubits for a 32-bit > break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100) > for 256-bit. >=20 > > Of course, if you believe it's the only possible future, I understand > > you'd come to a different conclusion. But is it really? Do you think > > this isn't a plausible future: >=20 > > - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too)= gets introduced in the next few years, with hash-based PQC opcodes. > > - Over the course of the next decade or so, it gets adopted by practica= lly all active users. >=20 > I think it might be better to look at that scenario in a more fine-graine= d > way? I think your "Late-ish" scenario is: >=20 > 1) P2TRv2 (or whatever) is introduced > 2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-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. >=20 > I think your "Soon-ish" scenario differs as of step (4): >=20 > 4) NoEC-day happens. Massive disruption because the "what's used in pra= ctice" > path breaks, but everything is recoverable. > 5) Post-quantum approaches get even higher priority >=20 > I'm skeptical of step 3 here; and would expect to see something more like= : >=20 > 3') Only a small proportion of users (ie, the most conscientious/fearfu= l) > switch to P2TRv2 with most preferring to stick with what works >=20 > That has no real impact on the Late-ish scenario, but changes the Soon-is= h > scenario to either: >=20 > 4'a) NoEC-day happens substantially before Q-day; people hurry to migra= te > to P2TRv2, but it mostly works. >=20 > or >=20 > 4'b) NoEC-day happens essentially at the same time as Q-day; coins get > stolen and we hit the disaster-recovery scenario. >=20 > Perhaps the difference between (3') and (3) playing out in reality > is just having nearly everyone agree that the upgrade is essential, > and rather than leaving it to self-interest/market-dynamics, having a > consistent push that every single wallet/service that doesn't deprecate > every current address type is a danger to the entire ecosystem, even > absent widespread agreement on when/if Q-day will happen. Arguably that > would be easier to agree on if the incremental cost of EC spend paths > in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to > zero, rather than up to ~14% per input. >=20 > Cheers, > aj >=20 --=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/= SHKHzyvg1Rr2E-CBLdgNEinhsndgXog0v4YxlDBJAYVcwjCEnBdByD-3_PSCZzkf9nHeisOKHSq= jsBrTgumAVwsZPHHnwrx7FcpZeVZiups%3D%40protonmail.com.