Can AI Hack Bitcoin and Ethereum Wallets? What the Evidence Actually Shows

No publicly demonstrated AI attack can recover an arbitrary, properly generated Bitcoin or Ethereum private key from its public key. The October 2026 warning about cryptocurrency entering "bunker mode" concerns a possible future mathematical breakthrough, not an observed defeat of Bitcoin’s or Ethereum’s core wallet-signing systems.

The warning is nonetheless worth examining. AI systems have already helped researchers discover meaningful weaknesses in other cryptographic designs. And public blockchains preserve the information an attacker might need if the mathematics protecting exposed public keys were ever defeated. Some Bitcoin outputs reveal public keys as soon as they are funded; others conceal them until spending. Ethereum accounts, smart-contract wallets and validators present different problems again.

The central question is not simply whether AI is getting better at mathematics. It is which cryptographic assumption would have to fail, which assets would then be exposed, how fast an attack could run, and whether a proposed defense changes any of those conditions.

The findings at a glance

Why did Justin Drake warn about crypto "bunker mode"?

The immediate trigger was OpenAI’s October 6 release of AI-generated mathematical research. The following day, Ethereum Foundation researcher Justin Drake urged the blockchain industry to begin planning for "bunker mode", according to his public statement and contemporaneous reporting by The Block.

Drake’s argument was a risk scenario: AI-assisted mathematical discovery might find a practical method for recovering private keys from public keys on ordinary computing hardware, possibly before powerful quantum computers arrive. His worst-case horizon was months rather than years. He described a potential break as private-key recovery within roughly a week using available hardware, such as a large GPU cluster. Neither estimate was presented as an observed attack or an established forecast.

He urged large, sophisticated holders to consider a controlled movement of funds toward fresh addresses whose public keys remain concealed behind hashes, and cautioned against hurried transfers. Importantly, this recommendation does not apply equally to every Bitcoin address format or every Ethereum account.

The reaction exposed a legitimate disagreement about precaution, rather than a dispute about a proven exploit:

Ethereum co-founder Vitalik Buterin also acknowledged risks from faster AI-assisted mathematics while warning that poorly executed wallet migrations can cause immediate, irreversible losses. Lindell, Coinbase’s head of cryptography, argued that the new mathematics was not evidence that decades-old elliptic-curve hardness assumptions had failed. Those positions are not equivalent claims about an attack: the public evidence supports the narrower conclusion that no practical general key-recovery break has been demonstrated. The Block documented the differing responses.

Did OpenAI’s 372 mathematics results break Bitcoin cryptography?

No. The 372 figure refers to families of mathematical results, not 372 verified ways to hack cryptocurrency.

OpenAI’s mathematics repository originally contained 722 manuscripts grouped into 372 families. A family can contain a main result, related arguments, consequences or alternate proofs. Following the October 7 withdrawal of three manuscripts, its catalog reported 719 manuscripts in 372 families.

The October 7 revision record also documents repairs or substantive corrections to 14 other manuscripts, updates to citations in 13 more, and an increase to 300 of 719 top-line results with formalizations, approximately 42%. OpenAI itself cautions that some unformalized results may contain problems.

Those distinctions matter:

• A manuscript is a research write-up, not necessarily an independent discovery.
• A result family groups related work; it is not a count of cryptographic systems defeated.
• A Lean formalization provides machine-checkable reasoning for the result that was formalized, subject to the definitions and assumptions used. It does not automatically establish every claim elsewhere in a manuscript.
• Independent mathematical acceptance requires scrutiny of statements, assumptions, proofs, novelty and significance. Public release alone does not provide that acceptance.

The withdrawn papers concerned an error in work on algebraic geometry, not a demonstrated compromise of cryptocurrency signatures. The most important negative finding is straightforward: the reviewed release does not publish a practical algorithm for solving the secp256k1 elliptic-curve discrete-logarithm problem or recovering arbitrary Bitcoin and Ethereum wallet keys.

That does not mean future AI-assisted discoveries are impossible. It means the October 2026 release cannot responsibly be described as proof that such a break is imminent.

Has AI already discovered real cryptographic weaknesses?

Yes, but the specific algorithms and consequences matter.

