Quantum runway

P2PKH and the quantum clock tick: who moves first

Updated 21 October 2026

That is a hash lock dressed as a payment. It is not a key.

What a P2PKH output actually exposes

A P2PKH script is short and stubborn. It commits to HASH160 of a compressed or uncompressed public key, and that is the only thing the chain records until spend. The public key itself is hidden behind two rounds of hashing. A cryptographically relevant quantum machine running Shor's algorithm cannot recover a private key from a hash. It needs the raw elliptic curve point.

This is the architectural detail that decides the order of events when BIP-360's deadline lands. Until the owner of the box signs, the on-chain artefact is a 20 byte fingerprint. There is nothing for the qubit budget to chew on.

Compare this with a Pay-to-Pubkey output, where the key sits in the scriptPubKey from day one. Or with a Taproot key path spend, where the internal key is committed to but can be revealed with a single signature and an empty script tree. P2PKH is the older, quieter cousin. It keeps the key under the doormat until you need it.

On the quantum runway counter the distinction matters because the runway is denominated in vulnerable satoshis. P2PKH satoshis are still locked behind a hash. Pay-to-Pubkey satoshis are not. When the runway counter ticks past the next billion, every dollar sitting in a P2PKH output is a dollar that needs the owner to broadcast a spend before the qubits can read the key.

The BIP-360 proposal catalogues this. A P2PKH output is post-quantum safe against a now-or-never attacker that only sees the chain. It is not safe against a now-and-later attacker that can wait for the spend and the key reveal in the same block.

The order of operations on spend

When a P2PKH owner finally moves their coins, three things happen in quick succession. The wallet assembles a transaction. The transaction includes the public key in its scriptSig along with the signature. The transaction is broadcast to peers and lands in the mempool.

The quantum machine sees the public key the instant it lands in the mempool. From that point it has the time between mempool acceptance and block confirmation to run Shor's algorithm on the key and forge an alternative signature that spends the same output to its own address.

Block times on Bitcoin are probabilistic. Ten minutes is the target, not the promise. In practice a transaction can sit in the mempool for seconds, minutes, or hours depending on fee, congestion, and policy. Each of those units of time is also a unit of time the qubit budget has to grind.

Three countermeasures get floated, in order of how seriously the community takes them. First, never reuse an address. A P2PKH address whose output has been spent reveals its key in the spending transaction, but the remaining balance of that address is zero. Nothing to steal. Second, consolidate vulnerable funds to a quantum-safe scheme well before BIP-360's deadline. Third, when consolidation is no longer possible because the deadline has arrived, refuse to spend from P2PKH at all and accept that the box stays closed until a fork.

None of these is automatic. Each requires the owner to act. The clock does not pause for inaction. On the runway counter the lower bound on P2PKH exposure falls as people sweep, but the upper bound has not moved in months.

Why the mempool is the new attack surface

Before 2017 the attack surface was the block. A miner who controlled a hashrate majority could rewrite recent history, but the public key of a P2PKH spend was visible only inside a confirmed block, and only after that block was final. The quantum machine did not have a ten minute head start.

After SegWit the mempool carries witness data separately. The public key still ships in clear, and any peer can read it. The witness discount made transactions cheaper, which means more transactions, which means more key reveals, which means more data for a harvesting adversary to record. The quantum tape recorder argument gets louder with every P2PKH consolidation sweep.

Now imagine a coalition running a harvesting operation. They run full nodes. They record every P2PKH key reveal since genesis. They wait for a future where fault tolerant quantum hardware can run Shor on a 256 bit elliptic curve key in well under the block time. The harvested data is their starting point. The attack is offline, not online.

This is why BIP-360's deadline is not a magic number. It is the time horizon inside which harvesting has to be uneconomical. After that horizon, the harvested tape becomes a key store, and the box is open whenever its owner finally moves it.

Who acts first

Three actors have a vote. The owners of vulnerable coins, who can sweep to a quantum-safe address or to a fresh P2PKH they will never spend. The miners, who choose what software to run and which transactions to include. The developers, who can ship a consensus change that freezes legacy outputs at the deadline.

Owners act first in the most orderly path. They sweep on their own schedule, before any panic hits the fee market. Each sweep is a small transaction that burns a little block space and reveals a key that is now empty. The runway counter ticks down by the value of the sweep.

Miners act second if owners dither. They can refuse to include transactions that spend from a frozen script class, which the BIP-360 soft fork can make a policy consensus rule. The mempool stays open, but the chain closes.

Developers act last. A consensus change is a last resort because it requires overwhelming social coordination and a flag day that freezes funds. The frozen quantum vault argument holds that this is acceptable because the alternative is theft, and the cost of theft is borne by the people who failed to move their own coins.

None of these actors is fully in control. The runway counter does not care who acts first. It tracks the value of vulnerable coins regardless of intent. The order of operations is decided by the box, not by the people who think they own it.

This post is technical commentary, not financial advice. Never paste a seed into a watch-only field. Watch-only wallets display addresses and balances, and any field that asks for a seed in such a tool is a scam.