The 100-Key Vault: one block, no Bitcoin fork

Bitcoin is not post-quantum secure today, and the fix in the protocol is years away. We propose a method, One-Time Vaulting, that makes Bitcoin custody post-quantum secure at rest and quantum-resilient in flight on the Bitcoin mainnet today: no fork, no miner deals, no change to wherever your keys already live, one ordinary transaction. Bitcoin will become post-quantum on its own schedule, once the protocol upgrades and the economy migrates; this method is for the years in between.

The One-Time 100-Key Vault is a Bitcoin custody method, built from the standard P2WSH output and 100 fresh ECDSA keys that all must sign, each address spent exactly once. It is post-quantum secure at rest, because only a SHA-256 hash is visible, and quantum-resilient in flight, because an attacker must derive all 100 private keys inside one Bitcoin block interval. Using the estimate in Google Quantum AI’s 2026 paper Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations, about nine minutes per key on a first-generation fast-clock quantum computer, an attacker with seven such machines succeeds about once in 730,000 spends, with twenty about 1% of the time, and with a hundred about 41%. On published expert surveys and vendor roadmaps, the method holds below one in a million per spend through about 2032 and below 1% through about 2035, which covers the estimated seven-year window for Bitcoin to adopt native post-quantum signatures. It requires no change to Bitcoin, no relationship with miners, and no change to existing hardware security modules; a spend costs about 2,800 virtual bytes (2,759 measured on mainnet for one input and one output). The method is called One-Time Vaulting, written OTV; implemented here by EternaX Labs in October 2026.

Bitcoin will fix this itself, eventually. The question is what you do with your bitcoin until it does.

1. The problem not priced in

If you have heard that Bitcoin is not post-quantum secure and that nothing can be done about it until the protocol changes, the first half is true and the second is not. This piece shows a way to hold and move bitcoin that a quantum computer cannot touch at rest and can only race in flight, built entirely from what Bitcoin already does, and proves it with an ordinary mainnet transaction. First, the problem as it actually is.

Bitcoin ownership is a public key. Whoever can turn a public key into its private key owns the coins, and a sufficiently large quantum computer running Shor's algorithm does exactly that. Nothing else about Bitcoin changes when it arrives; only the signatures stop meaning anything. Two things make this sharper than the usual story: secp256k1's 256-bit keys need a smaller quantum computer than RSA-2048, and there is no undo. A bank that loses a wire to fraud has recourse; a bitcoin moved by a forged signature is gone.

The question that matters is not "when will a quantum computer exist" but "when it does, which of my coins can it reach, and how fast". Google Quantum AI's March 2026 whitepaper, co-authored with the Ethereum Foundation and Stanford, gives the first careful answer, and it splits the problem into two attacks that are not alike.

At rest: coins whose key is already visible

