Can AI recover a wallet private key? The proof that is still missing

The October 7 warning about AI and cryptocurrency private keys asked people to prepare for a possible mathematical breakthrough, not to respond to a demonstrated wallet exploit. Ethereum researcher Justin Drake described a worst case in which a large GPU cluster could recover a private key from an exposed public key in roughly a week. No reproducible algorithm, test result or affected wallet accompanied that scenario. Contemporaneous reporting preserves the distinction.

It is still a question worth investigating because a public-key break would bypass the security of even a properly managed private key. But the history of cryptocurrency key failures points to other mechanisms with different prerequisites. Some have already recovered signing keys from public transaction data; AI-connected software can also move funds without deriving or seeing a key at all. The difference determines what should be tested, what can be protected and whether moving funds accomplishes anything.

On October 6, OpenAI published mathematical manuscripts and proof artifacts generated with an internal model. The release demonstrates work in mathematical research, but its announcement does not claim to solve elliptic-curve discrete logarithms or break a wallet signature scheme. Drake's October 7 suggestion was an extrapolation: perhaps increasingly capable systems will discover a classical shortcut to a problem cryptographers currently regard as computationally infeasible.

The underlying repository makes an instructive contrast between a candidate result and a verified one. Its October 7 correction history documents three withdrawn manuscripts following a sign error affecting related proofs, plus revisions to fourteen others. The maintained count was 719 manuscripts, with 300 top-line results formalized at that point. These corrections do not invalidate the remaining work; they show why publishing mathematical material is not the same as validating a specific security consequence.

The disagreement is partly about how to respond to low-evidence, high-impact possibilities. The Block reported that Coinbase cryptography head Yehuda Lindell challenged the suggestion that AI progress constituted evidence of weakening elliptic-curve assumptions, while Dragonfly's Haseeb Qureshi supported cautious preparation. Vitalik Buterin also urged attention to the possibility while warning against rushed wallet migrations. Their original X exchanges were not independently accessible for this review, so these positions are attributed to the reporting rather than authenticated as directly reviewed posts.

An ordinary elliptic-curve signing key consists of a secret scalar d and public point Q, connected by Q = dG, where G is the curve's fixed generator. The computation from d to Q is straightforward. Recovering d from a healthy secp256k1 point is the elliptic-curve discrete-logarithm problem, for which general classical attacks require on the order of 2^128 group operations. Bitcoin's BIP 340 describes the corresponding 128-bit classical-security design target.

A one-week recovery on available GPUs would require a radical improvement in algorithmic efficiency or a weakness in the problem actually being solved. Faster model inference alone does not produce that method. Nor is a hypothetical attack on ECDSA signature generation automatically a general secp256k1 discrete-logarithm solution: ECDSA and Bitcoin's Taproot Schnorr signatures share a curve, but their signing rules differ. A successful attack against secp256k1 also would not, without further analysis, prove an attack on Solana's Ed25519 signing keys. The reusable threat model is described in the key-recovery Concept.

These are not three descriptions of the same vulnerability. In particular, the ECDSA signing nonce is a temporary cryptographic value, not the transaction sequence number that some blockchains also call a nonce.

In Biased Nonce Sense, published at Financial Cryptography in 2019, Joachim Breitner and Nadia Heninger studied publicly observable ECDSA signatures. ECDSA uses a secret per-signature value k. If a signer reuses k on two different message hashes, the public signature equations can expose k and then the permanent private key d. Several signatures with sufficiently short or correlated values of k can also permit lattice attacks, even though the underlying curve's general discrete-logarithm problem remains hard.

The authors' September 13, 2018 Bitcoin snapshot held 975,560,082 signatures from 446,605,479 distinct public keys. They recovered 302 distinct Bitcoin private keys through short or structurally biased nonces. Table 1 places 280 of these in the 64-bit-nonce category, and 279 of those 280 keys had been used in multisignature addresses. Across the 302 keys, the researchers identified 6,026 signatures with the vulnerable nonce patterns. Their Bitcoin computation took approximately 38 CPU-years, not a week on a commodity computer. These are counts within the studied historical dataset and attack methods, not an estimate of the share of all wallets vulnerable today.

A multisignature connection is also not equivalent to a wallet drain. Some addresses require multiple independent valid signatures, so deriving one component key does not establish that an adversary could satisfy the particular threshold. Conversely, a one-signature threshold offers no such additional requirement. The paper identifies the vulnerable keys and discusses balances that could be claimed, but the researchers state that they did not execute cryptocurrency transactions or active attacks themselves.

In a separate Ethereum analysis, the same authors recovered one key associated with signatures sharing a 192-bit nonce prefix and three keys affected by repeated nonces. Bitcoin.org's 2013 Android-wallet warning supplies an earlier, operational example of deficient randomness that required software changes and key rotation. RFC 6979 offers deterministic nonce generation to remove dependence on fresh per-signature randomness. It cannot restore a key already leaked by bad signatures, prevent malware copying a seed, or defend a curve whose mathematical assumption has genuinely failed.

The historical finding therefore demonstrates real private-key recovery, but it has a precise input condition: defective signatures. Calling it proof that AI can invert an arbitrary healthy public key would discard the reason the attack succeeded.

