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 ) 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 ; 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" To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <80005f10-e9af-4b4f-a05f-de2bd666d8ccn@googlegroups.com> References: <4d6ecde7-e959-4e6c-a0aa-867af8577151n@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 Reply-To: Bitcoin Foundation 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 (-) ------=_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 Response to Murch:

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.

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].

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 />Response to ArmchairCryptologist:

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.

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].

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.


Response t= o Alex Pruden:

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.

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.

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.

On Thursday, August 21, 2025 at 2:07:30=E2=80=AF= 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:=C2=A0https://www.sciencedirect.com/science/article/pii/S0167739X24004308<= /a>

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

Note that the resource estimation in the paper doesn't account f= or Gidney's speedup, which was 20x reduction in qubits required. It'= ;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's circuit layout w= orks 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.=C2=A0

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)

Other architec= tures like this one=C2=A0https://a= rxiv.org/pdf/2506.20660 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.

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 "prefer security t= o not be contingent on progress being slow."

<= /div>
On Tuesday, August 12, 2025 at 3:04:32=E2=80=AFAM UTC-6 ArmchairCryptolog= ist wrote:

=20 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=C2=A0fro= m=C2=A0Google Quantum AI) claiming that you could break RSA-20= 48 with around a million noisy qubits in about a week.=C2=A0


I can'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'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'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 cou= ld be some cause of concern.

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=A0pre-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 brea= king public keys in the short time between they are broadcast and included = in a block=C2=A0is known to exist=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.
<= div>
--
Best,
ArmchairCryptologist

--
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.com/d/msgid/bitcoind= ev/ec2153e6-7cf5-400c-8964-e2a9269777a5n%40googlegroups.com.
------=_Part_13419_2044323691.1755807677075-- ------=_Part_13418_2016232564.1755807677075--