path: root/6c/452119f36cc20f54af42e096ae504d86c10a36

Delivery-date: Fri, 22 Aug 2025 15:05:55 -0700
Received: from mail-qv1-f63.google.com ([209.85.219.63])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDMP3YP4WUCBBN6TUPCQMGQE5UW6MAQ@googlegroups.com>)
	id 1upZtS-0006qT-L8
	for bitcoindev@gnusha.org; Fri, 22 Aug 2025 15:05:55 -0700
Received: by mail-qv1-f63.google.com with SMTP id 6a1803df08f44-70a88dd1408sf56087616d6.0
        for <bitcoindev@gnusha.org>; Fri, 22 Aug 2025 15:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1755900348; x=1756505148; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :from:to:cc:subject:date:message-id:reply-to;
        bh=onvJLJDi7HTInIekDUUvohnURekWyCOQpJx1i3HgFIQ=;
        b=mSQU2ToHKQAkLrrmsNhd13udJ0vDgifN3aEIMiqvh31cZB0LCDA1q4QZJQkVQ4YUNp
         1TZ9kmdnZyldZvdM5Ps6Bh5g0ooUwY0pNFF//r2s12FwpnuAYn6LMVxj+bH37YWvBadJ
         Kjp3ju/rIIonuGMBCHuLRJ1CJV/q52C2QgZfZVOpuxBI3RN7w0pdqegrflA6KlsB93li
         u7fb8DsTJRLZpVLQKjYzvThAVWxMm9Js5kSaJDobdJttiggqkiehJttf4mHylLcMRp8K
         li0tgPF2zMS/dVzLeCi/QmYb3h8Zc9dUWjjdD+hAqKNPzicknG0gcISLkLjaPvoNmuRp
         EuFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1755900348; x=1756505148;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=onvJLJDi7HTInIekDUUvohnURekWyCOQpJx1i3HgFIQ=;
        b=R1e4qsHZMTeAqsCp06nCFpJGXaaOIrLiwC5/F6VgWjJQuHGogEDoyR5XdVRizIbHxE
         YsCXpt0XpSZ0RnO/vBRY8zURBhq7ta/v4X8zb6MD4paG2IHSEz36+p+L6l9sSIIHE+Yg
         iOnIE5nGK8C14UCT5ReaPUd2gpmjW02ReHgJF76qoLTRHaB0Ose0AHsHhcZeZD2c+BLq
         hB3FkPj/UGDy3D4k6k8WgWUGQuKhqzqYLjbyVWTxNRVGgP1T62IbQBIVWs9kZ/5pQYBe
         jAsIPgIChoST4uKfG2onwSC3fpmCsAuVh0vAy4N+SdAR1T0ez8CIAE3A2UTiDDf3EMm3
         TV7Q==
X-Forwarded-Encrypted: i=1; AJvYcCWwrSU0ami2RnHORaEsm0YLtdkAflOiwNLs1VvPy/8W/J1d/wxpVhI3EuAREpnUHO/QTctfGR3co56b@gnusha.org
X-Gm-Message-State: AOJu0Yy0jc8NJA/3M0js7I2TDZDtT99wXRLWFszcnRZ9Ca/kdX/iXyya
	Ncb2eSHI7GRkPwVfY15/4LwMWYwgKFe03e6c5cmXtGyj2H5kL7+ibygw
X-Google-Smtp-Source: AGHT+IFOPH2aeOlD1a1Z4PkSCAceQ1XBS5V4xRj0lF3eEJvzKE+zIZo9aCU0P1+xzwqDKhJH2pIvKA==
X-Received: by 2002:ad4:5de6:0:b0:707:5d28:2b80 with SMTP id 6a1803df08f44-70d970a46d7mr56074536d6.7.1755900348009;
        Fri, 22 Aug 2025 15:05:48 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZewdxAvhEWwF7ctCrGA/RRPL108xawJsLQloTSURje9bw==
Received: by 2002:a05:6214:242f:b0:709:ad61:7fb9 with SMTP id
 6a1803df08f44-70d85a728a5ls46429146d6.1.-pod-prod-04-us; Fri, 22 Aug 2025
 15:05:42 -0700 (PDT)