On July 28, 2026, Anthropic reported that its Claude Mythos Preview model helped discover a substantially improved attack against HAWK, an experimental lattice-based, post-quantum digital-signature candidate. The research identified an exploitable mathematical property of that scheme. Anthropic also reported an improved attack on a deliberately weakened, seven-round version of AES, not the full AES cipher used in production.

In its technical account of the HAWK research, Anthropic said the improved attack substantially reduced the expected security of smaller HAWK parameters. The U.S. National Institute of Standards and Technology confirmed that HAWK’s developers withdrew the candidate from its additional-signature standardization process.

This is more substantial evidence than a general assertion that AI is good at math. Researchers identified a previously unexploited cryptanalytic route, published the result and prompted a concrete change in a standards process.

But three limits are essential:

1. HAWK was a candidate, not Bitcoin’s ECDSA or Taproot’s Schnorr system.
2. The attack did not break NIST’s finalized post-quantum standards. NIST explicitly says its finalized standards, including ML-KEM and ML-DSA, are unaffected by this HAWK result.
3. The new HAWK attack does not establish a timeline for solving secp256k1. Different cryptographic schemes rely on different assumptions and structures.

AI can already affect cryptocurrency security through a separate route: ordinary software and smart-contract vulnerabilities. In December 2025 research on the SCONE-bench benchmark, Anthropic and collaborators reported that AI models developed simulated exploits worth a combined $4.6 million against a subset of historically exploited smart contracts selected to reduce training-data contamination. The tests ran in controlled blockchain environments; that dollar figure was not verified live theft by those models.

A smart-contract exploit is not a mathematical defeat of the private keys that authorize a Bitcoin transaction. Confusing these threats makes both harder to understand.

How could an AI recover a Bitcoin or Ethereum private key?

Bitcoin and conventional Ethereum accounts use digital signatures to authorize transactions. The coins or tokens are recorded on the blockchain; a wallet holds or controls the signing secrets used to move them. This is not the same as encrypting a balance and then decrypting it.

For a typical elliptic-curve key pair, a private number is used to calculate a corresponding public point. The forward computation is easy. The reverse problem — determining the private number from that public point — is the elliptic-curve discrete-logarithm problem, or ECDLP. Its presumed difficulty is a foundational security assumption behind several widely deployed signature systems.

A hypothetical broad key-recovery attack would have the following sequence:

1. An attacker obtains the relevant public key, either from a blockchain record, a transaction signature, an exported wallet descriptor or another source.
2. An algorithm makes recovering the associated private signing value practical on available hardware.
3. The attacker uses that recovered secret to produce valid signatures authorizing a transfer or another protected action.
4. Funds or permissions remain under the compromised key when the forged authorization is accepted.

All four conditions matter. An exposed public key is not currently a stolen private key. A key with no remaining spendable funds is not, by itself, an opportunity to steal that address’s old balance. And an attack that requires days has different consequences from one that finishes before a transaction confirms.

The distinction between AI and quantum computing is equally important:

An AI model also cannot obtain a well-generated private key merely by "guessing harder." Weak random-number generation, reused signing nonces, exposed seed phrases and malicious applications are separate failures. A successful attack through any of those routes does not prove that the underlying elliptic-curve problem has been solved.

Which Bitcoin wallet addresses expose their public keys?

Bitcoin address types do not provide identical protection against a future attack on exposed public keys. Some contain a hash or a commitment and disclose signing keys only when spent. Others place a usable elliptic-curve public key directly in the funded output.

The most relevant specifications are BIP 141 for Segregated Witness, BIP 340 for Schnorr signatures and BIP 341 for Taproot. The draft BIP 360 proposal also explicitly distinguishes these exposure patterns.

Two technical corrections prevent a misleading reading of this table.

First, Taproot does not use ECDSA for its key-path signatures. It uses the Schnorr signature design standardized by BIP 340. Both Schnorr and Bitcoin’s traditional ECDSA system use the secp256k1 elliptic curve. A bug unique to an ECDSA signing implementation would not necessarily affect Taproot. A sufficiently general practical break of the curve’s discrete-logarithm problem would threaten both.

Second, "never spent" does not always mean "public key undisclosed." Taproot outputs expose their output key upon funding. A holder may also have disclosed a key through signed messages, an exported extended public key (xpub), a wallet descriptor or another system. BIP 32 additionally explains why extended keys create their own security considerations: in certain non-hardened derivation configurations, a parent extended public key combined with a compromised child private key can expose a larger branch of the wallet.

