Long exposure vs short exposure: the quantum race in the mempool

Updated September 2026

Every quantum estimate for Bitcoin eventually runs into one question: how long does the attacker get to look at the key? The answer splits the threat in two. Open boxes can be attacked slowly. Closed boxes can only be attacked in the moment you open them, and that moment is short. This page explains both, with the numbers from the two most detailed 2026 estimates.

What is a long exposure attack?

BIP-360, the draft that defines Pay-to-Merkle-Root, gives the vocabulary most discussions now use. A long exposure attack "attempts to derive private keys from public keys that are exposed for an extended period of time; that is, longer than the window of time that a public key is generally exposed in the mempool while waiting to be confirmed."

In this site's terms, that means the open boxes. The public key is already written on the chain, next to coins, and nothing forces it to move. BIP-360 lists the outputs that are open this way by design: P2PK, Taproot (bc1p) outputs, and any output whose address has been reused. Older hashed types, P2PKH, P2SH, P2WPKH and P2WSH, join the list the moment a spend reveals their key and coins are left behind, which is exactly what address reuse and change sent back to a spent address do.

Google Quantum AI's March 2026 paper uses a different name for the same thing. It calls these at-rest attacks, on "public keys that remain exposed onchain or offchain for long periods of time, such as dormant wallets with reused keys," and adds that "the attacker has days (or more)" to work. The paper counts a little over 1.7 million bitcoin in P2PK outputs alone, and estimates that dormant quantum-vulnerable bitcoin across all script types may reach 2.3 million BTC.

A long exposure attack does not need a fast machine. It needs a machine that works at all, and patience.

What is a short exposure attack?

BIP-360's second definition covers the other case: a short exposure attack "attempts to derive private keys from public keys during the brief period when funds are unconfirmed in the mempool."

This is the only attack that can touch a closed box. A never-spent 1, 3 or bc1q address publishes a hash of the public key, and Shor's algorithm needs the key itself as input. When you spend, your wallet has to reveal the key and a signature, so the network can check that you own the coins. From that moment until a miner includes your transaction in a block, the key is visible to anyone watching the mempool, and the coins have not moved yet.

An attacker who could recover the private key inside that window could sign a second transaction spending the same coins to their own address and try to get it mined instead of yours. The Google paper calls this an on-spend attack: "an attacker must derive the private key within the window of time allowed before the transaction is recorded on the blockchain."

So the box is not closed forever. It is closed until you use it, and then it is open for as long as your transaction waits.

How long is the mempool window?

Bitcoin does not produce blocks on a fixed schedule. The difficulty adjusts every 2,016 blocks so that those blocks take about 1,209,600 seconds, two weeks, according to the Bitcoin developer guide. That works out to one block every 600 seconds, ten minutes, on average.

The average hides a lot of spread. Blocks are found at random, so some arrive a minute apart and some take half an hour. A transaction that pays a competitive fee usually goes into one of the next blocks. One that pays too little can wait for many blocks, and every extra block is more time with the key on display.

For a short exposure attack, the arithmetic is simple. The attacker needs to recover the key, build and broadcast a competing spend, and have that spend mined before the honest one. If the key takes longer to recover than the transaction takes to confirm, the attack fails, because the coins have already moved to a new, still-closed box.

What Google's paper says about the race

"Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations" was posted to arXiv on March 30, 2026 and revised on April 15. Its authors are Ryan Babbush, Adam Zalcman, Craig Gidney, Michael Broughton, Tanuj Khattar, Hartmut Neven, Thiago Bergamaschi, Justin Drake and Dan Boneh. It gives two circuits for breaking a 256-bit elliptic curve key: under 1,200 logical qubits and under 90 million Toffoli gates, or under 1,450 logical qubits and under 70 million Toffoli gates. On superconducting hardware with a physical error rate of one in a thousand, the authors say these "can execute in minutes using fewer than half a million physical qubits."

The part that matters for the mempool is a trick the paper calls priming. The first half of Shor's algorithm depends only on the curve's public parameters, which are the same for every Bitcoin key. A quantum computer can run that half in advance and wait. When a public key appears, it only has to finish the second half. The paper says this "halves the time between a public key being revealed and its private key being resolved."

With priming, the paper estimates roughly 9 or 12 minutes from seeing the key to having the private key, out of a full run of 18 or 23 minutes. Against Bitcoin's ten-minute average block interval, it puts the chance of a successful on-spend attack at "slightly less than 41%," under idealized assumptions that favor the attacker.