X-Received: by 2002:a05:620a:298f:b0:7e6:998c:99c0 with SMTP id af79cd13be357-7ea10fdb3dfmr538683285a.24.1755900342826;
        Fri, 22 Aug 2025 15:05:42 -0700 (PDT)
Received: by 2002:a0d:c201:0:b0:71f:9f84:d07 with SMTP id 00721157ae682-71fdb813044ms7b3;
        Thu, 21 Aug 2025 13:21:19 -0700 (PDT)
X-Received: by 2002:a05:690c:7109:b0:71f:d22b:3526 with SMTP id 00721157ae682-71fdc2b148amr8150957b3.10.1755807677443;
        Thu, 21 Aug 2025 13:21:17 -0700 (PDT)
Date: Thu, 21 Aug 2025 13:21:17 -0700 (PDT)
From: "'Bitcoin Foundation' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <ec2153e6-7cf5-400c-8964-e2a9269777a5n@googlegroups.com>
In-Reply-To: <80005f10-e9af-4b4f-a05f-de2bd666d8ccn@googlegroups.com>
References: <4d6ecde7-e959-4e6c-a0aa-867af8577151n@googlegroups.com>
 <fff86606-d6ce-4319-a341-90e9c4eba49dn@googlegroups.com>
 <6532d72c-fc2b-485a-9984-a9ade31e1760n@googlegroups.com>
 <1LDO_bQOdcKkNoKyyjfqLXAPUBVXSL667nAKDCNUfN2D7HEpDAkuFQrMubklIi1QdDI6BXdgB674g4uWYRlyQ5f-dlztDtnoEbIAlmrCg5M=@protonmail.com>
 <80005f10-e9af-4b4f-a05f-de2bd666d8ccn@googlegroups.com>
Subject: Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition
 Framework for Bitcoin
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_13418_2016232564.1755807677075"
X-Original-Sender: contact@bitcoin.foundation
X-Original-From: Bitcoin Foundation <contact@bitcoin.foundation>
Reply-To: Bitcoin Foundation <contact@bitcoin.foundation>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

------=_Part_13418_2016232564.1755807677075
Content-Type: multipart/alternative; 
	boundary="----=_Part_13419_2044323691.1755807677075"

------=_Part_13419_2044323691.1755807677075
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

*Response to Murch:*

Thank you for your feedback. You are correct that the high-level goal of=20
achieving quantum resilience is shared between our proposal and the earlier=
=20
one from Lopp et al. (co-authored by the Pauli Group). However, the=20
critical differentiator lies not in the "what" but in the "when" and the=20
"why"=E2=80=94factors that fundamentally impact Bitcoin's security and stab=
ility.

The primary shortcoming of the Pauli Group proposal is its alarmist and=20
commercially motivated urgency, which pushes for an accelerated timeline=20
that is misaligned with the cautious, evidence-based approach of=20
international standards bodies. As the NIST Internal Report 8547 makes=20
clear, the transition to PQC is a massive undertaking that requires careful=
=20
coordination across the entire cryptographic ecosystem, with a realistic=20
target for completion set for 2035 [NIST.IR.8547.ipd, p.8, 18]. NIST=20
explicitly allows for the continued use of classical signatures for=20
authentication until quantum computers are actually available, advocating=
=20
for a managed transition that minimizes disruption [NIST.IR.8547.ipd, p.15]=
.

The Pauli Group's timeline seems designed to create a false sense of=20
emergency, likely to benefit their commercial interests in promoting=20
specific solutions. In contrast, our BIP is structured around NIST's=20
well-reasoned 2035 horizon. This provides the entire Bitcoin=20
ecosystem=E2=80=94miners, wallet providers, exchanges, and users=E2=80=94wi=
th a realistic=20
and achievable schedule for a complete and secure migration. It avoids the=
=20
extreme risks of a rushed implementation, which could lead to critical=20
vulnerabilities, and instead fosters a deliberate, stable, and globally=20
coordinated upgrade. Our proposal is not a duplicate; it is a necessary=20
correction towards a timeline that prioritizes Bitcoin's long-term=20
cryptographic integrity over the speculative urgency of a private entity.


*Response to ArmchairCryptologist:*

