Skip to main content

​
Overview

This page is not a physics tutorial. It states the consensus cryptographic risk model that security teams use when planning around cryptographically relevant quantum computers (CRQCs): machines large and stable enough to run Shor’s and Grover’s algorithms at scales that threaten today’s deployed public-key sizes. Important nuance: Quantum computing is a credible long-term threat to both Bitcoin and Ethereum, but it does not “break the address” in a naive sense (e.g. deriving a private key from a hashed address alone with no further structure). The main risk is that a sufficiently powerful quantum computer could derive a private key from a visible public key, especially with Shor’s algorithm, which would let an attacker steal funds from outputs or accounts where the public key is already exposed—not from every untouched address at once. Industry analyses from firms such as Deloitte and Chainalysis frame the problem around exposed keys and reuse, not a single headline that “all addresses are broken.” Morpheum and most blockchains today rely on the same mainstream primitives as the rest of the industry: ECDSA and Schnorr on secp256k1, Ed25519, ECDH-style key agreement on elliptic curves, and hashes (e.g. SHA-256, Keccak) inside protocols. Signatures and key establishment are the urgent migration surface; symmetric encryption often has a simpler story (larger keys help against Grover) but still needs protocol updates when paired with broken public-key layers. Product decisions should follow your organization’s risk process and ecosystem roadmaps—not alarmist headlines or a single vendor’s blog.

​
What is vulnerable

Bitcoin is most exposed when a public key has already been revealed on-chain, for example in older pay-to-public-key (P2PK) outputs or when addresses are reused so the key is visible from a prior spend. Deloitte’s analysis notes that the public-key relationship is only partially impacted until the public key is known from a prior spend. Chainalysis similarly highlights early address types and reused addresses as higher risk, while modern address designs often keep the public key hidden until spending. Some post‑2026 commentary cites on the order of ~6.9 million BTC (roughly one‑third of supply) sitting in reused or otherwise exposed wallets as theoretically higher risk under future Shor‑class assumptions—treat such figures as illustrative and methodology‑dependent, not a live risk dashboard. Ethereum has a different exposure profile: its account model tends to encourage address reuse. Deloitte’s Ethereum-focused analysis reported that over 65% of Ether was in quantum-exposed addresses at the time of that study—higher than the Bitcoin estimate they compared against. (Figures are point-in-time and depend on methodology; treat them as illustrative, not a live dashboard.)

​
How the attack works

The basic path is: public key becomes visible on-chain → a quantum-capable attacker runs Shor’s algorithm (or related approaches) → private key is recovered → the attacker signs a transaction to move funds. The danger is therefore not merely “cracking an address string,” but breaking the elliptic-curve discrete-log assumption for ownership once the public key is exposed. See Deloitte’s discussion of this model.

​
Recent research: Google Quantum AI (March 2026)

A March 31, 2026 paper from Google Quantum AI (reported co-authors include Justin Drake, Ethereum Foundation, and Dan Boneh, Stanford) updates resource estimates for attacking elliptic-curve discrete logarithms, with headline figures often quoted for ECDSA on secp256k1—the stack Bitcoin and Ethereum use for standard EOAs and many contracts. Ed25519 and other curves use different parameters but remain in the same Shor‑class planning bucket for signature migration. This page does not mirror the full paper; retrieve the authoritative PDF and any errata from Google Research or the authors’ institutional pages. What the paper does not claim
  • It does not say a cryptographically relevant quantum computer (CRQC) exists today or that a break is imminent.
  • It does not replace protocol‑level roadmaps for Bitcoin or Ethereum with Google’s internal IT deadlines.
Key quantitative takeaways (as reported)
  • Breaking ECDSA/secp256k1–style discrete log could require fewer than ~500,000 physical qubits—on the order of a ~20× reduction vs earlier multi‑million qubit rough estimates. Constants depend on error rates, architecture, and algorithm details; treat the headline as planning‑input, not a specification.
  • In a hypothetical attack on an already exposed public key (for example during a Bitcoin transaction broadcast window), a sufficiently capable machine could in principle recover a private key in about ~9 minutes in some models—under Bitcoin’s ~10 minute average block interval—yielding on the order of ~41% “race” success probability in those models. This illustrates why exposure timing matters; it is not a statement that current hardware can perform the attack.
Organizational vs chain timelines
  • Google sets 2029 as an internal target to migrate its own infrastructure (authentication, digital signatures, etc.) to post‑quantum cryptography (PQC)—a prudent enterprise horizon, not a public‑blockchain protocol deadline.
  • The paper and related commentary emphasize that hardware progress has been faster than some older projections, lowering the apparent resource bar and compressing planning assumptions—while many independent analyses still often discuss material risk on mid‑2030s or longer horizons depending on assumptions.
Alignment with this document The paper reinforces the model used here: risk concentrates on exposed public keys and reuse, not on deriving keys from address hashes alone. It strengthens the case for algorithm agility, hybrid classical+PQC transitions, key rotation, vendor/HSM roadmaps, and on‑chain upgrade planning—especially for long‑lived keys in cold storage, multisig, DAOs, and agent signers.

​
Bitcoin vs Ethereum (exposure at a glance)

NetworkMain exposureWhy it matters
BitcoinOld P2PK outputs, reused addresses, any output that already revealed a public key (HRF)Funds can be stolen if the public key is exposed long enough for a quantum attack to succeed (HRF)
EthereumReused accounts and contexts where the public key is exposed; account model increases reuse (Deloitte)Deloitte’s analysis found a larger share of Ether in exposed addresses than Bitcoin in their comparison (Deloitte)