That figure matches what random block times would suggest. If blocks arrive at random with a ten-minute average, the chance that no block has been found nine minutes after a transaction is broadcast is about 41%. The attacker wins roughly those races and loses the rest.

A 41% chance per spend is not a safe margin. It is also a number for a machine that does not exist, with every assumption tilted toward the thief.

Fast clocks and slow clocks

The paper's most useful idea for holders is its split between two kinds of hardware. Superconducting, photonic and silicon spin qubit machines have "fast gates and short quantum error correction cycles" and could "solve ECDLP in the span of a few minutes and thus, to launch on-spend attacks." By contrast, it says, operations on neutral atom and ion trap devices "are about two to three orders of magnitude slower."

The IonQ estimate from September 2026 shows what slow means in practice. IonQ's trapped-ion design needs only 19,397 physical qubits, far fewer than Google's half million, but takes about 25.7 days per attempt. At ten minutes per block, that is roughly 3,700 blocks. A machine like that can attack open boxes, one at a time, and has no chance at all against a spend in the mempool.

So the two numbers people quote, qubits and time, answer different questions. Qubit count decides when a machine can be built. Run time decides which boxes it can reach. A slow machine threatens long exposure only. A fast one threatens both.

Which boxes each attack can reach

• Taproot (bc1p), P2PK and reused addresses: long exposure from the day coins arrive. Taproot opens the box on arrival, because the address encodes a public key.
• Spent-from addresses that still hold coins: long exposure from the first spend onward. The key was published and the leftover coins sit beside it.
• Never-spent 1, 3 and bc1q addresses: no long exposure. Short exposure only, and only during the minutes or hours your own spend waits for a block.
• Coins on an exchange: whichever addresses the exchange uses, which you do not control. Who holds the box decides that.

The exposure classification draft submitted to the BIPs repository in September 2026 formalizes the same split, with EXPOSED_AT_REST for the first group and EXPOSED_ON_SPEND for hashed outputs that reveal their key only when spent.

Why BIP-360 fixes one and not the other

BIP-360's new output type, P2MR, removes Taproot's key path, so a bc1z output keeps its keys hidden until spent, like a hashed address. BIP-360 says this gives "resistance to long exposure attacks." It is equally plain about the limit: protection against more sophisticated attacks "may require the introduction of post-quantum signatures in Bitcoin," and P2MR does not, by itself, protect against short exposure attacks. What BIP-360 actually proposes goes through the rest of the draft.

The reason is structural. Hiding a key until spend time cannot help during spend time, because spending means showing the key. To close the mempool window, the thing revealed at spend has to be something a quantum computer cannot reverse: a post-quantum public key and signature. BIP-360 notes that post-quantum signature schemes could give P2MR outputs "comprehensive quantum resistance," including against short exposure. Proposals like SHRINCS are drafts of that second step. None is deployed.

That order makes sense given the hardware. If slow machines arrive first, closing open boxes buys the most protection for the least change. If fast machines arrive, signatures have to change as well.

Are there other ways to shorten the window?

The Google paper lists mitigations alongside the post-quantum route. Two are about the mempool window specifically. It mentions "private mempools," and notes that "some Bitcoin mining operations allow users to bypass the public mempool by submitting transactions directly to miners for a fee." A transaction nobody outside the miner sees is a transaction nobody can race, though the key still appears when the block is published, after the coins have moved.

It also mentions commit-reveal schemes, where a spender first commits to a transaction without revealing the key and only reveals it later. Proposals of this kind are about rescuing coins after a quantum computer appears, and they would need consensus changes.

For an ordinary holder, the practical version is modest: when a spend matters, pay a fee that gets it into the next block or two. It narrows the window. It does not close it.

What to do with this today

• Close the open boxes first. That is the slow, cheap attack. Check your addresses with the wallet checker and, if coins sit in a reused or spent-from address, follow how to move coins to a still-closed address.
• Send change to fresh addresses, so a spend opens only the coins you meant to move.
• Know that a closed box is not a vault against every future machine. It is protection against slow machines and against attacks at rest. Against a fast machine, the protection has to come from new signatures.
• Read new estimates for their run time as well as their qubit count. Minutes means mempool. Days or weeks means open boxes only.