After the AI Security Warning, How Should We Use Our Wallets?

When people read a cryptographic security warning, the question they most want answered is often straightforward: what should I do with my wallet?

In his October 7 post, Justin Drake argues that advances in mathematics enabled by AI could threaten blockchain signature algorithms sooner than expected. He recommends that the industry start preparing, including moving long-term holdings to addresses whose public keys have not been exposed. He also repeatedly warns against panic and hurried migration.

This is the post I am responding to:

Vitalik Buterin subsequently responded to the warning. He takes the risk seriously but advises against rushing to replace wallets today. He also asks whether the cryptography chosen for an upgrade could itself be vulnerable to AI-assisted mathematical progress.

Their emphases differ, rather than their advice being opposites. Drake stresses early preparation; Vitalik stresses conditions and costs. Both caution against hurried migration.

I think the warning deserves serious attention. But there is a considerable distance between assessing a cryptographic risk and telling someone how to use a wallet. If a precaution makes people more likely to send to the wrong address, lose access to a backup, or avoid checking whether they can spend their funds, those costs belong in the security assessment too.

Consider a test transfer. Sending a small amount first can help confirm receipt. When the destination is your own wallet, sending a little back out can check that you can actually use it. That is useful operational verification. Under a new objective of keeping a public key hidden, however, the outbound test may reveal exactly what you wanted to protect. The test has not suddenly become a bad idea. We need to understand what it checks, and what additional constraint we are asking it to satisfy.

A warning is not evidence that wallets have been cracked

Three things need separating: a private key, a public key, and an address.

The private key is the secret that authorizes a digital signature. The public key lets others check that signature. Under the security assumptions these systems rely on, knowing the public key does not let someone calculate the private key. An address is the identifier you give people for payment. Some common address formats use a hash of a public key: roughly, a digest that is difficult to reverse. Seeing such an address does not necessarily reveal the full public key.[1][2]

The original design allows public keys to be public. An exposed public key is not a leaked private key.

Drake's concern is that the underlying assumption could change. If AI helps discover a sufficiently efficient way to recover a private key from a public key, exposed accounts would face a different kind of threat. ECDSA, which he discusses, is a widely used digital-signature algorithm. This possibility is worth examining even before a large quantum computer becomes available.

But his post does not supply a reproducible method for cracking a real wallet's private key. Its proposed timeline is a risk assessment, not a verified countdown. Encouraging research and preparation does not establish that everyone needs to move funds today.

Vitalik raises a further distinction: post-quantum does not mean proven safe against unknown AI-assisted attacks. His concern includes lattice cryptography, which relies on difficult mathematical problems in high-dimensional spaces. ML-DSA, a lattice-based signature scheme, is already a NIST standard. Standardization reflects evaluation, not a guarantee that more efficient attacks will never emerge.[7]

He favors hash-based signatures where appropriate. This family also has standards, including SLH-DSA.[8] Neither preference establishes that lattices have been broken or that hashes are invulnerable. For users, the lesson is that upgrades need continuing scrutiny, not that they should choose algorithms or improvise wallet parameters from online discussions.

It also explains why “I use cold storage” is only part of an answer. Cold storage keeps private keys away from connected environments; a hardware wallet keeps keys and signing operations inside a dedicated device. The blockchain's record of your assets is not stored inside that device. If an attacker could calculate a private key from public information, keeping the device offline would not stop that attack. Hardware wallets would still have an important role in preventing ordinary computer malware from directly stealing private keys.

How can one wallet have many addresses?

A little wallet history helps here.

Generating a separate random key for every address creates a backup problem: an older backup may not include a newer key. Deterministic wallets address this by deriving keys from a shared secret starting point. HD stands for Hierarchical Deterministic: those keys form a tree, with different branches and positions.[3]

For a user, the benefit is simple. Restore the same starting point and follow the same route through the tree, and the keys can be found again. Recovery words commonly back up that starting point; an optional passphrase also affects which wallet is produced. Think of it as a key directory you can recreate. Different chains, accounts, and address types may occupy different branches.

This suggests a more precise approach to testing. With a newly configured wallet, one address can be used for a small receive-and-send test. If there is also a requirement to keep a long-term storage address's public key hidden, a different fresh address can be derived from that wallet and verified on the hardware device's trusted display. Verifying a receive address on the device normally does not require an outgoing on-chain transaction.[4]

These checks serve different purposes. The test address checks the basic transfer process. Verification on the device helps establish that the new address belongs to the wallet currently loaded, rather than being a substitution on the computer. Neither replaces the other. A successful transfer also does not establish that a backup can later be restored. Follow the manufacturer's supported backup-checking procedure; do not enter recovery words into chatbots, web checkers, or unfamiliar “migration tools.”

Sharing the same recovery words does not mean every new address is ready to use, or that its public key is hidden. Recovering or checking an address requires the chain, account, address type, and passphrase settings used to generate it. Some watch-only services receive an extended public key, called an xpub, to generate addresses and monitor balances. Relevant public keys can then be derived by that service. “This address has never sent a transaction” is not sufficient evidence that its public key is hidden.[3]