Thank you for sharing the preprint by Dallaire-Demers et al., co-authored=
=20
by the Pauli Group. While their analysis of ECDLP challenges is a valuable=
=20
contribution to the field, their projected timeline for Cryptographically=
=20
Relevant Quantum Computers (CRQCs) in the 2027=E2=80=932033 window is highl=
y=20
speculative and built on a series of aggressive, unproven assumptions=20
regarding error correction and hardware scalability.

From a Bitcoin protocol perspective, our migration strategy must be=20
grounded in conservative, internationally-vetted standards, not optimistic=
=20
forecasts. The NIST Internal Report 8547 provides the definitive framework=
=20
for this transition. It explicitly states that the migration to=20
Post-Quantum Cryptography (PQC) is unprecedented in scale and will demand=
=20
substantial effort across diverse infrastructures, with a holistic target=
=20
for completion set for 2035 [NIST.IR.8547.ipd, p.8, 18]. This timeline is=
=20
not arbitrary; it is based on a comprehensive assessment of the immense=20
engineering challenges, the need for global standards coordination, and the=
=20
integration complexity across the entire cryptographic ecosystem=E2=80=94fr=
om=20
hardware modules and software libraries to network protocols and PKI=20
[NIST.IR.8547.ipd, p.12-13].

Furthermore, NIST cautions that migration timelines may vary based on use=
=20
case, but the 2035 target balances the urgency of the quantum threat with=
=20
the "practical challenges that different sectors face during this=20
transition" [NIST.IR.8547.ipd, p.18]. The Pauli Group's alarmist stance,=20
which suggests a much earlier doomsday scenario, appears commercially=20
motivated to push for a rushed adoption of their proposed standards. For=20
Bitcoin, a measured transition aligned with NIST's 2035 horizon ensures we=
=20
prioritize cryptographic integrity and ecosystem-wide stability over the=20
speculative and potentially self-serving timelines of private entities. Our=
=20
foundation's proposed BIP targets a full sunset of ECDSA by approximately=
=20
2035, a timeline that is both prudent and aligned with global standards=20
body guidance.


*Response to Alex Pruden:*

We appreciate you referencing the rigorous work by Gheorghiu and Mosca on=
=20
quantum resource estimation. Their findings are indeed important for=20
understanding the theoretical boundaries of quantum attacks. However, it is=
=20
critical to distinguish between asymptotic resource estimates and the=20
practical, engineering-heavy path to building a fault-tolerant CRQC.

NIST's transition plan, as outlined in IR 8547, is predicated on this very=
=20
distinction. The report emphasizes that the transition is starting now=20
precisely because of the "harvest now, decrypt later" threat, acknowledging=
=20
the risk to long-term data confidentiality [NIST.IR.8547.ipd, p.8].=20
However, for authentication=E2=80=94which is the primary function of digita=
l=20
signatures in Bitcoin=E2=80=94the threat model is different. NIST states th=
at=20
"authentication systems may continue to use quantum-vulnerable algorithms=
=20
until quantum computers... become available, at which point authentication=
=20
using these algorithms will need to be disabled" [NIST.IR.8547.ipd,=20
p.14-15]. This allows for a managed, rather than panicked, transition.

The 2035 target date for federal systems, referenced from NSM-10, is cited=
=20
in the NIST report as a primary goal, but it is presented with the=20
understanding that it must accommodate "legacy constraints or lower risk=20
profiles" and that flexibility is essential [NIST.IR.8547.ipd, p.18]. For a=
=20
decentralized system like Bitcoin, this flexibility is paramount. Rushing a=
=20
transition based on optimistic hardware projections introduces more risk=20
than it mitigates, potentially compromising security through improper=20
implementation. Therefore, the Bitcoin Foundation's strategy is to target a=
=20
full, ecosystem-wide transition by ~2035, ensuring a robust and thoroughly=
=20
vetted integration of a NIST-standardized PQC algorithm (like the=20
hash-based SLH-DSA in FIPS 205), in line with the comprehensive and=20
cautious approach advocated by NIST.

On Thursday, August 21, 2025 at 2:07:30=E2=80=AFAM UTC+2 Alex Pruden wrote:

> I consider the recent work by Mosca et al to be the most up-to-date in=20
> terms of research estimation:=20
> https://www.sciencedirect.com/science/article/pii/S0167739X24004308
>
> The estimate he provides is approximately an order of magnitude less work=
=20
> required to break ECDSA (P-256) vs RSA-2048. Ironically, the longer=20
> bit-lengths of RSA seem to actually contribute to post-quantum security,=
=20
> even though the motivation for moving from RSA-1024 was to protect agains=
t=20
> NFS and other classical attacks against shorter RSA instances.=20
>
> Note that the resource estimation in the paper doesn't account for=20
> Gidney's speedup, which was 20x reduction in qubits required. It's unclea=
r=20
> whether that same improvement factor could be applied here; as the Gidney=
=20
> paper showed, the earliest CRQCs will probably be hardwired for certain=
=20
> circuits for performance reasons. E.g. Gidney's circuit layout works for=
=20
> RSA-2048 and that's it. But the ideas he presents around error correction=
=20
> (e.g. the yoked surface code) might apply more broadly, it's hard to say.=
=20
>
> Also note that many of his assumptions are based on a superconducting=20
> architecture, which generally have faster runtimes but lower stability (s=
o=20
> scaling is harder)
>
> Other architectures like this one https://arxiv.org/pdf/2506.20660 from=
=20
> the neutral atom community have slower runtimes but greater stability. Bu=
t=20
> even if you scale, it probably only works for targeted, long-range attack=
s=20
> vs specific PKs as a CRQC.
>
> Lots of variables to consider here in terms of estimating the timeline fo=
r=20
> a CRQC, but the proactive approach is probably the right one, because (to=
=20
> quote Gidney in his conclusion) we should "*prefer security to not be=20
> contingent on progress being slow.*"
>
> On Tuesday, August 12, 2025 at 3:04:32=E2=80=AFAM UTC-6 ArmchairCryptolog=
ist wrote:
>
>>
>> An astute observation. To clarify the quantum computing landscape:=20
>> Google's current quantum processors do not possess 50 logical qubits, an=
d=20
>> even if they did, this would be insufficient to compromise ECDSA - let=
=20
>> alone RSA-2048, which would require approximately 20 million noisy physi=
cal=20
>> qubits for successful cryptanalysis [0].
>>
>>
>> That paper is pretty old. There is a recent paper from a couple of month=
s=20
>> ago by the same author (Craig Gidney from Google Quantum AI) claiming=20
>> that you could break RSA-2048 with around a million noisy qubits in abou=
t a=20
>> week.=20
>>
>> Paper: https://arxiv.org/pdf/2505.15917
>> Blog post:=20
>> https://security.googleblog.com/2025/05/tracking-cost-of-quantum-factori=
.html
>>
>> I can't say for sure whether this approach can be applied to ECDSA; I=20
>> have seen claims before that it has less quantum resistance than RSA-204=
8,=20
>> but I'm unsure if this is still considered to be the case. And while the=
se=20
>> papers are of course largely theoretical in nature since nothing close t=
o=20
>> the required amount of qubits exists at this point, I haven't seen anyon=
e=20
>> refute these claim at this point. These is still no hard evidence I'm aw=
are=20
>> of that a quantum computer capable of breaking ECDSA is inevitable, but=
=20
>> given the rate of development, there could be some cause of concern.
>>
>> Getting post-quantum addresses designed, implemented and activated by=20
>> 2030 in accordance with the recommendations in this paper seems prudent =
to=20
>> me, if this is at all possible. Deactivating inactive pre-quantum UTXOs=
=20
>> with exposed public keys by 2035 should certainly be considered. But I=
=20
>> still don't feel like deactivating pre-quantum UTXOs without exposed pub=
lic=20
>> keys in general is warranted, at least until a quantum computer capable =
of=20
>> breaking public keys in the short time between they are broadcast and=20
>> included in a block is known to exist - and even then, only if some=20
>> scheme could be devised that still allows spending them using some=20
>> additional cryptographic proof of ownership, ZKP or otherwise.
>>
>> --
>> Best,
>> ArmchairCryptologist
>>
>

--=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/=
ec2153e6-7cf5-400c-8964-e2a9269777a5n%40googlegroups.com.