If a public key is sitting on the blockchain, an attacker can read it today and work on it for as long as they like. Three kinds of bitcoin are in this state: the original pay-to-public-key outputs (about 1.7 million BTC, including Satoshi's), every Taproot address, because Taproot writes the public key into the output, and every reused address, because the first spend revealed the key. Google counts roughly 6.9 million BTC in this condition; BIP-361's authors put it at more than 34% of supply. For these coins the only cure is to move them before a quantum computer exists.

In flight: every other coin, for about ten minutes

The remaining two thirds of bitcoin sit behind a hash. The chain shows a fingerprint of the key, not the key, and a quantum computer cannot invert a hash in any useful time. That protection holds until the owner spends. To spend, the owner must reveal the public key so the network can check the signature, and from that moment until the transaction is buried in a block, the key is public and the race is on.

Google's whitepaper is the first to put a number on that race. Its optimised circuits need either 1,200 logical qubits and 90 million Toffoli gates or 1,450 and 70 million, fitting in fewer than half a million physical superconducting qubits, and take about 23 or 18 minutes per key. Half of Shor's algorithm depends only on the curve, so a machine can be "primed" in advance; from that state Google estimates roughly 12 or 9 minutes from seeing a public key to holding its private key, and simplifies to "about 9 minutes" for the first generation of fast machines.

Bitcoin blocks arrive on average every ten minutes, but randomly: the wait is exponentially distributed, so a nine-minute quantum attacker beats the next block about 41% of the time. The number, per Google, assumes a single key, no network congestion, and an attacker who then outbids you for block space. The last assumption is now the network's default: since Bitcoin Core 28, any unconfirmed transaction can be replaced by a conflicting one that pays a higher fee.

Google paper notes only fast-clock machines, superconducting, photonic or silicon-spin, can run this race; ion-trap and neutral-atom machines are 2-3 orders of magnitude slower and more likely attack coins at rest long before coins in flight. And the first such machine may not announce itself: early quantum computers "may first be detected on the blockchain rather than announced."

The same paper warns against the opposite failure mode: unscientific resource estimates are themselves a form of attack on the system. So every number in this article is cited to a primary source and scope.

2. Bitcoin can't fix it this year

The proper fix is a post-quantum signature scheme in Bitcoin's consensus rules, so that a coin can be locked to a key no quantum computer can derive.

Currently, Bitcoin's scripting language can verify exactly two kinds of signature, ECDSA and Schnorr, both on the same vulnerable curve. It has no opcode for SLH-DSA, ML-DSA or any other post-quantum scheme, no way to express one with existing opcodes, and the only post-quantum primitive it offers at all is the hash function. Adding a new signature scheme means a soft fork. BIP-360, "Pay to Merkle Root", was merged into the BIPs repository as a draft in February 2026; it removes Taproot's exposed key path but defers post-quantum signature opcodes to a future proposal. BIP-361, the proposal to retire legacy signatures on a schedule, is also currently a draft.

User adoption timelines are an another unknown. A BIP-360 co-author has estimated that even on an optimistic path, with consensus reached and no setbacks, migration takes about seven years: two and a half years of review and testing, half a year to activation, and roughly five years for most of the economy to move. A bank holding bitcoin today cannot plan on the protocol solving the problem for it.

So the constraint on a method that works now is severe: no change to consensus or relay policy, no relationship with miners, no new software for nodes, nothing new for the device that holds the keys to learn. The only post-quantum material Bitcoin offers is the hash. The only lever it offers on the in-flight race is how much work the attacker must do and how long they have.

The chart above is the shape of the problem. The lower band is how long Bitcoin needs; the upper band is how long a method built from today's Bitcoin can hold. Everything that follows is built for the span between those two dates, and built to be left behind at the end of it.

3. The One-Time 100-Key Vault

A 100-Key Vault is a standard Bitcoin P2WSH address built from 100 fresh keys that all have to sign, used exactly once, with the decision to spend made by a hash-based signature that no quantum computer can forge. The mechanism is One-Time Vaulting; written generally it is OTV(N), and OTV(100) is the instance this piece is about, because 100 is the most keys Bitcoin Core's default policy relays in a single input.

In plain words: you generate 100 brand-new keys, in a hardware security module for a bank or on an offline computer for an individual, build a script that says "all 100 must sign", and put bitcoin into the address that is the hash of that script. On chain that is all anyone sees, for as long as the coins sit there. When it is time to move them, whoever governs the vault approves one exact transaction with a hash-based signature that lives off-chain; only then does the signing device produce the 100 signatures, and the transaction goes out exactly as any other: Bitcoin Core nodes relay it, pools on Core's policy mine it, and it confirms in the next block that takes it. Change goes into a new vault with 100 new keys in the same transaction. The 100 keys that signed are deleted and never used again.

That is the whole method. Nothing in it is new to Bitcoin, and two of its parts are not new at all. Never reusing an address has been Bitcoin's own advice since 2010. Using several keys as a quantum defence was proposed by Holmes and Chen at the University of Surrey in 2021, up to the 20 keys that Bitcoin's multisig opcode allows, with the observation that it multiplies the attacker's required capacity but can be attacked in parallel. What has not been done is to take the number to the ceiling: 100 keys needs a different construction than the one everyone uses, it sits exactly at the limits Bitcoin Core relays, and nobody had built it, spent it on mainnet, put a hash-based approval gate around it, or quantified it against a dated fleet of quantum machines. That combination is what we call One-Time Vaulting, and the 100-Key Vault is its first instance. This is the first description of it.

Locked by hash at rest

A resting vault is safer than a single hashed address, for a reason that is itself post-quantum. There are exactly two ways to move its coins: produce 100 valid ECDSA signatures, which needs the 100 public keys, hidden behind a SHA-256 hash of the script that a quantum computer cannot invert; or persuade the device that holds the keys to sign, which needs the off-chain lock to open first: an approval signed with SLH-DSA, the hash-based scheme NIST standardised as FIPS 205, which a quantum computer cannot forge. For an institution that approval is a quorum of officers; for an individual it is one hash-based key on a token they hold. Both locks rest on hash functions. Shor's algorithm is irrelevant to either. The curve matters only during the minutes of the spend itself, which is why that moment gets the next four sections.

Nothing in the method requires an institution. Hardware security modules and officer quorums are how a bank runs it; the construction itself is a script, a rule about reuse, and a hash-based approval, and it scales down. The same vault at 20 keys uses Bitcoin's ordinary multisig opcode and can be built by any wallet software that can construct a custom witness script; 100 keys is the reserve-grade setting. The number is a dial. What does not change with the dial is the discipline: every address used once, every spend approved by a signature a quantum computer cannot forge, change into a fresh vault.

A 100-Key Vault shows the chain nothing until it spends, and when it spends, it shows everything at once and only once.

The script

The vault is a pay-to-witness-script-hash output. Its witness script is a chain of 100 signature checks:

<pubkey_1>   OP_CHECKSIGVERIFY
<pubkey_2>   OP_CHECKSIGVERIFY
   …
<pubkey_99>  OP_CHECKSIGVERIFY
<pubkey_100> OP_CHECKSIG

One hundred 33-byte keys and one hundred opcodes come to 3,500 bytes. Bitcoin Core's relay policy allows a witness script of up to 3,600 bytes and up to 100 witness items per input; its source code notes that these limits are "adequate for multisignatures up to n-of-100 using OP_CHECKSIG". So 100 is not a number chosen for effect. It is the largest vault a single input can hold and still be relayed under Bitcoin Core's default policy. Bitcoin Knots is stricter: its default -maxscriptsize of 1,650 bytes counts the whole witness, which caps the chain at 15 keys, so Knots nodes, and the OCEAN pool that runs them, neither relay nor mine a 100-key spend; Core nodes relay it and other pools mine it. Our mainnet spend, one input to one output, weighed 2,759 virtual bytes, roughly 20 times an ordinary payment; with a change output it is about 2,800.

Why not the familiar OP_CHECKMULTISIG? It is capped at 20 keys by consensus, and chaining five of them pushes the witness past the 100-item limit. The chain of single checks is both larger and standard.

The chain sees only a hash until the spend

4. A theft needs all 100 keys before the next block

Here is the whole in-flight argument in one sentence: the attacker must derive every one of the 100 private keys from the 100 public keys, in the time between your broadcast and the next block, and then win a fee auction. Everything else is arithmetic.

Google's whitepaper states the two facts that govern that arithmetic, and we quote both because they cut both ways: "The cost of quantum attacks on multi-signature transactions, such as P2WSH, increases linearly with the number of signatures required. However, these attacks parallelize trivially, so an attacker with a sufficient number of CRQCs can achieve the probability shown in Figure 6." And: "for scripts that require a large number m of signatures, on-spend attacks by an attacker with a small number of CRQCs are made more difficult by the need to derive a large number of private keys in the ten minutes average block interval."

So the honest model is this. Take an attacker with M primed machines, each needing about 9 minutes per key. To break N keys they need ⌈N/M⌉ rounds of 9 minutes, and they succeed if the next block takes longer than that: probability e^{−0.9·⌈N/M⌉}. Table B shows what that gives.

Table B. Probability that an attacker derives all keys before the next block, per spend. Assumes 9 minutes per key per machine (Google's primed figure), no congestion, and that the attacker then wins the fee auction. Favourable to the attacker in every respect but one, batching, which is covered under gate 2 in section 5. It also charges every round only 9 minutes, although a machine must re-prime between keys, so later rounds really cost closer to 18.

5. A thief must pass seven gates

"Hard" is not one argument. It is a sequence of gates an attacker has to pass in order, each with its own number, its own source, and a date for when it weakens. Together they are the case for 100.

Gate 1. Only fast-clock machines can race

Google's paper separates quantum platforms by how fast they run a single operation. Superconducting, photonic and silicon-spin machines are fast-clock. Trapped ions and neutral atoms, which hold today's records for logical qubits, are "about two to three orders of magnitude slower": a key that takes nine minutes on fast hardware takes fifteen hours to six days on slow. That threatens coins whose keys are already visible, and not a spend that confirms in minutes. Half the quantum industry is not in this race. Weakens if: slow-clock platforms find magic-state techniques suited to their hardware, which Google calls plausible and nobody has shown.

Gate 2. A fleet, not a machine

Each key is a separate run of Shor's algorithm. One first-generation machine working through 100 keys needs about fifteen hours, during which roughly ninety blocks go by. For the single-key odds of 41% the attacker needs 100 machines running at once; for one in a hundred, twenty; for one in a million, seven. On the published expert surveys and vendor roadmaps we assess a coordinated fleet of seven fast-clock machines as unlikely before about 2032 and no better than one in eight by 2035.

Say the limit out loud: adding keys multiplies the attacker's hardware, not the difficulty of the mathematics. Going from one key to a hundred adds about log₂(100) ≈ 6.6 bits of work, and nobody calls 6.6 bits a security parameter. What those bits buy is time, during which the machines that could use them are few, expensive, and owned by governments and hyperscalers. Against a handful, an OTV(100) spend is safe to better than one in a million; against a hundred it is a coin flip. The method is a bet about how many such machines exist before Bitcoin adopts post-quantum signatures, and the bet should be made with the chart in front of you.

Table B in section 4 is kind to the vault in one way an attacker would not be. Litinski's 2023 work shows a quantum computer can derive several keys in one execution by reusing its initial state, nine per run in Google's description, which Google's headline numbers exclude. An attacker building a machine for vault spends, where all 100 keys arrive together, would use it. The effect is that 100 keys become roughly a dozen batch runs, each longer and needing more qubits than a single-key run; on that assumption the one-in-a-million line holds against one machine rather than six, and a dozen batching machines would reach roughly a 13% shot. Treat the right-hand columns of Table B as the optimistic case.

Weakens as: fast-clock programmes go from one-off machines to production, and as per-key time falls, because every halving of key time halves the fleet required.

Gate 3. Primed, idle, and waiting for you

Half of Shor's algorithm depends only on the curve and can be precomputed; the machine then sits "in this primed state until a public key is available," in Google's words. A one-time key that confirms before it is derived is worthless a minute later, so there is nothing to stockpile. The fleet has to be primed and idle at the exact moment you broadcast, which could be any day, and while it waits it is not working through the roughly 6.9 million bitcoin already exposed on chain, at about three keys per machine-hour. A rational attacker drains that pool first; your spend is at the bottom of the queue until it is gone. Weakens when: exposed coins have been migrated or stolen and fleets have idle capacity, the late 2030s on any current projection.

Gate 4. Beat a block that arrives at random

This is the only gate with a probability, and the rest of the piece rests on it. Blocks arrive every ten minutes on average but at random, so the chance the next one is still pending after t minutes is e^−t/10: 41% at nine minutes, 13.5% at twenty, 0.25% at an hour. An attacker with M machines at nine minutes a key needs 9 × ⌈100/M⌉ minutes. Seven machines need 135 minutes, which the next block outlasts about once in 730,000 spends; ten machines, once in 8,000; twenty, about 1%. The tables are generous in one more way: a machine must re-prime between keys, so every round after the first really costs closer to eighteen minutes than nine. Weakens as: per-key time falls or the window is stretched (the heat map below).

Gate 5. Outbid the fee

Deriving the keys gives the attacker a signature, not the coins. Their replacement must displace yours in every miner's mempool, and since Bitcoin Core 29.0 the rule is uniform: a replacement must pay a strictly higher fee, plus an increment for its own size. A custodian signs a ladder of higher-fee versions of the same transaction before destroying the keys, so the attacker has to climb past every rung. Google notes this can become a "scorched earth" auction in which the fee eats the asset; with the odds at gate 4, it is an auction the custodian can afford to lose once in a very long time. Weakens if: never, mechanically; it is policy Bitcoin Core nodes already run.

Gate 6. The loot has to exceed the cost

Each attempt costs the attacker 100 key-derivations of quantum machine time, whatever the outcome, plus any flooding bought to stretch the window; the expected gain is the slice's value times the odds at gate 4. With a value cap per spend the attack is irrational whenever cap × odds is less than 100 × cost-per-key. At any plausible first-generation cost per key, tens of thousands of dollars of amortised capital alone, a seven-machine attacker would need a single spend in the hundreds of billions to break even. The cap starts to bind only against fleets the size of the vault. Weakens as: machine time gets cheap; review the cap whenever a credible cost estimate halves.

Gate 7. Six blocks and it is over

After confirmation the keys are dead unless the attacker can orphan the block that holds your spend. Google describes that attack, a bribe to miners to abandon the block while the keys are derived, and states that reversal cost "grow[s] exponentially in the number of blocks." Natural single-block reorganisations happen a handful of times a year; a six-block one has never been bought. A six-confirmation rule makes post-confirmation theft a majority-hashrate problem, which is a different attack on a different thing. Weakens if: hashrate centralises, which has nothing to do with quantum computing.

Large fleets and mempool flooding are the two weak points

Two gates are honest weak points: a large enough fleet walks through gate 2, and an attacker who floods the mempool stretches gate 4. Holmes and Chen worked out the hybrid in 2021: flood for about two blocks and lean on the difficulty, and Bitcoin's effective window becomes about 31 minutes. The table shows both at once, for 100 keys, so nobody has to discover them.

Heat map (derived). OTV(100), 9 minutes per key per machine, attacker never has to re-prime. "Stretched" windows model the Holmes–Chen hybrid: the target cannot confirm for 2 or 5 blocks, so the wait is a sum of exponentials. Flooding costs the attacker roughly 1 BTC per suppressed block at a 100 sat/vB fee level, and is visible on the network after about two blocks. Congestion gating and a high fee are the custodian's answer; both are cheap.

The rows that go orange and red are fleets of ten or more fast-clock machines; the rows that stay green are what exists on any roadmap before the mid-2030s. Window stretching is the attacker's strongest lever, which is why a vault spend is never broadcast into a congested mempool.

Faster keys need a new generation of hardware

Could the attacker just build a faster machine? The constraint is not the qubits but the loop around them: every layer of a fault-tolerant computation waits for a classical computer to decode the errors and feed back. Google assumes that loop takes 10 microseconds; the best published figure, from Google's own Willow processor, is 63, and that decoder does not yet feed back into the logical circuit at all. The trade that does exist is Google's: doubling the qubits roughly doubles the speed. A machine ten times faster than the first therefore needs either a decode loop ten times faster than anything built, or ten machines' worth of qubits. Either is a generation of hardware. Weakens as: decoder latency approaches 10 µs, which we would expect leading groups to reach around the turn of the decade.

Try it yourself

The whole in-flight argument is one formula. Set the dials to whatever you think the attacker has, including values more generous than anything published, and read the result. Drag minutes-per-key to one to see what a machine ten times the first does to the defence; that collapse is why section 8 exists.

The defence holds to about 2035

Through about 2032, the chance that any one OTV(100) spend is stolen in flight is below one in a million with high confidence, because that requires a fleet of seven or more fast-clock machines, which we assess at five percent or less to exist by then. Through about 2035 it stays below one percent, which requires twenty such machines, or ten plus a sustained stretching of the window. From about 2038 the construction should no longer be relied on by itself. Those dates are our synthesis of the Global Risk Institute's 2025 expert survey, the Metaculus forecast for factoring RSA-2048, and the IBM and PsiQuantum roadmaps; they are estimates, reviewed every year against the signals in section 8. That window is the medium term this method is built for, and it is wider than the window Bitcoin needs to adopt post-quantum signatures.

6. Every option gives something up

There are five other things an institution can do about this problem today or soon. The table puts them side by side on the questions a custodian actually asks: what has to change, whom you have to trust, what is protected, when it is available, and what it costs. Our row is not the best in every column, and the columns where it loses are the point of section 8.

Table A. Costs in USD at $80,000 per bitcoin, late October 2026. "Stays trustless" means the spend relies on no party beyond the ordinary Bitcoin network. QSB's reported first-spend compute cost varies by source ($50–$320) and is quoted as a range. PQ signature sizes: ML-DSA-44 ≈ 2.4 KB, SLH-DSA-128s ≈ 7.9 KB, FALCON-512 ≈ 0.7 KB; the native-output fee is an estimate from those sizes, not a published figure.

Three things the table says that we would say ourselves. QSB is stronger in flight, by a wide margin, and is the right research direction; it is not yet something a bank can run, for the reasons in its row. Native post-quantum outputs win every column except "available", and that column is why this piece exists. Hygiene alone is most of the at-rest story; the vault is hygiene enforced, multiplied by a hundred, and governed. Sidechains move the problem: the peg is a curve-key output on Bitcoin, plus trust in whoever runs it.

A vault spend costs about twenty times an ordinary payment

One input, two outputs, the payment and a fresh vault for the change: about 2,800 virtual bytes, roughly twenty times an ordinary payment (our mainnet spend, one input to one output, weighed 2,759). At 2 satoshis per virtual byte that is 5,600 satoshis, about $4.50; at 10 sat/vB, 28,000 satoshis, about $22; at 50 sat/vB, seen only in congested periods, 140,000 satoshis, about $112. All at $80,000 per bitcoin, where it closed on 26–27 October 2026, against positions typically eight or nine figures. OTV(20) for operational wallets costs about a quarter, roughly $5.40 at 10 sat/vB. There is no other cost: ordinary key-generation and signing calls, a standard transaction, nothing paid to anyone but the miner. A custodian with Bitcoin signing in place can pilot on signet in weeks and on mainnet the quarter after.

7. Most objections are true, and the design accounts for them

We wrote this section before publishing by asking what the sharpest reviewers in three communities, Bitcoin Core, quantum computing, and bank custody, would say first. Here is what they would say, and what is true in it.

"Isn't 100 keys just 100 machines?"

Yes. Google says it plainly: the attacks "parallelize trivially", which is why every curve in Figure 3 reaches 41%, and spare machines push past it. What the objection misses is the other half of the same paragraph: against an attacker with a small number of machines, which is what the first generation will be, deriving 100 keys in ten minutes is exactly the obstacle. The method is a bet on fleet size over a window of years, and the fleet sizes are in a table rather than a slogan: a seven-machine fleet is unlikely before about 2032, twenty before the mid-2030s, and a hundred, or one machine a hundred times faster, is a late-2030s proposition on anything published today.

"What about one bigger machine?"

Also true. Google notes that doubling the qubits roughly doubles the speed, and that eleven primed machines working one key together get a 6.5× speedup. A machine a hundred times the first would do 100 keys serially inside a block; it is also a hundred times harder to build than one that does not yet exist. The question for a risk committee is not "can this be beaten in principle" but "by whom, when, and at what cost per spend", and section 8 gives the signals that say when to stop relying on it.

"Attacks always get better."

They do, and the trend is the strongest argument for treating this as a bridge. Between 2017 and 2026 the estimated cost of breaking one secp256k1 key fell by orders of magnitude on every axis: roughly 1,800× fewer Toffoli gates from Roetteler et al. to Google, about 20× fewer physical qubits from Litinski's photonic estimate to Google's superconducting one, and about 10× less spacetime volume between the two most recent. A defence worth 6.6 bits can be erased by one good paper. That is why the migration plan in section 8 is part of the method, not an afterthought.

"This isn't post-quantum cryptography."

In flight, correct, which is why we say resilient and not resistant. At rest it is: a SHA-256 commitment and an SLH-DSA approval gate are post-quantum cryptography in the ordinary sense. The in-flight security of a 100-Key Vault still rests on ECDSA over secp256k1, which NIST's draft transition timeline (IR 8547) lists as disallowed after 2035 and CNSA 2.0 phases out for national security systems by 2033. Neither binds a commercial custodian, but no auditor will call ECDSA post-quantum, and we do not ask them to. What the method gives you is the only post-quantum property Bitcoin can express today, the hash at rest, a hash-based governance layer around the spend, and a quantified work factor in the one window where Bitcoin cannot yet help you.

"Bitcoin never verifies your hash-based approvals."

True by construction. Bitcoin checks 100 ECDSA signatures and nothing else; the SLH-DSA approval is enforced off-chain, by the software that decides whether the keys are asked to sign. Its job is not to make the chain post-quantum but to ensure the one moment of exposure happens only when the right people have agreed to the exact transaction, so the attacker's only route is the race and not the approval. Who can trigger the signatures is answered two objections below; section 8 shows how the same approval trail becomes the migration record.

"The window isn't really ten minutes."

Correct. Blocks are random, the mempool can be flooded, and the Surrey paper's hybrid attack puts Bitcoin's effective window at about 31 minutes if an attacker pays for it. The heat map in section 5 shows what that does: against seven machines the odds go from one in 730,000 to one in 2,400; against twenty, from 1% to 22%. So a vault spend is never broadcast into a congested mempool and always pays a next-block fee with margin, which is cheap and removes most of the lever. And the window argument only bites against fleets of ten or more fast-clock machines, the same fleet the first objection already needs: it makes an existing large attacker more dangerous, not a new one.

"Wouldn't they just go after the exposed coins first?"

Yes, and that is a guard, not a gap. About 6.9 million bitcoin already sit with keys visible on chain, attackable at leisure at roughly three keys per machine-hour, with no race and no deadline. The first owner of a quantum computer has years of that work waiting. A vault spend, by contrast, requires the whole fleet idle and primed at the exact second of broadcast for a capped slice behind a hundred keys. It is the worst target on the list, and it stays that way for as long as the list exists.

"What about a reorg?"

Google describes it: when a high-value key first appears in a block, an attacker can pay miners to orphan that block while the quantum computer works on the key, then collect in the replacement. It is real, and it means the window does not end at the first confirmation. It also requires buying a chain reorganisation, which is expensive, public, and grows exponentially harder with every block; natural ones are a handful of single-block events a year. The method's response is a rule: a vault spend is final at six confirmations, and the value in any one spend is capped so that buying a reorganisation is never worth it.

"At rest, you're just a SegWit address."

Yes. Every unreused bc1q address hides its key behind a hash, and Google's paper recommends exactly that hygiene as the first mitigation. The at-rest property is Bitcoin's, not ours. What the method adds is enforcement: a vault address cannot be reused, cannot be exposed through a shared master key, and cannot be spent without the hash-based approval, and when it is spent, the attacker faces 100 keys rather than one. Hygiene that is enforced by construction is worth more than hygiene that is recommended.

Two further objections come from custody rather than quantum computing, and they are the ones a bank's reviewer asks first.

"Who can trigger the 100 signatures?"

Ordinary signing devices, HSMs included, sign whatever they are asked to sign; they cannot see a hash-based approval. If one program can ask all 100 keys to sign, that program is the custody, and anyone who compromises it needs no quantum computer. The method's answer is that no single system may hold that power: the 100 keys are spread across independent signing systems under separate control, including one the asset owner runs, and each checks the hash-based approvals against the exact transaction before signing its share. Stealing means breaching all of them at once, the standard every multi-party custody system is held to. The operating rules that make it concrete are a custodian's implementation, published separately.

"What if one of the 100 keys is lost?"

A script that needs all 100 keys has no mercy on its own: one failed device and the coins are gone. The answer uses the same hash that hides the main path: the witness script can carry a second spending path, for a separate recovery quorum, that opens only after a fixed date. Like the main path, it is hidden only while the vault is unspent. A P2WSH spend reveals the whole witness script, unused branch included, so every ordinary spend also publishes the recovery keys, and they are retired with the vault. That is why the lock must be a date, an absolute timelock, with each vault rolled into a fresh one before it arrives: a relative delay would already have run out on any vault older than the delay, and an attacker racing an ordinary spend could take the coins through the recovery path, which has far fewer keys. The branch also costs one main key, 99 instead of 100, because choosing a path takes one of the 100 witness items Bitcoin Core relays, and the recovery quorum fits in the remaining script space only up to about three keys. If a key is lost, the custodian waits for the date and moves the coins to a fresh vault; that recovery spend races with only the recovery quorum's keys, so it is for emergencies. It is the timelock machinery that has protected cold storage since 2016, placed behind a one-time hash.

8. One spend moves the vault to post-quantum outputs

Everything above is designed to be temporary. When Bitcoin activates native post-quantum outputs, a 100-Key Vault migrates in one ordinary spend: the 100 keys sign a transaction whose output is a post-quantum address, the keys are revealed once, the coins are then locked by a signature scheme no quantum computer can forge, and no curve key has ever been visible at rest at any point in the coins' history. That last property is the one that matters. Coins that spent the waiting years in a Taproot address, or in a reused address, carry an exposed key into the migration and have to run the race one last time with the whole world watching; coins that waited in a One-Time Vault run it on their own terms, in a transaction of the custodian's choosing, with 100 keys.

Two more things the method leaves behind for that day. The hash-based approval trail, kept off-chain, is a timestamped record of every spend decision that no quantum computer can have forged, which is the kind of evidence a BIP-361-style recovery phase or a regulator will want. And the discipline itself carries over: post-quantum signatures are large, and the value caps and recovery paths a custodian learns now are what it will run then, with different keys.

Five signals mean it is time to move

A bridge is only honest if you say when to get off it. The dates in the chart in section 2 are reviewed every year against the indicators in section 5. Any one of the following signals means the in-flight bet is no longer worth making, and cold reserves should move to the strongest construction available at the time, whether that is native post-quantum outputs or a hash-locked spend path that has by then become standard:

• A publicly demonstrated fault-tolerant machine passes roughly a thousand logical qubits on a fast-clock platform.
• A logical error rate below one in a hundred million is demonstrated at scale.
• A published estimate cuts the cost of breaking a 256-bit curve key by another factor of five.
• Any unexplained theft from an address with an exposed key.
• Native post-quantum outputs activate on Bitcoin.

The bridge is the point. It is what lets a custodian say, truthfully, that its bitcoin was never exposed at rest and that it never had to choose between acting now and waiting for the protocol.

9. Four steps can start this quarter

It runs on standard tools, and the code is open

The cost is in section 6: a few dollars to a little over a hundred per spend, nothing to anyone but the miner, no new hardware. Everything here is standard Bitcoin and standard signing-device operation, and a custodian or a capable individual can build it from the description above or start from our open-source reference implementation, which made the mainnet spend. A ready implementation for custodian banks exists as EternaX Bitcoin Vault; ask for the details, which are deliberately not in this piece.

11. Glossary and references

1. Babbush, R., Zalcman, A., Gidney, C., et al. Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations. Google Quantum AI, Ethereum Foundation, Stanford. arXiv:2603.28846, March 2026. arxiv.org/abs/2603.28846
2. Litinski, D. How to compute a 256-bit elliptic curve private key with only 50 million Toffoli gates. arXiv:2306.08585, 2023.
3. Roetteler, M., Naehrig, M., Svore, K., Lauter, K. Quantum resource estimates for computing elliptic curve discrete logarithms. ASIACRYPT 2017; ePrint 2017/598 (9n+2⌈log₂n⌉+10 qubits, 448n³log₂n+4090n³ Toffolis). eprint.iacr.org/2017/598
4. Gidney, C. How to factor 2048 bit RSA integers with less than a million noisy qubits. arXiv:2505.15917, 2025.
5. Lopp, J., Papathanasiou, C., Smith, I., Ross, J., Vaile, S., Dallaire-Demers, P.-L. BIP-361: Post Quantum Migration and Legacy Signature Sunset. Draft, 2026. github.com/bitcoin/bips
6. Beast, H., Heilman, E., Foxen Duke, I. BIP-360: Pay to Merkle Root. Draft, merged February 2026.
7. BIP-141 (Segregated Witness), BIP-143 (transaction signature verification for version 0 witness program), BIP-341 (Taproot).
8. Bitcoin Core, src/policy/policy.h: MAX_STANDARD_P2WSH_SCRIPT_SIZE = 3600; MAX_STANDARD_P2WSH_STACK_ITEMS = 100; MAX_STANDARD_P2WSH_STACK_ITEM_SIZE = 80. github.com/bitcoin/bitcoin
9. Bitcoin Core 28.0 release notes (full-RBF default) and 29.0 release notes (option removed). bitcoincore.org/en/releases/28.0
10. NIST IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards, November 2024.
11. NSA, Commercial National Security Algorithm Suite 2.0 and FAQ.
12. Levy, A. Quantum-Safe Bitcoin Transactions. StarkWare, April 2026. github.com/avihu28/Quantum-Safe-Bitcoin-Transactions; StarkWare, The first quantum-safe Bitcoin transaction has been mined, August 2026.
13. Heilman, E., public estimate of migration duration, Cointelegraph Magazine, February 2026.
14. Holmes, S., Chen, L. Assessment of Quantum Threat To Bitcoin and Derived Cryptocurrencies. University of Surrey, IACR ePrint 2021/967. eprint.iacr.org/2021/967
15. Google Quantum AI. Quantum error correction below the surface code threshold. Nature 638, 920–926 (2025); arXiv:2408.13687 (1.1 µs cycle; 63 ± 17 µs decoder latency).
16. Mosca, M., Piani, M. Quantum Threat Timeline Report 2025. Global Risk Institute / evolutionQ, March 2026.
17. Metaculus, "When will the RSA-2048 challenge number be factorized by a quantum computer?", community forecast, accessed October 2026.
18. Bitcoin Core 29.1 release notes (incremental relay fee default lowered to 0.1 sat/vB). bitcoincore.org/en/releases/29.1
19. One-Time Vault OTV(100) on Bitcoin mainnet, 28 October 2026: funding b77b3538…1085 (block 973,544); 100-signature spend 397b3672…220c (block 973,546, MARA Pool).
20. EternaX Labs. eternax-bitcoin-vault: open-source reference implementation, tests and measured results (Bitcoin Core v31.1, Bitcoin Knots v29.2, signet, mainnet). github.com/eternax-ai/eternax-bitcoin-vault
21. Bitcoin Knots v29.2, -maxscriptsize (default 1,650 bytes, the whole witness stack); OCEAN, Node Policy. ocean.xyz/docs/nodepolicy

Change log

28 Oct 2026: added the mainnet transaction links and the open-source reference implementation. Removed the multi-input setting: splitting a vault across inputs adds no work for an attacker, since each input falls to its own keys. Scoped relay claims to Bitcoin Core's default policy and noted Bitcoin Knots' 15-key limit. Corrected the Taproot advice, the hardware-wallet answer, the recovery-path description, the 41% ceiling and the spend size to the measured mainnet figure.

27 Oct 2026: first publication. Numbers with a shelf life carry their as-of date in the text: the bitcoin price in the cost section, the fleet-date estimates, the BIP statuses and the Metaculus median. This piece is reviewed every year against the migration signals in section 8 and revised when any of them moves; changes are listed here.

Figures in this piece are redrawn from the cited sources or computed from the stated model; the model's code and the full machine-count tables are in the operating rules and security model document. Nothing here is investment, legal or regulatory advice.