An address prefix alone is not a comprehensive security audit. In particular, bc1q can describe more than one output type, and a script-based wallet requires examination of its actual spending conditions.

Why transaction timing changes the risk

There are two conceptually different attacks:

Long-exposure attack: The public key already appears in a funded output, a previous spend or another permanent record. An attacker could work against it for an extended period while the key continues to authorize funds. Early P2PK outputs, funded Taproot outputs and reused signing keys fit this scenario.

Short-exposure attack: A spending transaction reveals a previously hidden key while it is pending. An attacker would need to recover the private key and successfully redirect or replace the spend during a much narrower window. Hiding the key until the first spend does not eliminate this possibility if key recovery eventually becomes fast enough.

The BIP 360 authors explicitly distinguish these cases. A week-long hypothetical key-recovery operation and a sub-minute one are not equivalent threats. Nor does confirmation of the original spend restore secrecy to the public key: it remains in the historical record, although any fully spent output no longer contains coins.

How much Bitcoin is associated with exposed public keys?

The clearest publicly accessible snapshot identified for this briefing is Project Eleven’s Bitcoin Risq List.

This is a substantial conditional exposure measure, not a report of compromised coins. The dataset identifies balances that its rule-based analysis associates with publicly exposed elliptic-curve key material. It does not demonstrate that an AI can presently recover those keys. It also does not mean 14.58 million unique people or independently compromised wallets.

Project Eleven has released its Bitcoin Risq List methodology and SQL query, allowing outside researchers to inspect its onchain classification approach. Its published totals should still be attributed as Project Eleven’s estimates, rather than presented as a separately reproduced audit. The total can change as UTXOs are spent and new outputs are created. Offchain disclosures may be absent from onchain classification, and script or custody structures introduce exceptions.

Conflict-of-interest disclosure: Project Eleven also sells post-quantum security products and services, including wallet-related offerings. Its commercial interest does not invalidate the underlying public blockchain data, but it is relevant when interpreting labels such as "at risk." The figure was developed around a future quantum key-recovery threat; applying it mechanically to any particular AI/ECDSA-only scenario would be incorrect, especially because Taproot uses Schnorr rather than ECDSA.

It would therefore be misleading to write either "AI can steal 8.18 million BTC" or "8.18 million BTC is currently hacked." Neither follows from the evidence.

Could the same breakthrough affect Ethereum, stablecoins and validators?

Yes, but different parts of Ethereum depend on different cryptographic systems. A failure in one signature algorithm would not automatically have identical consequences for every account, validator or proof system.

Ethereum externally owned accounts (EOAs)

An ordinary Ethereum EOA uses ECDSA over secp256k1. Its address is derived from a hash of the public key, not a plain copy of that key. As Ethereum’s account documentation explains, signatures allow the public key to be recovered.

An account that has only received ETH and has never signed anything may therefore have an additional layer of protection against an attack requiring a known public key. Once it signs a transaction, the key becomes recoverable from that signature. And offchain signed messages or activity on other networks using the same key can also disclose relevant public-key information. An account’s Ethereum mainnet transaction count is not a complete record of every place its key might have been used.

If that EOA’s signing secret were recoverable, the consequences could extend to ETH, ERC-20 tokens such as stablecoins, NFTs and DeFi permissions controlled by the account. A private-key compromise is an authorization problem, not a vulnerability limited to the coin used for transaction fees.

Smart-contract wallets, multisig and custodians

A smart-contract wallet does not necessarily rely on one ordinary EOA signature. It may require multiple signers, specialized validation, time delays, spending limits or upgradeable authentication logic. That can change the attacker’s requirements. But a contract wallet is not automatically safe merely because it is called a smart wallet: its controlling keys, implementation, recovery paths and upgrade permissions must be assessed.

Multisig protection likewise depends on which keys are exposed and whether an attacker could meet the authorization threshold. Exchange-held assets add another layer: a customer often does not control an individual onchain private key, while the custodian’s signing architecture and operational controls determine its exposure.

Ethereum proof-of-stake validators

Validator signing keys are a separate security domain. Ethereum uses BLS signatures for validator proposals and attestations, and validator public keys are included in staking deposit data.