------=_Part_13419_2044323691.1755807677075
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<b>Response to Murch:</b><br /><br />Thank you for your feedback. You are c=
orrect that the high-level goal of achieving quantum resilience is shared b=
etween our proposal and the earlier one from Lopp et al. (co-authored by th=
e Pauli Group). However, the critical differentiator lies not in the "what"=
 but in the "when" and the "why"=E2=80=94factors that fundamentally impact =
Bitcoin's security and stability.<br /><br />The primary shortcoming of the=
 Pauli Group proposal is its alarmist and commercially motivated urgency, w=
hich pushes for an accelerated timeline that is misaligned with the cautiou=
s, evidence-based approach of international standards bodies. As the NIST I=
nternal Report 8547 makes clear, the transition to PQC is a massive underta=
king that requires careful coordination across the entire cryptographic eco=
system, with a realistic target for completion set for 2035 [NIST.IR.8547.i=
pd, p.8, 18]. NIST explicitly allows for the continued use of classical sig=
natures for authentication until quantum computers are actually available, =
advocating for a managed transition that minimizes disruption [NIST.IR.8547=
.ipd, p.15].<br /><br />The Pauli Group's timeline seems designed to create=
 a false sense of emergency, likely to benefit their commercial interests i=
n promoting specific solutions. In contrast, our BIP is structured around N=
IST's well-reasoned 2035 horizon. This provides the entire Bitcoin ecosyste=
m=E2=80=94miners, wallet providers, exchanges, and users=E2=80=94with a rea=
listic and achievable schedule for a complete and secure migration. It avoi=
ds the extreme risks of a rushed implementation, which could lead to critic=
al vulnerabilities, and instead fosters a deliberate, stable, and globally =
coordinated upgrade. Our proposal is not a duplicate; it is a necessary cor=
rection towards a timeline that prioritizes Bitcoin's long-term cryptograph=
ic integrity over the speculative urgency of a private entity.<br /><br /><=
br /><b>Response to ArmchairCryptologist:</b><br /><br />Thank you for shar=
ing the preprint by Dallaire-Demers et al., co-authored by the Pauli Group.=
 While their analysis of ECDLP challenges is a valuable contribution to the=
 field, their projected timeline for Cryptographically Relevant Quantum Com=
puters (CRQCs) in the 2027=E2=80=932033 window is highly speculative and bu=
ilt on a series of aggressive, unproven assumptions regarding error correct=
ion and hardware scalability.<br /><br />From a Bitcoin protocol perspectiv=
e, our migration strategy must be grounded in conservative, internationally=
-vetted standards, not optimistic forecasts. The NIST Internal Report 8547 =
provides the definitive framework for this transition. It explicitly states=
 that the migration to Post-Quantum Cryptography (PQC) is unprecedented in =
scale and will demand substantial effort across diverse infrastructures, wi=
th a holistic target for completion set for 2035 [NIST.IR.8547.ipd, p.8, 18=
]. This timeline is not arbitrary; it is based on a comprehensive assessmen=
t of the immense engineering challenges, the need for global standards coor=
dination, and the integration complexity across the entire cryptographic ec=
osystem=E2=80=94from hardware modules and software libraries to network pro=
tocols and PKI [NIST.IR.8547.ipd, p.12-13].<br /><br />Furthermore, NIST ca=
utions that migration timelines may vary based on use case, but the 2035 ta=
rget balances the urgency of the quantum threat with the "practical challen=
ges that different sectors face during this transition" [NIST.IR.8547.ipd, =
p.18]. The Pauli Group's alarmist stance, which suggests a much earlier doo=
msday scenario, appears commercially motivated to push for a rushed adoptio=
n of their proposed standards. For Bitcoin, a measured transition aligned w=
ith NIST's 2035 horizon ensures we prioritize cryptographic integrity and e=
cosystem-wide stability over the speculative and potentially self-serving t=
imelines of private entities. Our foundation's proposed BIP targets a full =
sunset of ECDSA by approximately 2035, a timeline that is both prudent and =
aligned with global standards body guidance.<br /><br /><br /><b>Response t=
o Alex Pruden:</b><br /><br />We appreciate you referencing the rigorous wo=
rk by Gheorghiu and Mosca on quantum resource estimation. Their findings ar=
e indeed important for understanding the theoretical boundaries of quantum =
attacks. However, it is critical to distinguish between asymptotic resource=
 estimates and the practical, engineering-heavy path to building a fault-to=
