Quantum Core Institute · harvest now, decrypt later
When does today's data get cracked?
An adversary can record your encrypted traffic today and store it until a quantum computer can break it. So data with a long secrecy requirement is already at risk, the computer doesn't need to exist yet. This puts dates on it.
Mosca's rule: if your data's shelf life (X) plus the time to migrate to post-quantum crypto (Y) is greater than the years to Q-Day (Z), some of it gets exposed. X + Y > Z means trouble.
Your shelf life plus migration time is 15 years, but Q-Day is only 8 years out. The last data protected by today's crypto stays sensitive 7 years past the point a quantum computer could read it.
The timeline
Latest safe start
Q-Day in
Data sent today
X + Y vs Z
What this leaves out. A planning model, not a prediction. Q-Day timing is genuinely uncertain, estimates from NIST, IBM, Google, and others cluster around 2030–2035, but no one knows. Shelf life and migration time are your inputs and dominate the result. The point isn't the exact year; it's that data sent today with a long secrecy requirement is already exposed to harvesting, and migrating later can't unsend it. Not security or legal advice.
FAQ
What is harvest-now-decrypt-later and why does it affect Bitcoin?
Harvest-now-decrypt-later (HNDL) is an attack strategy where an adversary — typically a nation-state — captures and stores encrypted communications or blockchain data today, with the intention of decrypting it once they have access to a quantum computer capable of breaking the encryption.
Why this is relevant to Bitcoin specifically:
Bitcoin's blockchain is public. Every transaction, every address, every public key ever broadcast is permanently archived and trivially downloadable. An adversary doesn't need to intercept anything — the data is already available. Any address that has ever signed a transaction has its public key on the chain, and that public key is the input to Shor's algorithm.
The timeline problem:
The question isn't whether quantum computers can break Bitcoin's cryptography today — they can't. The question is whether they will be able to before you've migrated your holdings to quantum-resistant addresses. If the answer is yes, the adversary who harvested your public key years ago will be able to derive your private key and drain the address.
What "cryptographically relevant quantum computer" means:
A CRQC is a quantum computer with enough logical (error-corrected) qubits and low enough error rates to run Shor's algorithm against a 256-bit elliptic curve key in a meaningful time window. Current consensus estimates from NIST and CISA put this at 10–20 years, with wide uncertainty. Some estimates are shorter.
The migration response:
Moving coins from an exposed address (one that has broadcast its public key) to a fresh, never-signed address reduces the attack surface to the hash function layer, which Grover's algorithm weakens but does not break. This migration should happen before quantum capability arrives, not after — once a CRQC exists, the window to move may be very short.
The timeline tool models this risk window against your current exposure profile.
Who is actually capable of harvesting blockchain data?
Anyone with an internet connection and a few hundred gigabytes of storage. The Bitcoin blockchain is roughly 600 GB and freely downloadable. Every full node already has every exposed public key.
That changes the threat profile in two ways:
- There is no "harvest" step in the conventional intelligence sense — the data is universally available, forever
- The attacker doesn't need to be sophisticated to harvest, only to eventually possess a quantum computer. The hard part is the compute, not the collection
This is qualitatively different from HNDL against encrypted internet traffic, where harvesting at scale is itself a state-level capability. For Bitcoin, every actor with quantum capability inherits the full historical exposure dataset.
How much Bitcoin is actually exposed today?
Estimates vary depending on how strictly "exposed" is defined, but the order of magnitude is consistent across independent on-chain analyses: roughly 25–30% of all Bitcoin supply sits in addresses whose public key is already on-chain.
That total is dominated by two categories:
- Satoshi-era P2PK outputs — roughly 1.7M BTC, immediately exposed and largely believed to be lost
- Reused P2PKH addresses from the 2010–2017 era — millions of additional BTC, much of it still active
The tail is concerning. Even a single exposed exchange or custodian address holding tens of thousands of coins represents systemic risk: a single quantum breach there is a price event for the whole market, not just for the address owner.
Is migration something I do now, or wait for a protocol upgrade?
Both, in sequence.
Today, the only thing a holder can do alone is move coins from exposed addresses to fresh, single-use addresses with high entropy. That reduces exposure from "public key on chain" (vulnerable to Shor's algorithm) to "only the hash on chain" (vulnerable only to Grover's algorithm, which is far weaker).
What still needs network coordination:
- Bitcoin Improvement Proposals (BIPs) to add post-quantum signature schemes (CRYSTALS-Dilithium, FALCON, or similar) at the protocol level
- Wallet and custodian tooling that can sign and verify the new scheme
- A coordinated migration window during which the network actively encourages moving from legacy to PQ addresses
That work is years out. The individual-holder mitigation isn't a substitute, but it does buy time and dramatically reduces blast radius if capability arrives sooner than expected.
Methodology
Applies Mosca's Inequality to decide whether data being collected today is at risk of being decrypted once a cryptographically relevant quantum computer (CRQC) exists.
- Mosca's Inequality
- X + Y > Z → you are already behind
- Risk Window
- W = max(0, (X + Y) − Z)
- Exposure Score
- E = W × sensitivity (sensitivity 0–10)
- CRQC Timeline Bands
- Z ∈ {conservative ≈ 25y, central ≈ 15y, aggressive ≈ 7y}
X = years data must remain confidential. Y = realistic migration time in your environment. Z = years until a CRQC. The verdict tells you whether to start now or whether you have slack.