A break of ECDSA alone would not automatically prove a break of BLS. Conversely, a breakthrough affecting the relevant BLS key problem could enable malicious validator signatures, unauthorized actions or slashable behavior. It would not automatically give an attacker withdrawal control over every validator’s ETH. Withdrawal credentials and execution-layer payout addresses have distinct control arrangements.

Ethereum also uses KZG commitments and various zero-knowledge proof systems that present separate migration challenges. The Ethereum post-quantum security roadmap identifies account signatures, BLS consensus, data commitments and proof systems as different workstreams. Collapsing them into "Ethereum encryption" obscures the actual risks.

Why this could become an infrastructure problem

Individual wallet theft is only the first level of the threat. At a broader level, stolen administrator keys could affect token issuers, bridges, smart-contract upgrades or exchange-controlled reserves. A sufficiently broad cryptographic failure could interfere with validator consensus and transaction settlement. In that scenario, moving a personal balance is not an adequate substitute for coordinated protocol upgrades and custody-system controls.

This is also why dormant, exposed-key balances matter beyond the person who owns them. A future attack against old, immobile holdings could create market and governance consequences even if active users had already migrated. That is a scenario analysis, not a prediction of a specific attack or market outcome.

Should you move crypto to a new wallet, use a hardware wallet or switch to Taproot?

There is no evidence-based instruction for every holder to move funds immediately. The right decision depends on the key’s exposure, the wallet’s design, the attack being considered and the risks introduced by the transfer itself.

A sensible immediate posture is to review existing wallet hygiene before undertaking irreversible movement of funds. Stop unnecessary address reuse, verify how the wallet generates change and receive addresses, keep software updated, protect backups, and make a written migration plan for material institutional holdings. Use official instructions from the specific wallet provider and, when moving substantial sums, independently verify destination addresses and conduct a small test transfer where appropriate.

Do not enter a seed phrase, private key, recovery file or signing secret into an online "AI risk," "quantum exposure" or "bunker mode" checker. A legitimate public-blockchain address lookup does not need those secrets. Do not approve an unexpected wallet connection or signature request merely to obtain an exposure score.

For an ordinary holder with no evidence of key compromise, an unfamiliar emergency migration may be more dangerous in the immediate term than the hypothetical general mathematical attack. For an institution managing large exposed-key reserves, carefully planned exposure reduction may be reasonable as part of broader security and continuity planning. These are different decisions.

Can Bitcoin and Ethereum upgrade before a cryptographic break?

The relevant question is no longer whether post-quantum algorithms exist. It is how blockchains migrate users, validators, scripts, wallets and infrastructure without creating new failure modes.

Bitcoin: BIP 360 is a draft, not a deployed cure

Bitcoin Improvement Proposal 360, titled Pay-to-Merkle-Root (P2MR), proposes a new output type that removes Taproot’s key-path spending option while retaining script-tree functionality. The goal is to avoid exposing a long-lived, spend-authorizing elliptic-curve public output key merely by funding an output.

This is important, but its limits are explicit in the proposal itself:

• BIP 360 remains a draft. It is not an activated Bitcoin consensus rule.
• It primarily targets long-exposure attacks. Its protections depend on the scripts and keys actually used, and on not exposing them in ways that defeat the intended protection.
• It does not by itself deliver fully post-quantum signatures or eliminate short-exposure attacks. Protecting against very fast key recovery after a spend becomes visible may require additional signing-system changes.

Bitcoin consensus changes also require engineering, implementation, testing and adoption. A draft mitigation does not instantly move old coins or solve the problem of owners who can no longer access dormant wallets.

Ethereum: a 2029 target, with major work remaining

The Ethereum Foundation’s September 7, 2026 protocol priorities set a target of December 2029 for quantum resistance across Ethereum’s execution, consensus and data layers. The Foundation treats a possible "Q-day" as early as 2030 as a deliberately aggressive planning assumption, not as a confirmed date.

The roadmap includes account-signature flexibility, hash-based validator-signature research, new consensus aggregation methods and changes to data commitments. Native account abstraction is intended to let account authorization evolve without requiring a fresh hard fork for every signature scheme. The Foundation also acknowledges that its minimum-viable fallback would carry reduced guarantees and that the full schedule is aggressive.

