Part III, Engineer · Lesson 18
Cryptocurrency in a post-quantum world
The short version
A crypto wallet's address is often a scrambled fingerprint of its public key, and a future quantum computer needs the actual public key to work out the secret one. Some coins show the public key right away, and every coin shows it when you spend. The longer a key sits in public with money behind it, the bigger the target.
You'll learn to
- Explain which parts of Bitcoin and Ethereum a large quantum computer threatens, and which it doesn't.
- Determine when a public key is exposed for P2PK, P2PKH/P2WPKH, P2TR and Ethereum accounts.
- Distinguish long-exposure from short-exposure attacks.
- Outline what a post-quantum migration would require and why signature size is a hurdle.
What's actually at risk
Bitcoin and Ethereum have no encrypted payloads to "harvest now, decrypt later." Their exposure is about signatures. Bitcoin signs with ECDSA and, since Taproot, Schnorr signatures (BIP 340). Ethereum accounts sign with ECDSA. All of these use the elliptic curve secp256k1, and Shor's algorithm would let a large fault-tolerant quantum computer derive a private key from its public key. With the private key, an attacker can spend the coins.
Other parts of the systems fare better. Addresses that are hashes of keys, transaction IDs and proof-of-work mining all rest on hash functions, which face only Grover's generic quadratic speedup. So the question for every coin is narrow and precise: is its public key visible, and for how long?
Where public keys appear
Bitcoin
- P2PK (pay-to-public-key). The output script contains the public key itself:
<pubkey> OP_CHECKSIG. It was common in Bitcoin's earliest years and is rarely used in new transactions. The key is public from the moment the coins arrive. - P2PKH and P2WPKH. The output commits to a 20-byte hash: RIPEMD-160 of SHA-256 of the public key (HASH160). The key itself appears only when the output is spent, inside the spending transaction.
- P2TR (Taproot, BIP 341). The output's witness program is a 32-byte x-only public key
Q = P + t·G, a tweak of an internal key. A key-path spend is just a signature forQ, so the key is visible on chain from the start.
It helps to see what a spend actually contains. To spend a P2PKH output, the spender supplies a signature and their full public key. Nodes check that the key hashes to the 20-byte value in the output, then verify the signature against it. From that moment the key is in the transaction for anyone to read: first in the mempool, then permanently in the block. The hash protected the key exactly until the first spend.
So hashing is a delay, not a defense. That delay is valuable: a coin that has never been spent from a hashed address gives a quantum attacker nothing to work on. But it only holds if the address is used once.
Ethereum
An externally owned account's address is the last 20 bytes of the Keccak-256 hash of its public key, so a fresh, never-used account hides its key. But every Ethereum transaction signature lets anyone recover the sender's public key: the protocol's own validity check, ECDSARECOVER in the Yellow Paper, does exactly that. After an account's first outgoing transaction, its key is effectively public. And because Ethereum accounts are normally reused, the funds usually stay behind it.
Why the attacker needs the key, not the address
Shor's algorithm solves the elliptic-curve discrete logarithm problem: given a public point Q = d·G, find d. It needs Q as input. An address that is only a hash of Q gives it nothing to start from. To get from the hash back to Q, an attacker would have to invert RIPEMD-160 or Keccak-256, where quantum computers offer only Grover's generic speedup. That asymmetry is the whole reason exposure timing matters.
Long exposure and short exposure
BIP 360, a draft Bitcoin proposal, uses a helpful pair of terms:
- Long-exposure attacks target public keys that sit visible for an extended period: P2PK outputs, Taproot outputs, reused addresses, and keys revealed through shared extended public keys (xpubs). The attacker has unlimited time.
- Short-exposure attacks target the brief window while a spending transaction waits unconfirmed in the mempool, the queue of pending transactions. Spending reveals the key; an attacker who could derive the private key within that window could try to broadcast a competing transaction. As BIP 360 notes, wallet hygiene can't prevent this, because revealing the key is how spending works.
Short-exposure attacks need a much faster quantum computer than long-exposure ones: the key must be broken while the transaction waits for confirmation, not at leisure. That's why BIP 360 expects long-exposure attacks to be the earliest quantum threat to Bitcoin.
Step a P2PKH wallet through its life with and without address reuse, then compare it with P2PK and Taproot. Note where the verdict changes from "hidden" to "short window" to "long exposure," and when there's nothing left to steal.
What migration would take
Nothing a single user does can make a secp256k1 signature quantum-resistant. A real fix requires the protocol to accept a new kind of signature, then for every holder to move their coins into outputs that use it. Three hard parts stand out.
1. Size
Block space is the scarce resource, and post-quantum signatures are big:
| Scheme | Public key (bytes) | Signature (bytes) |
|---|---|---|
| Schnorr (BIP 340) | 32 | 64 |
| ML-DSA-44 | 1,312 | 2,420 |
| SLH-DSA-SHA2-128s | 32 | 7,856 |
A spend that carries an ML-DSA-44 key and signature is roughly 3.7 KB of authentication data, against 96 bytes for Schnorr. Hash-based SLH-DSA keeps keys tiny, but its signatures are over a hundred times larger than Schnorr's. Each option trades capacity, fees and verification cost differently. That's why the choice is a design debate, not a drop-in swap.
2. Getting there safely
Proposals approach the problem in stages. BIP 360, a draft, would add Pay-to-Merkle-Root (P2MR): a SegWit version 2 output like Taproot but with the key-path spend removed, so funds are spendable only through scripts. On its own that removes the long-exposure risk of Taproot's visible key. Script trees could later include post-quantum signature checks once the protocol supports them. Like any consensus change, it needs community agreement before it means anything on chain.
3. The coins that can't move
Migration assumes owners act. Coins whose keys are lost, and early P2PK outputs whose owners are inactive, will never be moved voluntarily. If a quantum attacker could take them, the network faces an uncomfortable governance question: leave them as a prize, or change the rules for coins nobody can prove they own. There's no consensus answer, and this course won't pretend there is.
Practical guidance for engineers
- Never reuse addresses. Use a fresh address for change and for every receive. It turns long exposure into short exposure for hash-based output types.
- Treat xpubs as sensitive. An extended public key reveals the public keys of every address it derives.
- Know your output types. Taproot brings real privacy and efficiency benefits, but its key is on chain. Factor that into long-term cold storage decisions as post-quantum proposals mature.
- Design for agility. Wallet and custody software should be able to add a new address type and a migration flow without a rewrite. See crypto-agility.
- Watch the proposals, not the headlines. Track BIPs and Ethereum improvement proposals directly. Claims that a chain is "quantum-proof" deserve the same skepticism as any other "unhackable" product.
Summary
- Bitcoin and Ethereum signatures use secp256k1 (ECDSA, and Schnorr in Taproot), which Shor's algorithm breaks; hashes and mining face only Grover-type speedups.
- P2PK and Taproot (P2TR) outputs expose a public key as soon as coins arrive; P2PKH/P2WPKH expose it only when spent.
- Ethereum addresses hash the key, but any signed transaction lets anyone recover it, and accounts are usually reused.
- Long exposure (key on chain while funds remain) is the easier quantum target; short exposure is the mempool window during a spend.
- Migration needs new PQ signature types by consensus; signatures of kilobytes, against Schnorr's 64 bytes, make it a capacity debate.
- Avoid address reuse, guard xpubs, and build wallets that can adopt new output types.
Questions
Get five of six right to mark the lesson complete. They also feed the final exam.
Sources
- BIP 341: Taproot (SegWit version 1 spending rules)
- BIP 340: Schnorr Signatures for secp256k1
- BIP 360: Pay-to-Merkle-Root (P2MR), draft
- Bitcoin Developer Guide: Transactions
- Bitcoin Wiki: Technical background of version 1 Bitcoin addresses
- ethereum.org: Ethereum accounts
- Ethereum Yellow Paper
