The Bunker That Isn't There: Reading the Fine Print of Ethereum's Public-Key Warning

Look at an Ethereum address that has never signed a transaction. Its balance is public, but its public key is not. The chain exposes only a 20-byte hash — the Keccak-256 digest of a public key that has never left the wallet. Nobody engineered this as a privacy feature. It falls out of address derivation, an accident of the hash function's output length. And this past week, Justin Drake, a core researcher at the Ethereum Foundation, urged the industry to reorganize around that accident — proposing a "Bunker Mode" in which holders migrate assets to addresses that have never signed, hiding their public keys from a threat he attributes to artificial intelligence. That final attribution is where I stop nodding. The recommendation is sound and roughly as old as the curve itself. The threat model is where the story falls apart, and the gap between the two is not academic. It determines whether the industry spends the next decade building quantum-resistant rails or chasing a machine-learning ghost. An Ethereum address is not a public key. It is the last 20 bytes of the Keccak-256 hash of a public key. That distinction is the entire subject. As long as an address has never authorized an outbound transaction, the public key behind it has never been written to the ledger — only its hash. The moment the address signs anything, the full public key is published permanently, and every future observer can read it. This matters because of what a public key exposes. ECDSA — the signature scheme underneath Bitcoin, Ethereum, and nearly every EVM chain — rests on the elliptic curve discrete logarithm problem. Recovering a private key from a public key is, mathematically, solving ECDLP over the secp256k1 curve. For a 256-bit curve, that problem is considered infeasible under classical computation. This is not a design preference; it is the load-bearing assumption of the entire industry. Every wallet, exchange, and custodian that has ever broadcast a transaction has already published the public keys tied to its addresses. That data sits on-chain, archived forever, waiting for whoever solves ECDLP first. None of this is theoretical bookkeeping. The exposure is cumulative and permanent. A single outbound transaction from a cold wallet converts that wallet from a hash-protected address into a publicly readable public key, and no subsequent action can undo it. This is why the recommendation lands on never-signed addresses specifically: they are the last untouched reserve in a system that has been quietly publishing its keys since the genesis block. So Drake's underlying instinct is correct, and it is not new. Bitcoin's community has debated the exposure of early P2PK outputs for years — coins whose public keys were embedded directly in the locking script rather than hidden behind a hash. The "Bunker Mode" proposal is the Ethereum-flavored restatement of a known problem: unspent, never-signed addresses are the safest place to park value against a future cryptanalytic break. Having spent years dissecting signature schemes at the contract level, I treat the public-key exposure of any live address as a permanent, unhedged liability. What is new is the label on the threat. Here is where precision matters, because this industry rarely practices it. ECDLP is not solved by machine learning. It is solved — in theory — by Shor's algorithm running on a sufficiently large, fault-tolerant quantum computer. There is no published cryptographic result showing that any current deep-learning system can invert the one-way function at the heart of ECDSA. Neural networks are powerful pattern extractors. A 256-bit elliptic curve discrete logarithm is not a pattern; it is a problem structured so that no known classical or statistical shortcut applies. When a report attributes the threat to "AI," it is almost certainly compressing "AI-accelerated research into quantum computing" into a single syllable — or transcribing a fast news item past the point of accuracy. This is not pedantry. The two threats demand opposite responses on opposite timelines. A quantum break is a hardware milestone — detectable, dated, eventually announced by the labs that reach it. An AI break would be a mathematical revolution, and no evidence suggests one is underway. Treating them as interchangeable misallocates exactly the resource the warning means to protect: attention. Drake's own framing of the timeline deserves the same scrutiny as his threat label. He describes the window as "months," not years. That is a magnitude estimate, not a measurement, and it sits awkwardly against the physics: no publicly demonstrated quantum machine is within orders of magnitude of breaking secp256k1. If the threat is genuinely AI, the timeline is meaningless, because there is no mechanism. If the threat is quantum, "months" is almost certainly wrong by a wide margin. Either way, the number should not drive a holder's decision. There is a second problem, and the proposal quietly avoids it. The recommendation is to migrate assets "in an orderly fashion" to addresses that have never signed. But migration requires a signature. To move funds from an exposed address, you must authorize the transfer from that address — publishing the very public key you are trying to bury, at the exact moment you expose it. The new address stays clean; the old one is now definitively compromised. The security of the operation therefore depends entirely on sequencing: assume the old key is burned the instant the migration transaction is broadcast, and complete the move before any adversary can act on the freshly revealed key. Then there is MEV. A migration transaction is a signature broadcast into a public mempool, visible to every searcher and block builder before inclusion. Any holder migrating a large balance is announcing, in real time, that an exposed key is about to authorize a large transfer. The race conditions are not hypothetical; they are the ordinary mechanics of a transparent chain. And no standard tooling exists for any of it. There is no coordinated migration protocol, no agreed time-lock, no cross-wallet specification, no hardware-wallet support. "Bunker Mode" is a name for a problem, not a solution to it. Shifting the consensus layer, one block at a time, demands the missing specification — and it does not yet exist. The blind spot is not the threat. It is the language, and the language is what spreads. Once "Bunker Mode" becomes a phrase, it becomes a phishing template. A user who believes their assets are at risk of imminent compromise is a user primed to accept help. Fake migration tools, counterfeit "secure address" generators, impersonated foundation support accounts — these are the predictable next block. I have watched this pattern before. During the Terra collapse, panic produced more scams than the collapse produced losses. A security advisory that spreads faster than its own tooling is a vulnerability distribution channel. Notice, too, what the warning does not contain. No token, no protocol change, no code diff, no governance proposal. It is an opinion — a considered one, from a credible researcher, but an opinion nonetheless, not an Ethereum Foundation roadmap. Any project that repackages it into a "quantum-resistant" token narrative is borrowing credibility it did not earn. The code does not lie, but the auditor must dig — and here the digging reveals an empty treasury of implementation. There is also an operational hazard the advisory never names: a wave of large, coordinated migrations could read to exchange risk engines and chain-analytics platforms as anomalous activity — funds moving en masse to fresh, never-signed addresses looks, to a fraud model, like laundering. Holders who migrate without warning their custodians may find accounts frozen mid-flight. Track the hardware, not the headline. Watch for quantum-logic-qubit milestones, for a foundation-authored migration specification, and for the first standardized signing-time-lock proposal. Until those exist, "Bunker Mode" is a warning without a workshop. Tracing the gas trails back to the root cause leaves a clear signal: the threat is real, the timeline is not, and the most dangerous artifact this week is a phrase that tells holders they are unsafe — without telling them, precisely, how to move.