That planning addresses a recognized quantum-computing threat. It does not prove that classical AI-driven cryptanalysis will arrive on Drake’s worst-case schedule — or that an accelerated attack would necessarily arrive in time for a coordinated migration.

NIST standards exist, but blockchain adoption is not automatic

NIST finalized three foundational post-quantum cryptography standards in 2024: ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for hash-based digital signatures. ML-KEM is not a wallet-signature replacement. Even suitable signature standards require protocol integration, transaction-size trade-offs, wallet support, auditing and migration planning.

Moreover, HAWK’s withdrawal illustrates why candidate algorithms need adversarial scrutiny. It is evidence for taking cryptographic research seriously, not evidence that all lattice-based schemes have failed or that any single family of algorithms is permanently immune to future discoveries.

Intelligence assessment: how serious is the AI threat to crypto?

Our assessment separates three layers that are too often combined into one headline.

Level 1 – Individual wallet or application compromise: demonstrated risk. Phishing, malicious software, exposed recovery phrases, implementation bugs and vulnerable smart contracts can already cause losses. AI can assist adversaries in some of these activities without overcoming elliptic-curve mathematics. This is where holders face immediate, actionable security exposure.

Level 2 – General signature-system compromise: high consequence, unproven method. A practical classical algorithm for recovering secp256k1 secrets from public keys would profoundly alter the security of exposed Bitcoin keys and ordinary Ethereum EOAs. Whether such an algorithm will be found, by AI or otherwise, and on what timeline, remains unknown. The reviewed public evidence does not justify a prediction that it will happen within months.

Level 3 – Systemic protocol or custody compromise: conditional, potentially severe. A broad break across multiple cryptographic systems or control architectures could affect exchanges, bridges, validators, token permissions and settlement. Its impact would depend on which exact assumptions failed, which public keys were available, and how quickly networks and institutions could respond.

Claims that should not be confused with evidence

What would change this assessment? A publicly described key-recovery algorithm independently reproduced against appropriately generated, full-strength secp256k1 keys; a credible reduction in the attack’s real computational cost; demonstrated ability to compromise a relevant deployed signature system; or an authoritative security advisory backed by technical evidence. These would be materially different from another large batch of unrelated mathematics manuscripts or an AI-generated vulnerability report about ordinary software.

There is no responsible numerical probability to attach to an undiscovered attack on the basis of the evidence reviewed here. A low-probability scenario can warrant preparation when the consequences are enormous and precautions are affordable. That does not turn a severe hypothetical into a present cryptographic breach.

Frequently asked questions

Can ChatGPT, Claude or another AI guess a Bitcoin seed phrase?

Not from a properly generated Bitcoin address or public key using any publicly demonstrated general method. Poorly generated secrets, seed phrases copied into websites or chats, compromised backups and malware are separate vulnerabilities. Never share recovery words or private keys with an AI service or an exposure checker.

Are Bitcoin Taproot addresses less secure than older addresses?

Not as a general statement about today’s security. Taproot uses modern Schnorr signatures and has important functional and privacy benefits. It does, however, publish a tweaked public output key when funded, creating a different hypothetical future key-recovery exposure than an unused hashed-key output. An ECDSA-only bug and a general secp256k1 discrete-logarithm break would affect these formats differently.

Is an Ethereum account safe if it has never sent a transaction?

It may have additional protection against a public-key-dependent attack if its key has truly never been exposed. However, offchain message signing and use of the same key on other chains can disclose the public key. An undisclosed key is not proof against phishing, a stolen seed, malicious permissions or every conceivable future cryptanalytic result.

Would a multisig wallet stop an AI attack?

That depends on the attack and the wallet. Multiple independent signers can limit single-key compromise, but a sufficiently broad key-recovery capability could endanger multiple exposed signers. The threshold policy, public-key disclosures, recovery arrangements and signing protocol all matter.

Are smaller Bitcoin holdings protected by "Satoshi’s shield"?

No guaranteed protection follows from that phrase. It is a speculative argument that attackers might prioritize older or larger exposed balances first. A hypothetical attacker is not required to follow any such order, and key-recovery speed could change targeting economics. Balance size does not alter the cryptographic validity of a recovered key.

Methodology and editorial limits

