Trust is not a virtue; it is an unpatched port. Europol said the quiet part out loud last week, and the market read it backwards. The agency's line — that quantum computing will not "break Bitcoin," but that some wallets are already exposed — was filed under reassurance. It is not reassurance. It is a two-part admission wearing the mask of a single sentence. The first half is a claim about consensus. The second half is a claim about you. They are not the same claim, and conflating them is the exact error that turns a twenty-year engineering problem into a twenty-minute panic.
I have spent the better part of a decade pulling apart cryptographic assumptions that people assume are load-bearing, and the pattern never changes. The industry hears "won't break" and stops listening. It never hears the comma. That comma is where the real exposure lives.
Context: A Standard Nobody Migrated To
To understand why Europol's statement is internally consistent, you have to separate two things that share the same four letters — cryptography — but almost nothing else at the implementation layer.
Bitcoin rests on two distinct families of primitives. The first is a signing scheme: ECDSA, and since the Taproot upgrade, Schnorr signatures over the secp256k1 elliptic curve. The second is a hash function: SHA-256, which secures proof-of-work and the block chain of hashes that gives the ledger its name. These two families respond to quantum attack in fundamentally different ways, and the entire "will quantum kill Bitcoin" debate collapses the moment you stop treating them as one system.
This is not a new observation. It is, however, an observation that gets buried every time a hardware vendor posts a milestone on LinkedIn and the timeline lights up with doom threads. The gap between the technical reality and the narrative is where I do most of my work, and this story is a textbook case.
In 2024, NIST standardized the first tranche of post-quantum cryptographic algorithms — ML-DSA (formerly Dilithium), SLH-DSA (formerly SPHINCS+), and ML-KEM. These are real, peer-reviewed, deployable signature and key-encapsulation schemes designed to resist both Shor's and Grover's algorithms. The tools exist. The migration has not started. Bitcoin, as of this writing, has no active BIP for a post-quantum signature path, no consensus-level commitment to one, and no timeline. That asymmetry — mature algorithms on one side, zero migration on the other — is the actual headline, and it is the headline nobody printed.
So when Europol speaks, we should read it as a statement about where the risk actually sits: not in the mining layer, not in the consensus rules, but in a specific, enumerable set of on-chain outputs whose public keys are already public. That is the whole story. Everything else is noise.
Core: The Teardown
Signature versus hash — the fork in the road
Shor's algorithm solves the integer factorization and discrete logarithm problems in polynomial time on a sufficiently capable quantum computer. secp256k1's security reduces to the elliptic curve discrete logarithm problem. Therefore, a cryptographically relevant quantum computer (a CRQC) running Shor's algorithm can recover a private key from a public key. That is the high-severity threat. Full stop.
Grover's algorithm, by contrast, provides only a quadratic speedup for unstructured search. Applied to SHA-256, it effectively halves the security margin in bit terms — a 256-bit hash behaves like a 128-bit hash against a quantum adversary. This is a nuisance, not an apocalypse. You can respond by increasing entropy, adjusting difficulty, or simply accepting it, because 128 bits of quantum security is still computationally out of reach for any realistic adversary. Mining does not collapse under Grover. Proof-of-work does not evaporate.
This is why Europol's "won't break Bitcoin" clause is technically defensible — if, and only if, it refers to the consensus and mining layers. The hash-based spine of the protocol survives the quantum transition largely intact. The signature layer does not. Logic dissolves when code meets human greed, but here the inverse holds: logic dissolves when humans collapse two threat models into one word.
The exposure surface is a public key that already shipped
Here is the mechanism that the panic threads miss. Shor's algorithm needs a public key. If your public key has never appeared on-chain, a quantum adversary has nothing to attack — the hash of your public key is a one-way function that Shor's algorithm does not help with. Cold storage of an unspent, never-revealed address is, in the quantum sense, structurally safe.
The danger is not holding Bitcoin. The danger is having held Bitcoin in a way that printed your public key to the ledger permanently. There are three categories here, and they matter in descending order of severity.
First: P2PK outputs. Pay-to-Public-Key outputs, common in the earliest blocks, embed the full public key directly in the locking script. There is no hash step. The public key is simply sitting there in plaintext, hashed into the chain forever. Every P2PK output is a standing invitation with the envelope already open. Satoshi's own early coins, to the extent they sit in P2PK outputs, are in this category — and yes, that includes the roughly one million coins widely attributed to the founder. The symbolic weight of that particular exposure exceeds its dollar value, which is precisely why it is the scenario nobody wants to model out loud.
Second: address reuse. Every time you spend from an address, you reveal the public key associated with it. If you then keep funds at that same address, those funds are now sitting behind a public key that a CRQC could, in theory, derive the private key from. Reused addresses are the most common form of self-inflicted exposure, and they are the reason "just use a wallet" is not a security strategy. It is a hope.
Third: Taproot (P2TR). This one is the counterintuitive piece. Taproot uses x-only public keys, and those keys are visible on-chain the moment the output is created — even before it is spent. That is a deliberate design tradeoff for privacy and efficiency, and it is defensible on its own terms. But it means a fresh Taproot address is not the "cold" address people assume it is. It is exposed on creation. The most modern address format in Bitcoin is, in the quantum sense, the least patient.
If you want a rough sense of scale: industry estimates typically cite low single-digit millions of BTC sitting in P2PK outputs and reused addresses combined, with the Satoshi-attributed stash comprising a meaningful fraction of the uncertainty. I would put low confidence on any specific number — the methodologies vary, and the patoshi-pattern attribution is contested. But the order of magnitude is not in dispute. We are talking about a non-trivial slice of the total supply sitting behind public keys that are already public.
What the migration actually requires
Suppose the community agreed tomorrow that Bitcoin needs a post-quantum signature scheme. What happens next is the part that should temper every timeline you read.
A change to the signature layer is a consensus change. Consensus changes in Bitcoin go through the BIP process: proposal, discussion on the developer mailing list, review, rough consensus, then a soft or hard fork depending on the nature of the change. This is not a committee that can ship a patch on a Tuesday. It is a coordination problem with no central authority, thousands of independent node operators, and a cultural memory of every contentious fork in the protocol's history. That decentralization is the source of Bitcoin's security — and it is simultaneously the reason a cryptographic migration is measured in years, not quarters.
I have audited enough systems to know that the hard part of a migration is almost never the cryptography. The cryptography is the easy part. ML-DSA is standardized. SLH-DSA is standardized. The hard part is the human layer: reaching consensus, coordinating the upgrade, deciding what to do with legacy outputs, and — this is the unresolved one — deciding what to do with coins whose public keys are already exposed and whose owners may no longer exist. Do you freeze them? Do you let them be claimed by whoever gets a CRQC first? Do you do nothing and hope? There is no clean answer, and the absence of a clean answer is why no BIP exists.
Complexity is just laziness wearing a mask. And the deepest complexity here is not technical. It is governance.
The honest timeline
Here is where I will be cold, because the discourse is not. Breaking secp256k1 with Shor's algorithm requires millions of physical qubits operating with error correction — not the noisy few-hundred-to-few-thousand physical qubit devices that dominate today's headlines. The gap between current hardware and a CRQC is several orders of magnitude, and the leading mainstream estimates place a CRQC on a ten-to-twenty-year horizon, with optimistic scenarios landing somewhere in the 2030s. Those estimates could be wrong in either direction. Hardware progress is not linear, and "we haven't hit it yet" is not a proof of impossibility.
But notice what this timeline does to the two halves of Europol's sentence. The consensus layer has twenty years of slack. The exposed-key problem has zero years of slack, because the exposure already happened. The clock on the exposed wallets did not start when the quantum computer arrived. It started when the public key was published. We are already inside the window. We just have not felt the pressure yet.
I spent six weeks in 2018 reverse-engineering the 0x protocol's v1 contracts, mapping every reentrancy vector I could find. Twelve critical logic flaws, three patched before mainnet. What that exercise taught me is that the elegant designs fail first, because elegance assumes the environment is as clean as the code. The Bitcoin signature layer is an elegant design. It assumes the adversary is classical. That assumption is correct today and false eventually, and the transition between those two states is the entire risk.
The AI-oracle shadow
One more thing, because it connects. In 2025 I spent six months reverse-engineering a major oracle network's off-chain computation model and found a centralization risk in the node selection algorithm. The lesson generalizes: the next generation of systemic failures will not come from a single broken primitive. They will come from the composition of automated agents, latency-sensitive data feeds, and trust assumptions that were never audited because everyone assumed they were somebody else's problem. A CRQC is the ultimate composable threat — it does not need to break every wallet, only the ones that are exposed and economically worth targeting. Adversaries optimize. They will not attack the herd. They will attack the stragglers.
Silence in the blockchain is louder than the hack. The exposed P2PK outputs have been silent for fifteen years. That silence is not safety. It is latency.
Contrarian: What the Bulls Actually Got Right
I am going to defend the other side for a paragraph, because the reflexive cynicism of my own genre is its own kind of laziness.
The bulls are right about one thing, and it is the most important thing: this is not an emergency. The probability of a CRQC breaking secp256k1 in the next five to ten years is low, and anyone selling you urgency is selling you something else. The mining layer genuinely survives. The consensus rules genuinely survive. NIST genuinely shipped the algorithms. The engineering path exists and is not speculative. If you hold Bitcoin in a never-spent, never-reused address, you are genuinely not in the exposed cohort, and no amount of doom-posting changes that.
The blind spot is subtler than the panic, and that is what makes it dangerous. The bulls correctly say "quantum won't break Bitcoin" and then stop. They do not say "but address reuse already exposed a slice of the supply, and the governance path to fix it does not exist." The first statement is true. The second is also true. Holding only the first is how a rational community walks into a structural problem with its eyes open and its attention elsewhere.
Every summer has a winter of truth. The quantum narrative is a long, intermittent cycle — it re-ignites every time a hardware vendor posts a milestone, and it goes quiet in between. The danger is not the spike. The danger is the quiet, because the quiet is when the exposed addresses stay exposed and the BIP stays unwritten.
Takeaway
The operational advice is boring and it is the only thing that matters right now. Stop reusing addresses. Migrate holdings away from any address whose public key has ever been revealed on-chain. Understand which address type you are actually using — P2PKH and P2WPKH keep your key hidden until you spend, P2TR does not. Treat the migration as a personal responsibility, because Europol just told you it is one: the agency's framing explicitly pushes the burden down to individual users, which is a polite way of saying the wallet and custody layer has not shipped you a solution and is not going to soon.
The forward-looking question is not "when will quantum break Bitcoin." It is "who is accountable for the exposed coins, and who decides." That question has no owner. In a system defined by the absence of an owner, that is the vulnerability that survives every patch — the one that is not in the code, but in the coordination. Trust is a vulnerability we audit, not a virtue. And right now, on this specific issue, nobody is holding the clipboard.