A public wallet address is not necessarily a public elliptic-curve point. The relevant material depends on the address construction, whether it has signed and what controls the funds.

The underlying protocol details appear in Ethereum's account-signature guidance, BIP 141, Taproot's BIP 341 and Solana's account documentation. Solana program-derived addresses have no ordinary corresponding signing private key; smart-contract and multisignature accounts on other chains also require analysis of their actual controllers, not just their displayed address.

There are two important limits to the table. A key may have signed an off-chain message even if its receiving address has never sent a transaction. Also, moving coins to a new address does not cure compromised recovery material or make a wallet post-quantum. The relevant question is whether the particular controlling public point is exposed and which signature assumptions protect it.

The first clock starts when a public key becomes visible; the second measures how quickly an attacker could recover its secret. Fireblocks research VP Michael Gutkin's October 8 analysis explains the operational difference for Bitcoin P2PKH and P2WPKH. An unused key can remain concealed behind a hash, but spending reveals it in the transaction, including during propagation through the mempool.

If a hypothetical attack needs one week per key, a typical spending transaction will be confirmed or otherwise resolved long before a newly exposed key can be used for a competing spend in that same short window. An attack taking minutes could create a different scenario: recovery while the transaction is pending, followed by an attempted conflicting spend. Both durations are thought experiments, not demonstrated recovery benchmarks.

That does not make week-long recovery harmless once a point has been exposed. If a Bitcoin address is reused, or change returns to a previously disclosed key, spendable funds may remain under an exposed public key long after the original transaction confirms. Ethereum EOAs commonly continue to hold and receive assets after their first public signature. Taproot outputs, meanwhile, expose an x-only point at creation. Exposure timing, recovery speed and whether value remains controllable by that key must all be evaluated together.

Fireblocks describes address and change rotation for its own custody product, including operational dependencies in accounting and reconciliation. Its defaults are not a statement about every Bitcoin wallet, and its article is vendor analysis rather than independent cryptanalysis. Rotation may reduce the visible-point surface under a narrowly defined future attack. It cannot guarantee safety against a sufficiently fast break or substitute for a protocol-supported change of signature scheme. A hasty migration can introduce immediate signing, address or custody mistakes that are absent from the speculative attack.

Two existing DiggingBeagle dossiers clarify why wallet security cannot be reduced to cryptanalysis. In the May 4 Bankr/Grok case, SlowMist and Fireblocks describe a transfer of about 3 billion DRB after attacker-controlled text crossed a model-to-Bankr authorization path. The public reconstruction involves Bankr's transfer-capable infrastructure, not mathematical recovery of a signing secret. The transferred token count should not be converted to a fixed fiat loss without accounting for price and recovery.

SafeDep's Polymarket package investigation identified nine malicious npm packages, including two named for AI-assisted workflows, that shared code designed to collect Ethereum private keys and send them to attacker infrastructure. The documented install path depended on an interactive terminal; the published analysis does not establish a confirmed victim wallet drain or prove that a model hallucinated the package names.

These mechanisms belong in the same security discussion because operators may reasonably ask whether AI increases the risk to wallet-controlled funds. They do not belong in the same cryptographic category. In one, untrusted language reached a signer with existing authority. In the other, malicious software could obtain raw secrets. The controls are policy-enforced transaction approvals, provenance checks and separation of development tools from signing material, rather than a novel mathematical signature scheme alone.

Shor's algorithm establishes a theoretical quantum approach to elliptic-curve discrete logarithms, but Drake's October warning concerned a classical shortcut possibly discovered by AI. A September 2026 trapped-ion preprint estimated 19,397 physical qubits and 25.7 days for a secp256k1 computation, with modeled 63 percent success. Those figures describe a proposed future architecture, not an executed attack or evidence that GPUs can recover keys.

Post-quantum migration also requires precision. NIST's signature standards distinguish lattice-based ML-DSA from the hash-based SLH-DSA standard. A hypothetical weakness in one assumption family does not establish a weakness in another. Changing schemes affects verification rules, signature sizes, wallet interfaces, recovery and protocol compatibility; none of these changes prevents an authorized but misdirected agent from approving the wrong payment.

A credible escalation would identify the curve, signature scheme and public inputs, publish an executable or independently reproducible method, and state measured computation, hardware and success rate. Verification would then establish whether researchers recovered a private scalar from a healthy public point, exploited biased signatures, forged only a particular signature type, accessed a side channel or simply obtained a stored secret. Those outcomes imply different affected populations and different repairs.

In the meantime, operators can inventory public-point exposure, track signing-key reuse, assess change-output and address-rotation behavior, inspect how development agents and connectors reach signers, and rehearse deliberate migration paths supported by their actual wallets. Each action addresses an identifiable condition; none should be sold as evidence that the proposed AI break has happened.

As of the October 8 evidence cutoff, the OpenAI mathematics release and the reported Drake/Buterin debate justify examining the assumption behind signing keys. The 2019 study proves that private keys have been recovered from defective public signatures, while recent agent incidents show that financial authority can fail elsewhere. They do not jointly establish an AI-enabled classical attack against correctly generated secp256k1 or Ed25519 signing keys.