This briefing was researched and source-checked on October 9, 2026. Its conclusions are based on the public OpenAI repository and revision history; Anthropic’s published cryptanalysis and smart-contract research; NIST’s standards guidance; Bitcoin BIPs; Ethereum technical documentation and roadmap; Project Eleven’s dated exposure tracker and published SQL; and contemporaneous reporting of the October expert debate.

"No publicly demonstrated attack" describes the public evidence reviewed, not proof that undisclosed research is impossible. Technical assessments distinguish ECDSA implementation defects from the underlying elliptic-curve discrete-logarithm assumption. The Project Eleven figures are an attributed dataset snapshot, not a result independently reproduced by sherafy.com. No private wallet keys were tested or requested for this analysis. Claims of timing, attack feasibility and systemic impact beyond observed research are identified as scenarios or inferences rather than established events.

References and Further Reading

Original warning and mathematics release

• Justin Drake – October 7, 2026 "bunker mode" statement – Original public warning and proposed precautionary response; some readers may need an X account to access the full thread.
• OpenAI – Sharing AI Progress in Mathematics – October 6 announcement describing the research release and its publication approach.
• OpenAI – Mathematics Repository and Methodology – Defines manuscripts, result families, formalizations, verification stages and evaluation scope.
• OpenAI – Mathematics Revision History – Documents the October 7 withdrawals, manuscript revisions and 300-of-719 formalization figure.

Original cryptanalysis and standards

• Anthropic – Discovering Cryptographic Weaknesses with Claude – Research account distinguishing attacks on the HAWK candidate and reduced-round AES from attacks on deployed production algorithms.
• NIST – Post-Quantum Cryptography – Confirms HAWK’s withdrawal and explains the finalized U.S. post-quantum standards and their current status.
• Anthropic – AI Agents Find $4.6M in Blockchain Smart Contract Exploits – Original experimental results establishing the simulated nature of the benchmark’s dollar figures.

Bitcoin security specifications and exposure data

• BIP 32 – Hierarchical Deterministic Wallets – Explains extended public keys, derivation and the security implications of non-hardened child keys.
• BIP 141 – Segregated Witness – Bitcoin specification relevant to witness-script and witness-public-key handling.
• BIP 340 – Schnorr Signatures for secp256k1 – Specifies Taproot’s Schnorr signature scheme and its relationship to Bitcoin’s traditional ECDSA signatures.
• BIP 341 – Taproot Spending Rules – Specifies Taproot output keys, tweaking and script-based spending.
• BIP 360 – Pay-to-Merkle-Root (Draft) – Proposed mitigation with explicit discussion of long-exposure and short-exposure attack limitations.
• Project Eleven – Bitcoin Risq List – September 14, 2026 snapshot of funded Bitcoin addresses classified as having exposed public keys; figures are not an observed hacking tally.
• Project Eleven – Open-Source Bitcoin Risq List Query – Published rule-based SQL approach underpinning the tracker. Project Eleven has a commercial interest in post-quantum security services.

Ethereum specifications and migration planning

• Ethereum.org – Ethereum Accounts – Explains EOAs, contract accounts, addresses, key pairs and public-key recovery from signatures.
• Ethereum.org – Proof-of-Stake Validator Keys – Separates BLS validator-signing roles from withdrawal credentials and their consequences.
• Ethereum.org – Post-Quantum Cryptography on Ethereum – Reviews the distinct account, consensus, data and proof-system upgrade requirements.
• Ethereum Foundation – Current and Emerging Protocol Priorities – Primary source for the December 2029 goal and the limits of the proposed migration schedule.

Contemporary reporting and expert responses

• The Block – Ethereum Researcher Calls for "Bunker Mode" Planning – October 7 account of Drake’s warning and his emphasis on a measured response.
• The Block – Crypto Industry Split Over Justin Drake’s AI Warning – October 8 reporting of disagreements among security researchers and industry figures.
• CoinDesk – Bitcoin and Ether Holders Urged to Prepare "Bunker Mode" – Additional contemporary reporting, including the connection to OpenAI’s math release and the warning against hasty migration.

Editorial currency note: Research releases, security advisories, BIP and EIP statuses, protocol roadmaps and the Bitcoin Risq List’s balance totals may change. The figures and threat assessment above reflect the sources available through October 9, 2026; check primary records again before republishing or materially updating this article.