Re: [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

["'Bitcoin Foundation' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>]

[-- Attachment #1.1: Type: text/plain, Size: 10654 bytes --]

*Response to Murch:*

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

The primary shortcoming of the Pauli Group proposal is its alarmist and 
commercially motivated urgency, which pushes for an accelerated timeline 
that is misaligned with the cautious, evidence-based approach of 
international standards bodies. As the NIST Internal Report 8547 makes 
clear, the transition to PQC is a massive undertaking that requires careful 
coordination across the entire cryptographic ecosystem, with a realistic 
target for completion set for 2035 [NIST.IR.8547.ipd, p.8, 18]. NIST 
explicitly allows for the continued use of classical signatures for 
authentication until quantum computers are actually available, advocating 
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 
emergency, likely to benefit their commercial interests in promoting 
specific solutions. In contrast, our BIP is structured around NIST's 
well-reasoned 2035 horizon. This provides the entire Bitcoin 
ecosystem—miners, wallet providers, exchanges, and users—with a realistic 
and achievable schedule for a complete and secure migration. It avoids the 
extreme risks of a rushed implementation, which could lead to critical 
vulnerabilities, and instead fosters a deliberate, stable, and globally 
coordinated upgrade. Our proposal is not a duplicate; it is a necessary 
correction towards a timeline that prioritizes Bitcoin's long-term 
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 
by the Pauli Group. While their analysis of ECDLP challenges is a valuable 
contribution to the field, their projected timeline for Cryptographically 
Relevant Quantum Computers (CRQCs) in the 2027–2033 window is highly 
speculative and built on a series of aggressive, unproven assumptions 
regarding error correction and hardware scalability.

From a Bitcoin protocol perspective, 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, with 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 assessment of the immense 
engineering challenges, the need for global standards coordination, and the 
integration complexity across the entire cryptographic ecosystem—from 
hardware modules and software libraries to network protocols and PKI 
[NIST.IR.8547.ipd, p.12-13].

Furthermore, NIST cautions that migration timelines may vary based on use 
case, but the 2035 target balances the urgency of the quantum threat with 
the "practical challenges that different sectors face during this 
transition" [NIST.IR.8547.ipd, p.18]. The Pauli Group's alarmist stance, 
which suggests a much earlier doomsday scenario, appears commercially 
motivated to push for a rushed adoption of their proposed standards. For 
Bitcoin, a measured transition aligned with NIST's 2035 horizon ensures we 
prioritize cryptographic integrity and ecosystem-wide stability over the 
speculative and potentially self-serving timelines 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.


*Response to Alex Pruden:*

We appreciate you referencing the rigorous work by Gheorghiu and Mosca on 
quantum resource estimation. Their findings are 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-tolerant CRQC.

NIST's transition plan, as outlined in IR 8547, is predicated on this very 
distinction. The report emphasizes that the transition is starting now 
precisely because of the "harvest now, decrypt later" threat, acknowledging 
the risk to long-term data confidentiality [NIST.IR.8547.ipd, p.8]. 
However, for authentication—which is the primary function of digital 
signatures in Bitcoin—the threat model is different. NIST states that 
"authentication systems may continue to use quantum-vulnerable algorithms 
until quantum computers... become available, at which point authentication 
using these algorithms will need to be disabled" [NIST.IR.8547.ipd, 
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 
in the NIST report as a primary goal, but it is presented with the 
understanding that it must accommodate "legacy constraints or lower 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 more risk 
than it mitigates, potentially compromising security through improper 
implementation. Therefore, the Bitcoin Foundation's strategy is to target a 
full, ecosystem-wide transition by ~2035, ensuring a robust and thoroughly 
vetted integration of a NIST-standardized PQC algorithm (like the 
hash-based SLH-DSA in FIPS 205), in line with the comprehensive and 
cautious approach advocated by NIST.

On Thursday, August 21, 2025 at 2:07:30 AM UTC+2 Alex Pruden wrote:

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

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

[-- Attachment #1.2: Type: text/html, Size: 12941 bytes --]