lerant CRQC.<br /><br />NIST's transition plan, as outlined in IR 8547, is =
predicated on this very distinction. The report emphasizes that the transit=
ion is starting now precisely because of the "harvest now, decrypt later" t=
hreat, acknowledging the risk to long-term data confidentiality [NIST.IR.85=
47.ipd, p.8]. However, for authentication=E2=80=94which is the primary func=
tion of digital signatures in Bitcoin=E2=80=94the threat model is different=
. NIST states that "authentication systems may continue to use quantum-vuln=
erable algorithms until quantum computers... become available, at which poi=
nt authentication using these algorithms will need to be disabled" [NIST.IR=
.8547.ipd, p.14-15]. This allows for a managed, rather than panicked, trans=
ition.<br /><br />The 2035 target date for federal systems, referenced from=
 NSM-10, is cited in the NIST report as a primary goal, but it is presented=
 with the understanding that it must accommodate "legacy constraints or low=
er risk profiles" and that flexibility is essential [NIST.IR.8547.ipd, p.18=
]. For a decentralized system like Bitcoin, this flexibility is paramount. =
Rushing a transition based on optimistic hardware projections introduces mo=
re risk than it mitigates, potentially compromising security through improp=
er implementation. Therefore, the Bitcoin Foundation's strategy is to targe=
t a full, ecosystem-wide transition by ~2035, ensuring a robust and thoroug=
hly vetted integration of a NIST-standardized PQC algorithm (like the hash-=
based SLH-DSA in FIPS 205), in line with the comprehensive and cautious app=
roach advocated by NIST.<br /><br /><div class=3D"gmail_quote"><div dir=3D"=
auto" class=3D"gmail_attr">On Thursday, August 21, 2025 at 2:07:30=E2=80=AF=
AM UTC+2 Alex Pruden wrote:<br/></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;">I consider the recent work by Mosca et al to be the most up-=
to-date in terms of research estimation:=C2=A0<a href=3D"https://www.scienc=
edirect.com/science/article/pii/S0167739X24004308" target=3D"_blank" rel=3D=
"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://www.sciencedirect.com/science/article/pii/S0167739X24004308&amp;=
source=3Dgmail&amp;ust=3D1755890793386000&amp;usg=3DAOvVaw0OF2anT0BSxg2--Ll=
qNg89">https://www.sciencedirect.com/science/article/pii/S0167739X24004308<=
/a><br><br>The estimate he provides is approximately an order of magnitude =
less work required to break ECDSA (P-256) vs RSA-2048. Ironically, the long=
er bit-lengths of RSA seem to actually contribute to post-quantum security,=
 even though the motivation for moving from RSA-1024 was to protect against=
 NFS and other classical attacks against shorter RSA instances.=C2=A0<br><d=
iv><br>Note that the resource estimation in the paper doesn&#39;t account f=
or Gidney&#39;s speedup, which was 20x reduction in qubits required. It&#39=
;s unclear whether that same improvement factor could be applied here; as t=
he Gidney paper showed, the earliest CRQCs will probably be hardwired for c=
ertain circuits for performance reasons. E.g. Gidney&#39;s circuit layout w=
orks for RSA-2048 and that&#39;s it. But the ideas he presents around error=
 correction (e.g. the yoked surface code) might apply more broadly, it&#39;=
s hard to say.=C2=A0<div><br></div><div>Also note that many of his assumpti=
ons are based on a superconducting architecture, which generally have faste=
r runtimes but lower stability (so scaling is harder)<br><br>Other architec=
tures like this one=C2=A0<a href=3D"https://arxiv.org/pdf/2506.20660" targe=
t=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Den&amp;q=3Dhttps://arxiv.org/pdf/2506.20660&amp;source=3Dgmail&a=
mp;ust=3D1755890793386000&amp;usg=3DAOvVaw390hMA_1qqrlG7wvrY1rIh">https://a=
rxiv.org/pdf/2506.20660</a> from the neutral atom community have slower run=
times but greater stability. But even if you scale, it probably only works =
for targeted, long-range attacks vs specific PKs as a CRQC.<br><div><br></d=
iv><div>Lots of variables to consider here in terms of estimating the timel=
ine for a CRQC, but the proactive approach is probably the right one, becau=
se (to quote Gidney in his conclusion) we should &quot;<b>prefer security t=
o not be contingent on progress being slow.</b>&quot;</div><div><br></div><=
/div></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr=
">On Tuesday, August 12, 2025 at 3:04:32=E2=80=AFAM UTC-6 ArmchairCryptolog=
ist wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"><div><br>
        <blockquote type=3D"cite">
           =20