Bitcoin's Taproot provides another important exception: its outputs already contain a public key. A fresh address is therefore not a universal public-key-hiding measure. Wallet software needs to explain this distinction. Users should not have to guess from a social post and hastily change address formats.[5]

Funds need a safe way out, too

Bitcoin and Ethereum require different explanations here.

A Bitcoin wallet's balance adds up several unspent transaction outputs, usually called UTXOs. Think of them loosely as banknotes of different denominations. A transaction spends an entire input, returning the excess as change.[1]

If one output holds 100 BTC and a payment spends 1 BTC, the same transaction can send almost 99 BTC, less the fee, to a fresh change address. There need not be a second transaction to rescue a balance left at the old address. Fresh change addresses are already an established wallet practice.

Other unspent outputs using the same exposed key do not automatically move, however. Nor does exposing one address's public key automatically expose every different key in the wallet.

A typical Ethereum externally owned account works more like a continuing balance. After an outgoing payment, the remainder stays in that account. The transaction signature allows the public key to be recovered; some off-chain message signatures, such as certain wallet login or message-confirmation requests, do too. Avoiding transactions alone does not establish that the key has never been exposed.[2]

An account may also hold different tokens or have permissions and identity relationships across applications. Moving to a new address can require more than transferring a balance. Some permissions need setting up again; some records do not move. Asking users to sort all of this out after every operation creates ample opportunity for mistakes.

Keeping a public key hidden mainly changes exposure while funds sit still. Spending may reveal the key or a signature from which it can be recovered. If a future attack becomes fast enough to operate before a transaction confirms, prior concealment cannot by itself guarantee a safe exit. It is a conditional precaution, not a substitute for upgrading signature algorithms.[5]

Vitalik makes the operational cost concrete by recounting greater personal losses from migration mistakes than from hacks. One person’s experience is not a population-wide finding. It does illustrate why any benefit from a fresh address must be weighed against the chance of a failed move.

Two other settings need more specific advice.

With multisig wallets, ask where signatures become public. A multisig operation needs approval from a specified number of signers. Vitalik favors collecting confirmations off-chain to reduce public exposure. But off-chain does not mean secret from the collector. If recovering private keys from public keys becomes feasible, that collector may become a new source of risk. What the final transaction reveals also depends on the wallet and contract. This is not a general claim that switching to multisig solves the problem.

For privacy, separate signing from encryption. Signing establishes who authorized something; encryption restricts who can read it. Improving signatures does not protect previously uploaded ciphertext. Vitalik recommends keeping encrypted records off-chain. Permanently public ciphertext can be copied and attacked later. Off-chain storage reduces permanent publication, but still needs access controls, backups, and protection against disclosure by recipients. It cannot erase copies that have already escaped.

Reducing public exposure helps, but we must still ask who receives the information and how the system can later change.

For ordinary users, I would keep the practical advice focused on a few actions:

These actions cannot promise protection against every future mathematical breakthrough. They can help avoid introducing a very real operational failure while preparing for a possible new threat.

Changing a key should not mean rebuilding an account

This discussion brings me back to questions we considered in ArcBlock's early blockchain design. Enterprise systems replace keys, revoke permissions, and change personnel and devices. Why should replacing a blockchain key so often require users to reconstruct their relationships with everyone else?

Account migration and delegated authorization were partly motivated by bringing those enterprise security practices into blockchain systems. Keys should be replaceable. Applications should receive the permissions they need for a task. Existing payment relationships need a system-recognized way to continue.

ArcBlock's account-migration patent, US11388010B2, filed in 2019 and granted in 2022, describes an old account authorizing migration to a new one, with the relationship recorded on-chain. It also discusses changing algorithms in response to a vulnerability. Historical SDK releases contain a migration flow; our analysis of the patent and implementation distinguishes the design from the behavior of specific released versions.

The value is in making continuity part of the system, beyond an instruction to generate a new address. This is not a ready-made solution to the present warning. The described migration submits a new public key and relies on the old private key's signature. If the old algorithm can already be broken, an attacker may also be able to authorize migration. Replacing a key while retaining the same vulnerable algorithm does not remove an algorithm-level threat.[6]

Delegated authorization addresses another problem: granting an application scoped permissions without handing it the user's master private key, and allowing that delegation to be revoked. This can limit the consequences of an application error or compromise. It cannot make a broken signature algorithm secure, or guarantee that the master public key has remained hidden.

These designs provide a useful starting point and leave substantial questions to answer. Who authorizes a change of signature algorithm? If the old key is no longer trustworthy, has an alternative verification path been established in advance? Which assets, addresses, and application relationships can continue? How does the wallet let a person verify those changes without first becoming a cryptographer?

Drake urges preparation; Vitalik draws attention to algorithm choices and migration costs. I would take the conversation further into how systems can support those changes. Protocols need to prepare stronger cryptography. Wallets and applications need to prepare operations people can carry out correctly. An account that a user can confidently verify, recover, and eventually spend from is the security experience we should be working toward.

References