When it comes to the NIST recommendation for the deprecation timeline, there is now a (very) recent paper available, released on August 19th 2025 (i.e. yesterday as of this writing), which suggests the timeline should be moved up somewhat. This paper targets ECDLP and ECC in general, and secp256k1 as used in Bitcoin specifically. You can find this here: https://arxiv.org/abs/2508.14011 Some key takeaways: "When algorithmic curves and vendor trajectories are overlaid on this common ruler, the earliest inter- sections appear in the late 2020s; more conservative crossings cluster in the early 2030s. We therefore indicate a first plausible window for cryptanalytically relevant quantum computers (CRQCs) around 2027–2033. The endpoints move mainly with three levers: reliable magic-state supply at scale (dis- tillation or cultivation), code distance sufficient for multi-hour jobs, and classical-control latency that keeps pace with fast error-correction cycles. If any lever stalls, the window shifts to the right; if severalimprove together, it shifts to the left." "The classical record remains consistent with Θ(2b/2) scaling for generic prime-field curves (Section 3); constant-factor engineering wins have not changed the asymptotics. In parallel, logical-to-physical translations suggest that credible ECC-256 attacks via Shor’s algorithm require mid-10^5 to low-10^6 noisy qubits under surface code assumptions, with cat-qubit architectures offering alternative overhead tradeoffs (Section 4; [37, 39, 46]) by trading fewer physical qubits for an increased complexity of their architecture. Overlaying algorithmic cost with public roadmaps yields a first plausible window forcryptanalytically relevant quantum computers in roughly 2027–2033, albeit with wide error bars." The lower bound of the window seems highly optimistic to me when compared to the actual roadmaps for physical qubits provided by Google and IonQ (the most optimistic of the bunch) which are summarized on page 15, but targeting 2030 as an actual deadline for having quantum-resistant addresses ready for use is starting to look necessary. Even if the surface code assumptions that are relied upon to combine physical qubits into logical ones turn out to not hold water, and this ultimately means that the current approach to quantum computers is unworkable, if nothing else, it would to counter the inevitable FUD. -- Best, ArmchairCryptologist On Monday, August 18th, 2025 at 7:12 PM, 'Bitcoin Foundation' via Bitcoin Development Mailing List wrote: > Dear ArmchairCryptologist, > > We appreciate your engagement with our quantum resistance proposal. > Let us address your points with additional technical context: > > NIST Reference DocumentationThe referenced blog post includes a link to NIST Internal Report 8547 (Initial Public Draft) [0], which offers critical guidance regarding the migration to post-quantum cryptographic standards. We strongly recommend thorough review of this document by all stakeholders evaluating quantum-resistant solutions. > > Pre-Quantum UTXO Sunset PolicyRegarding the migration of pre-quantum UTXOs: > > - Our current draft proposes freezing these outputs around 2033 > - This timeline appears in the "Migration Path: Phased Implementation" section ([https://quantum-resistant-bitcoin.bitcoin.foundation](https://quantum-resistant-bitcoin.bitcoin.foundation/)) > - We explicitly designed this as an adjustable parameter > - Based on community feedback, we're prepared to extend this sunset period beyond 2035 > The proposed recovery mechanism provides optional pathways for legacy UTXOs while maintaining network security. > > We remain open to community input regarding the sunset period for pre-quantum UTXOs. The current 2033 (block 1,327,121) proposal aligns conservatively with NIST's recommendation to deprecate ECDSA by 2035 [0], though we acknowledge reasonable arguments exist for adjusting this timeline. > > [0]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf > > On Tuesday, August 12, 2025 at 11:04:32 AM UTC+2 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/eefdcf22-9609-4fb1-b8c4-3274dc7f1f2en%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/-a-KFgZ_XFrN2mUZTauxRoD3H2f4Qhid-h1B2CcC0WgOxbJD-mfRvku_v-SOV7QcfAUpjgDO3kjJZvYnaNu1g0oXC9axoltclOgN628CMDc%3D%40protonmail.com.