An astute observation. To clarify the quantum computing landscape:
Google&#39;s current quantum processors do not possess 50 logical qubits,
and even if they did, this would be insufficient to compromise ECDSA -
let alone RSA-2048, which would require approximately 20 million noisy
physical qubits for successful cryptanalysis [0].<br></blockquote><div><br>=
</div></div></div><div style=3D"font-family:Arial,sans-serif;font-size:14px=
"><div><div><span>That paper is pretty old. There is a recent paper from a =
couple of months ago by the same author (<span>Craig Gidney</span>=C2=A0fro=
m=C2=A0<span>Google Quantum AI</span>) claiming that you could break RSA-20=
48 with around a million noisy qubits in about a week.=C2=A0<span><br></spa=
n></span><div><span><br></span></div><div><span>Paper:=C2=A0<a rel=3D"noref=
errer nofollow noopener" href=3D"https://arxiv.org/pdf/2505.15917" target=
=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;=
q=3Dhttps://arxiv.org/pdf/2505.15917&amp;source=3Dgmail&amp;ust=3D175589079=
3386000&amp;usg=3DAOvVaw3elUTOiOuTkJMsUJ35t1Db">https://arxiv.org/pdf/2505.=
15917</a><br></span></div><div>Blog post:=C2=A0<span><a rel=3D"noreferrer n=
ofollow noopener" href=3D"https://security.googleblog.com/2025/05/tracking-=
cost-of-quantum-factori.html" target=3D"_blank" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Den&amp;q=3Dhttps://security.googleblog.com/202=
5/05/tracking-cost-of-quantum-factori.html&amp;source=3Dgmail&amp;ust=3D175=
5890793386000&amp;usg=3DAOvVaw2pgDhNjQNO9WVIGavhIDvB">https://security.goog=
leblog.com/2025/05/tracking-cost-of-quantum-factori.html</a></span></div><d=
iv><br></div><div>I
 can&#39;t say for sure whether this approach can be applied to=20
ECDSA; I have seen claims before that it has less quantum resistance than R=
SA-2048, but I&#39;m unsure if this is still considered to be the case. And=
 while these papers are of course largely theoretical in nature=20
since nothing close to the required amount of qubits exists at this=20
point, I haven&#39;t seen anyone refute these claim at this point. These is=
 still no hard evidence I&#39;m aware of that a quantum computer capable of=
 breaking ECDSA is inevitable, but given the rate of development, there cou=
ld be some cause of concern.</div><div><br></div><div><span>Getting post-qu=
antum addresses designed, implemented and activated by 2030 in accordance w=
ith the recommendations in this paper seems prudent to me, if this is at al=
l possible. Deactivating inactive=C2=A0<span>pre-quantum </span>UTXOs with =
exposed public keys by 2035 should certainly be considered. But I still don=
&#39;t feel like deactivating pre-quantum UTXOs without exposed public keys=
 in general is warranted, at least until a quantum computer capable of brea=
king public keys in the short time between they are broadcast and included =
in a block=C2=A0<span>is known to exist</span>=C2=A0- and even then, only i=
f some scheme could be devised that still allows spending them using some a=
dditional cryptographic proof of ownership, ZKP or otherwise.</span></div><=
div><span><br></span></div><div><span>--</span></div><div><span>Best,</span=
></div><div><span>ArmchairCryptologist</span></div></div></div></div></bloc=
kquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/ec2153e6-7cf5-400c-8964-e2a9269777a5n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/ec2153e6-7cf5-400c-8964-e2a9269777a5n%40googlegroups.com</a>.<br />

------=_Part_13419_2044323691.1755807677075--

------=_Part_13418_2016232564.1755807677075--