​
What is at risk (primitives)

ClassExamples in Web3Typical quantum threat model
Elliptic-curve discrete logECDSA, Schnorr (secp256k1), Ed25519Shor-class attacks break classical hardness assumptions; public keys and signatures tied to those keys are in scope once CRQCs exist at scale.
ECDH / key agreementTLS-like patterns, some wallet backupsSame curve groups; shared secrets derived from classical ECDH may be recoverable.
HashesSHA-256, Keccak in PoW, Merkle treesGrover speeds up search; protocols often plan larger hash outputs or different structures rather than assuming SHA-256 “breaks” overnight.
Symmetric ciphersAES-256 in storageGrover effectively halves effective symmetric key length in some threat models; 256-bit keys are often cited with more margin than 128-bit public-key equivalents.
Bitcoin and many systems also use hash-based patterns (script hashes, Merkle trees) that age differently than raw ECDSA on long-lived keys—but migration still matters when addresses or scripts assume classical-only primitives end-to-end.

​
Time horizon

There is no single consensus on when a CRQC might threaten deployed curves at scale. Google’s March 2026 work (see above) is one prominent data point that lowers some resource estimates and pulls forward organizational PQC deadlines—without asserting that today’s machines can break production networks. Other industry commentary still often frames the threat as long‑term to medium‑term, with mid‑2030s or later appearing in some independent analyses. The practical takeaway unchanged: ecosystems need migration paths and operational readiness, not panic. For additional accessible context, see e.g. Binance Square.

​
What should be done

  • Bitcoin: The best near-term defense is to avoid address reuse and move vulnerable coins to fresh addresses before a public key is exposed on-chain where policy allows. See HRF.
  • Ethereum: The long-term fix is protocol-level adoption of post-quantum cryptography (and orderly migration), because today’s public-key assumptions may not survive large-scale quantum adversaries. See HRF and Deloitte for the high-level case.

​
What happens first

The most likely first targets are addresses whose public keys are already visible on-chain, because Shor-class attacks can then target the discrete-log problem and produce a signing key. Google’s March 2026 paper gives a worked hypothetical for that situation—~9 minute runtime vs ~10 minute average block time and ~41% success in some race models—see Recent research: Google Quantum AI (March 2026). Third‑party reporting (e.g. AMBCrypto, Blockhead) may summarize the same themes; always verify numbers against the primary paper and your risk model.

​
If nothing changes

Without upgrades, the threat can move from “theoretical” toward systemic concern: Bitcoin would face theft risk concentrated in reused or exposed-key funds; Ethereum remains especially exposed in models with heavy reuse. Over time, confidence in both networks could weaken if users believe large holdings might become stealable once quantum hardware matures. See CoinMarketTrace for a general discussion of PQC and blockchain security.

​
Likely consequences (high level)

  • Theft of vulnerable coins and tokens from exposed addresses (Chainalysis).
  • Emergency migrations to new cryptography, which can be disruptive and expensive (DIG.watch).
  • Market volatility if the threat is perceived as near-term rather than staged (Forbes).
  • Uneven losses, with older Bitcoin outputs and heavily reused Ethereum accounts often facing higher relative risk (Deloitte).

​
Bottom line

No immediate “crypto crack” on live networks: current quantum hardware is not at the scale or stability required for Shor-class breaks against 256‑bit curve sizes in production. At the same time, revised resource estimates and enterprise targets such as Google’s 2029 PQC migration goal accelerate planning urgency for Bitcoin, Ethereum, Morpheum, and adjacent stacks: hybrid schemes, rotation, minimized public-key exposure, and ecosystem upgrades should move from “someday” to active roadmaps. If the ecosystem does not update in time, the outcome is still unlikely to be “every address breaks overnight,” but rather a growing drainable-funds problem that can become a trust crisis: the longer migration is delayed, the more value may sit in forms that quantum-capable attackers could eventually exploit. See a16z crypto on misconceptions, realities, and planning.

​
Why it matters for signing and agents

  • Long-lived keys: Cold keys, multisig quorums, and DAO identities that must stay valid for years need algorithm agility and rotation plans.
  • Autonomous signers: Agents and hot wallets should minimize exposure of private material, scope keys, and monitor standards.
  • Hybrid deployments: Many enterprises plan transition periods where classical and post-quantum algorithms coexist—HSMs, KMS, and protocols must support that without breaking compatibility.

​
What teams should track

  1. NIST and other PQC standards — Post-quantum signature and KEM schemes; final specs, reference implementations, and profile choices (sizes, timing side-channels).
  2. Hybrid protocols — Classical + PQC for TLS, VPNs, and custom chains; understand failure modes if one side is misconfigured.
  3. Vendor roadmaps — HSM, KMS, and wallet vendors that publish migration paths for signing algorithms.
  4. On-chain governance — Hard forks or upgrades that introduce new verification paths or account types for chain-wide PQC—follow your networks’ research forums and core dev calls.

​
What this page does not do

  • It does not predict when a CRQC will exist.
  • It does not replace audit, threat modeling, or compliance requirements for your jurisdiction.
  • It does not endorse every headline or single-study estimate; compare primary sources and ecosystem technical discussion.
  • It does not specify Morpheum wire formats for PQC; those will ship with product and release documentation.

​
See also