A quantum computer will not be able to rewrite Bitcoin's ledger. It will probably be able, one day, to open some of its locks. Telling those two things apart is almost everything needed to understand the problem; the rest is getting the numbers, with dates attached
Two fears confused into one
«Sooner or later the quantum computer will break Bitcoin.» The sentence has been circulating for years and produces two equal and opposite reactions: alarm from those who take it as a sentence already written, and a smile from those who stopped listening because the sentence keeps being postponed. They are two symmetrical errors, and they come from the same flaw. The flaw is not in the answers: it is in the question. Inside that «will break» live two different fears, and they need separating at once, because they have different natures, different timescales and different remedies.
The first fear concerns the ledger: that a powerful enough machine could rewrite the history of transactions, erase payments that happened, spend the same coins twice. That would be the end of agreement on a single shared truth, the thing Bitcoin exists for.
The second fear concerns the locks: that the same machine could derive, from information already public on the chain, the private keys of some wallets, and therefore sign in place of their rightful owners. The ledger would stay intact, ordered, shared; what would change is whose hands can move certain coins.
The first fear is unfounded, and not out of optimism: because of the nature of the problem, as will be seen shortly. The second is well founded. It has no date, but it has a surprisingly precise perimeter: it is already known today which coins are exposed and which are not, to the point that the count should not be taken on trust: we redid it ourselves, independently. A companion piece devoted to the data shows the numbers in full, with the fingerprints to check them (the tools ready to redo it from scratch will follow in a piece of their own).
From here on the text tries to keep the two planes apart, under three declared rules: distinguish what is demonstrated from what is projected; give every estimate its source and its date; declare the date of the text itself, July 2026, because on this subject numbers age in months and an honest picture has to say when it was taken.
There is a single image worth carrying through the whole piece. Quantum computing does not produce tools for forging the ledger: it produces tools for picking certain safe deposit boxes, the ones whose lock has been left in plain sight.
What a quantum machine can actually do
Fortunately there is no need here to understand how a quantum computer works; what is needed is knowing what it would do better than a «conventional» computer. And the list, as far as the ground that touches Bitcoin is concerned, is short: two algorithms, discovered thirty years ago, long before machines existed that were remotely able to run them.
The first is Shor's algorithm (1994). It quickly solves two mathematical problems that are in practice impossible for a classical computer: factoring large numbers and the discrete logarithm. This is no specialist detail: almost all public key cryptography in use rests on those two problems, Bitcoin's signatures included. And Shor's gain is exponential, which does not mean «faster»: it means of another category altogether. A computation that would take longer than the age of the universe becomes a matter of hours or days, on one condition: that a machine exists large and stable enough to run the algorithm all the way through. This is the real threat, and that is all of it.
The second is Grover's algorithm (1996). It speeds up search by trial, the brute force approach, and its gain is only quadratic: it halves exponents, it does not bring down walls. Against SHA-256, the hash function Bitcoin uses everywhere, Grover brings the cost of a search from 2^256 to about 2^128 quantum steps. But halving the exponent of an impossible mountain leaves an impossible mountain: 2^128 stays out of reach for any sensible horizon, quantum or not.
Here is the point that popular accounts sometimes lose along the way: «quantum computing» does not mean omnipotent. It means exponentially stronger on a narrow class of problems, and barely stronger on everything else. The map of the threat traces the boundary of that class, and this is why it can be drawn precisely.
One last piece of groundwork, so that the numbers in the next sections make sense. Quantum machines are measured in qubits, but one must always ask which qubits are being talked about. Physical qubits are the ones that exist in laboratories: noisy, unstable, error prone; machines are announced in physical qubits. To run Shor on a real key, however, logical qubits are needed, reliable ones, obtained by grouping many physical qubits into error correcting codes: the ratio between physical and logical, with today's techniques, is measured in hundreds or thousands to one. The estimates one reads around use now one unit and now the other, and comparing them without noticing is the most common mistake in the debate. It is in that ratio, more than in the raw count, that the distance between the laboratories and the threat is decided. The state of the art, with dates, comes two sections from here.
The map: what it touches and what it does not
A minimum of anatomy is needed, three pieces in all. Whoever «owns bitcoin» in fact owns a private key: a secret that allows a digital signature to be produced, the mathematical proof that authorises a spend. To the private key corresponds a public key, with which anyone can verify the signature without being able to sign in turn. And on the chain the coins are closed by a small lock written in a scripting language, which states what is needed to open them: in the most common case, a valid signature against a certain key.
Signatures are the target. Bitcoin signs on elliptic curves (ECDSA and, since 2021, Schnorr as well), and the security of these signatures rests on the discrete logarithm: exactly the problem Shor brings down. From a public key, an adequate quantum machine would derive the private one. But there is a detail that decides everything, and that headlines always skip: the public key is needed in the clear. And the protocol, given how it has grown over fifteen years, does not always show it. What comes out is a hierarchy of exposure worth looking at closely, because it is the backbone of the whole rest of the text:
- Exposed for a long time. Two different families fall in here, and the distinction holds up the whole count further on. Exposed by construction, that is from the first day: the coins of the earliest years, in the P2PK format, where the lock is the public key, written out in full on the chain, Satoshi's era; and the coins on Taproot, the most recent format, where the key sits in the output by design of the format, a choice made with open eyes, for other benefits, when the threat looked further away. Exposed by reuse, that is from a certain spend onwards: the coins on reused addresses, where the first spend reveals the key to the world and the chain does not forget; every coin left on, or returned to, that address is exposed for good. And a partial spend is enough to end up there: a transaction moves the coins it chooses, not the whole address, and what it leaves behind stays closed by a key that is now in the shop window.
- Exposed for minutes. Any spend, on its journey towards the block. To be verified by everyone, a transaction must attach in the clear the public keys of the addresses it draws from: the signature is checked with the key, and the chain, for addresses protected by a hash, keeps only its fingerprint. And from the moment it is sent the transaction propagates node to node across the whole network in seconds: the mempool, the waiting room of transactions, is a public square, not a sealed envelope. Until the block that includes it, on average some ten minutes, those keys still guard the coins in transit; afterwards they stay written for ever, but the danger ends because the coins have moved on to new locks. For well managed coins, the ones in the class below, this window is the only exposure of their entire life: it is the measure of the residual threat when every good practice is respected. Today it is an idle observation; it stops being idle the day a machine could derive the private key within that window. The most recent estimates on this point (Google Quantum AI, March 2026, section 4) describe idealised scenarios in which the computation would drop below the time of a block: generous assumptions, no operational capability, but a signal that the ten minute window is not a refuge in principle.
- Protected until spent. The coins on addresses protected by a hash and never reused. There the public key is not on the chain: only its fingerprint is, its hash, and hashes are Grover's territory, not Shor's. The key shows itself only at the moment of spending; until then there is nothing to attack.
Two less visible entries must be added to this hierarchy. The first sits on the chain but shows itself only at the end: encapsulated locks (P2SH and P2WSH, where multisig typically lives) reveal at spending time the entire script they contain, including the public keys of the cosigners who did not sign that transaction. The second the chain does not record at all: public keys shared off chain. Whoever has handed a service an extended key (xpub: the key from which a wallet derives all its own addresses, typical of watch-only services and custodians) has exposed the entire branch, and no on-chain analysis sees it.
Hashes hold. SHA-256 is everywhere in Bitcoin: in proof-of-work, in commitments, in the trees with which blocks summarise transactions. Against hashes the quantum arsenal offers only Grover, and it has been seen what that is worth. Mining, moreover, is not even a target of the right kind: it is not a problem to «break» but an economic race of attempts per second per watt, against classical hardware optimised to the extreme; a realistic quantum machine, with its slow qubits, its error correction and an algorithm that parallelises badly, would not be competitive. The rule of the chain with the most work is not in question.
The agreement is not even attackable. Against «the chain with the most accumulated work wins» there is no quantum algorithm, because it is not a mathematical problem: it is an economic convention. What is not a computation cannot be broken by computing.
The summary of the map, and it is the sentence everything that follows rests on: quantum computing attacks the level of ownership, who can spend; it does not touch the level of consensus, which history counts. The cost barrier that guards the past stays standing. What will change, one day, is the cost of impersonating owners.
How close it is: the state of the art, with dates
This is the section that will age fastest, and it is right that it should declare its own date: the snapshot is July 2026. To take it honestly it helps to keep apart three planes that news reports tend to mix: what the machines have done, what the calculations say would be needed, what the laboratories have.
What has been done: toys. In September 2025 a 6 bit elliptic curve key was broken with Shor's algorithm on a publicly accessible IBM machine; in April 2026 the record rose to 15 bits, awarded a bitcoin by Project Eleven's Q-Day Prize, a competition set up precisely to measure this progress. Bitcoin uses 256 bit keys, and the scale is not linear: each extra bit roughly doubles the difficulty, so between 15 and 256 there is no factor of seventeen, there are more than two hundred doublings. No real key is in danger today; on this at least the two extremes of the debate ought to agree.
What would be needed: less and less, and that is the news. Resource estimates, that is the calculations of how much machine it takes to run Shor on a real key, are falling at a speed the numbers tell by themselves:
- to factor RSA-2048, which is not Bitcoin's problem but is the historical yardstick of these estimates: from about 20 million noisy physical qubits (Gidney and Ekerå, 2019) to fewer than one million (Gidney, May 2025). Twenty times less in six years, and not through progress in machines: through progress in algorithms and error correction, that is, on paper;
- for the 256 bit discrete logarithm, Bitcoin's problem: Google Quantum AI (March 2026, with the Ethereum Foundation and Dan Boneh among the authors) estimates circuits of fewer than 1,200 logical qubits and, on a superconducting architecture with an error rate of one in a thousand, a run in minutes with fewer than 500,000 physical qubits. It is the paper the «below the time of a block» quoted a section ago comes from, and it is the same paper that declares its assumptions: microsecond gates, mature error correction, precomputation already done. An order of magnitude, not an operational capability;
- lower still: a Caltech-Harvard group (same month; among the authors Preskill, Endres and Bluvstein, leading names in the field) calculates that on reconfigurable neutral atoms, with more efficient correcting codes, Shor at a cryptographically relevant scale would become possible with as few as 10,000 physical qubits; for a 256 bit key, in practice, about 26,000 and a few days of computation. Here too, and the authors write it themselves: a theoretical resource estimate with considerable engineering challenges ahead, not a machine;
- even the «textbook» number of logical qubits needed keeps falling: 2,124 in the reference estimates of the past decade, 1,333 in a paper from April 2026.
What there is: machines of hundreds or a few thousand noisy physical qubits. Between what exists and what would be needed there remain orders of magnitude, and that is the reason practical demonstrations are still stuck at toys. But the picture must be read in motion: the machines grow and the requirements fall, and the two curves are looking for each other. The new fact of 2025-2026 is not closeness, which is absent; it is the speed at which the gap narrows, and the fact that it narrows from both sides.
Two considerations must be added to this snapshot, and they do not age, because they do not depend on the numbers.
The first: the time of the defence must be subtracted from the time of the attack. Migrating Bitcoin onto new signatures is not a software update: it is a consensus to be built on the rules, plus a voluntary migration by millions of holders, and the history of the protocol says the timescales are measured in years (the three sections that follow are devoted to this). The right comparison is not «when the machine will arrive» but «when it arrives, minus how long it takes to move house». It is the arithmetic that explains why the subject is already on the agenda without an immediate threat: whoever waited to see the machine would already have spent the time that was needed.
The second: for Bitcoin, the harvest has already happened. In the world of encrypted communications people speak of «harvest now, decrypt later»: recording traffic today to decipher it when the machine exists. For public keys already written on the chain not even that step is needed: they are collected, ordered, replicated across tens of thousands of nodes, for ever. The most patient archivist imaginable is the ledger itself. Immutability, which elsewhere in this system is the guarantee, here works against its own users.
The coins that wait: how much of the ledger is exposed
How much does the class of visible-key coins weigh, then? The public estimates, with their dates. Deloitte, in an analysis from 2019-2020, counted about 4 million vulnerable BTC, a quarter of the supply at the time: about 2 million in the original P2PK format plus about 2.5 million on reused addresses. The text of BIP-361, the migration proposal discussed further on, with data as of 1 March 2026 raises the bar: more than 34% of all bitcoin has a public key already revealed on the chain.
Why two estimates so far apart? Not only because time passes. The bulk of the count sits in reuse, and reuse cannot be read from a snapshot of the present: to know whether an address's key has already been shown, the entire history of transactions must be rewound, and every analysis rewinds it by its own criteria. That is where the public numbers diverge, and that is where part of the count has to be taken on trust.
Part of it, though, does not. The numbers that follow we did not take on anyone's word: we recomputed them ourselves. In early July 2026 (block 957,301) a census of the UTXO set, the collection of all coins spendable at that moment, carried out for this piece on our own node with a program of a few hundred lines, gives this picture:
- the coins exposed by construction, the ones whose lock shows the key with no need of history (the original P2PK, Taproot, plus a dust of old bare multisig scripts), amount to 1.93 million BTC, 9.64% of all coins in existence. It is a certain and reproducible lower bound: anyone redoing the count at the same block height must obtain exactly the same numbers;
- inside that bound, the two main populations could not be more different. P2PK is worth 1.72 million BTC and is a fossil: 97% of those coins were created before block 100,000, that is roughly before the end of 2010. Taproot is the opposite: 54 million locks but barely 217,000 BTC, all recent and fragmented.
The comparison with the public numbers should be read for what it is: not three estimates competing over the same quantity, but three different perimeters. The 9.64% counts exposure by construction alone, and it is deliberately narrow: it is the part of the picture that requires no criteria, only a count, and for that reason it can be expected to come out right to the satoshi. The public estimates take in reuse as well, and there the perimeters each widen in their own way: Deloitte was writing in 2019-2020, when Taproot did not yet exist, and added the original P2PK to the reuse its scan recognised; BIP-361 counts, as of 2026, every key already revealed on the chain, Taproot included. The difference between the floor and the 34% measures how much of the picture rests on someone else's methodology: about a quarter of all coins, almost entirely reuse.
The floor can be checked with one command. Reuse, for this piece, did not remain an estimate: the same scan that anyone can redo went through the entire chain twice, by two independent routes that must give, and did give, exactly the same number, down to the fingerprint. At block 957,301 the coins protected by a hash but with the key already shown through reuse are at least 5.08 million BTC, across 8.78 million locks: a minimum, like every figure in this piece.
Adding the floor: 7.02 million BTC, about 35 per cent of all coins in existence, have their key in view. It is the third route arriving at the same place. The text of BIP-361 counts more than 34 per cent; Glassnode's analysis of May 2026, with proprietary data, puts the floor at 1.92 million against our 1.93; Coinbase's advisory council speaks of about 7 million. The difference is that this route can be walked again: the replication contract and the fingerprints are in the appendix of the companion piece, and the part of the picture that previously rested on someone else's methodology we have now measured ourselves.
In summary, at block 957,301:
| keys already in view | BTC | of circulating supply |
|---|---|---|
| exposed by construction (P2PK, Taproot, bare multisig) | 1.93 M | 9.6% |
| exposed by reuse (key shown by a past spend) | 5.08 M | ~25% |
| total with the key in view | 7.02 M | ~35% |
And it is worth saying in which direction these numbers are wrong, if they are wrong: on the low side. No on-chain count, ours included, sees keys shared off chain, the xpubs handed to services and custodians discussed in the map of exposure. If the true picture departs from the 35 per cent measured here, it is more likely to depart upwards.
Inside the P2PK fossil sits the emblematic case of the whole question: the roughly one million BTC attributed to Satoshi Nakamoto, untouched since the earliest years. Nobody can migrate those coins except whoever holds their keys, and nothing suggests anyone still holds them. If one day they were to move «by themselves», an outside observer would have no way of deciding what they were looking at: the return of the rightful owner or the first theft in history by quantum computing. A signature proves possession of the key, not the identity of whoever uses it; the day the key can be derived, the proof stops distinguishing. This undecidability is worth keeping in mind: the text comes back to it, among the coins nobody can move any more.
One last note, to weigh the scenario without loading it. Vulnerability is neither binary nor simultaneous: even on the day the machine existed, it would be scarce, slow and expensive, and a rational attacker would queue up the targets, the largest and most dormant first, not millions of wallets in one night. And even before the thefts the news would arrive: the first credible demonstration that keys can be derived would land on trust, and therefore on price, long before the attack could scale. The economic scenario precedes the technical one; the threat is not a switch that turns the system off, it is an incentive that builds.
How that value became exposed over time is a story of its own: which locks, in which years, at what pace, and why exposure grows while the habit of reuse improves. It has a piece of its own, the companion to this one: the history of reuse, read from the data.
The technical solutions: new signatures, new addresses
The easy part of the answer already exists, at least on paper. In August 2024 NIST, the American standards body that in practice sets the world's cryptographic standards, published the post-quantum signatures: ML-DSA (FIPS 204), built on lattices, a family of mathematical problems that no known quantum algorithm can bring down, and SLH-DSA (FIPS 205), built entirely on hash functions. The second has a property that by this point in the text sounds familiar: it asks nobody to believe in any new assumption, it rests on hashes alone, the territory where quantum computing gains little or nothing. Signatures like these are not frontier research: they are published engineering, with specifications, implementations and certifications. The problem is not making them exist. It is where to put them.
Because these signatures are large, and on a chain where every byte is bought size is not a technical detail: it is the price. The numbers, taken from the tables of the two standards:
| scheme | NIST category | public key | signature | to present in order to spend |
|---|---|---|---|---|
| Schnorr (BIP-340), today | elliptic curves | 32 bytes | 64 bytes | 96 bytes |
| ML-DSA-44 | 2 | 1,312 | 2,420 | 3,732 (~39×) |
| ML-DSA-87 | 5 | 2,592 | 4,627 | 7,219 (~75×) |
| SLH-DSA-128s | 1 | 32 | 7,856 | 7,888 (~82×) |
| SLH-DSA-128f | 1 | 32 | 17,088 | 17,120 (~178×) |
(The NIST category measures the declared security margin: 1 is equivalent to forcing AES-128, 5 to AES-256. The final letters tell the internal trade-off: the «s» of small signs short but slowly, the «f» of fast the other way round.)
Translated into weight, with the discount the protocol grants today to unlocking data and at equal transaction structure (this is a calculation of ours, and it must be declared for what it is: none of these schemes is in the protocol, the numbers serve the order of magnitude): a Taproot input that today weighs about 58 vbytes would weigh about 980 with ML-DSA-44, seventeen times as much, and about 2,000 with SLH-DSA-128s, thirty-five times. Fees are paid by the byte, so spending would cost in proportion; and into the same block space would fit fifteen to thirty-five times fewer spends. Resistance to quantum computing is not invented: it is bought, and the currency is space.
And this is where the story of the main proposal on the table becomes
instructive, because its public path tells the problem better than any
summary. BIP-360 is born at the end of 2024 under the name P2QRH with the
post-quantum signatures on board: three schemes, tables, everything together.
Then the revision log, public as well, documents the diet: in January 2025
SQIsign goes, too expensive to verify; in July 2025 the signatures themselves
go, on which the authors declare the research still open; in February 2026
the project takes its final name, Pay-to-Merkle-Root (P2MR). Today (June
2026, version 0.12.0, status Draft) BIP-360 proposes one thing only, small
and precise: a Taproot without its vulnerability to quantum computing. It was
seen, in drawing the map, that Taproot puts the key in the output by
construction; P2MR is the same design with that spending path removed: on the
chain only a Merkle root remains, a hash, and hashes hold. A new SegWit
version, addresses that would begin with bc1z, and no key in the shop
window.
It is worth saying precisely what it would buy and what it would not. It would buy protection for coins at rest: the long exposure, the one just measured, would disappear for migrated coins. It does not buy, on its own, protection at the moment of spending: when a P2MR script reveals itself in order to be executed, the keys it contains are still elliptic curve keys, and the window of minutes stays what it is. The post-quantum signatures of the table above would come in at a second stage, inside the same design, as new leaf languages. It is a recognisable strategy: first the grip, then the plug. And it can be read in two ways, both true: as the caution of those who do not want to cement into the protocol a standard that might age badly, and as the measure of how much less mature the problem is than an announcement suggests.
Two properties should be kept for the section that follows. The first: P2MR would be a soft fork, an opt-in narrowing of the rules; it adds new locks alongside the old ones and closes none of them: migration remains up to whoever holds the keys. The second: the technical repertoire around it is richer than it seems, the discussions carry one-time signatures built on hashes alone (Lamport, Winternitz) as an emergency fallback and commit-reveal schemes that would protect even spending under attack at the mempool: the ten minute window, if wanted, has countermeasures. What is missing is not the engineering. It is what no engineering produces by itself: the decision about what to do with the coins nobody will ever migrate.
In the meantime: what someone with a wallet can do
The new signatures will arrive in their own time, which does not depend on the reader. But a defence already exists today, and it is not technical: it is conduct. To understand it, it is enough to go back to the locks. A modern address, in the form wallets propose first, is protected by the fingerprint of a key and not by the key itself: as long as it only receives, the key has never appeared anywhere. It appears at the moment of spending, inside the transaction that unlocks the coins, and it applies to that lock alone, because every address of a modern wallet is born from a different key. Hence the rule, and it is a single one: a new address for every receipt, and never anything again on an address that has already spent. Wallets have been doing this by themselves for years, including with transaction change, which always returns to a fresh address. Reuse, today, is almost always an operational choice, not a fate: and the numbers of the census say how much it is still practised.
This protection has three limits, and it is worth seeing them in a row.
The first: at every spend the protection breaks for a few minutes. Between sending a transaction and its confirmation the key is public and the coins are still there. It is a window that would matter only in a scenario where a machine already existed, mature and fast enough to exploit it; but it is a real limit, and it remains even when every other precaution is respected.
The second: the protection covers only what has not already been handed to others. A modern wallet is a tree: from a seed the accounts are born, from each account the keys, one per address. What leaves the house decides how much is exposed:
- an address: exposes a single key, and only when that address spends;
- an xpub, the extended public key of an account, the one handed to watch-only services and to some custodians: it exposes in one go the public keys of all the addresses of that account, present and future. For the threat under discussion it is equivalent to having already reused every address of that account;
- the seed: here the matter changes nature. Whoever has the seed has the private keys, and can spend today, with no need of any quantum machine. It is not a wider step on the same ladder: it is where the ladder ends.
The first two steps also explain why the census counts are wrong on the low side: the xpubs that have been handed over cannot be seen from outside.
The third, and it is the most important: the precaution buys time, not exemption. When the migration to new signatures arrives, it will have to be done anyway.
A clarification about Taproot, the most recent format, the one that begins
with bc1p. There the key is in view by construction, and the new-address
rule does not hide it: it is the case where the precaution buys nothing. It
is worth keeping this in proportion, though: Taproot is not today the most
widespread format, nor the one most wallets propose first. The numbers
already seen say so: under Taproot sit 217,000 BTC, while the bulk of the
value still lives on hash-protected formats. Whoever uses Taproot has
usually chosen it, for properties they need. It is worth, then, that the
choice takes this in too: in a quantum computing light, and only in this
light, a large value meant to sit still is better sheltered on a
hash-protected format, a bc1q… never reused, than on Taproot, where the key
is visible from the first day.
The point of all this is not the anxiety of the right move. It is that conduct is the only defence, in this story, that delegates trust to nobody: not to the protocol to come, not to a custodian, not to the timing of the collective decision. Whoever practises it has not solved the problem; they have bought the thing that in the next section is missing for everyone: the time to decide knowingly, whatever the generals decide. Between suffering a question and standing guard over it, the difference is almost entirely here.
The important point: the coins that cannot migrate by themselves
The whole discussion of solutions, however, has a silent premise: that behind every coin there is somebody able to move it. For those coins the problem is solvable with time and incentives: the new locks arrive, wallets update, whoever holds the keys migrates. But the ledger also holds the coins of those who cannot answer: lost keys, vanished owners, fortunes dormant for fifteen years. The census measured the fossil: 1.7 million BTC in P2PK alone, almost all untouched since before 2011, with the million attributed to Satoshi in the middle. No incentive will move them, because there is nobody to incentivise. And so, as the threat drew closer, the network would find itself facing a question no algorithm can absorb: what are these coins?
There are two ways out, and it is honest to say at once that both are unpleasant.
The first: leave them spendable. It means accepting that, on the day the machine existed, the first to get there takes them: an enormous and silent redistribution of wealth towards whoever wins the race to quantum computing capability, governments or laboratories or anyone else. With two aggravating factors. The stolen coins would be perfectly valid: correct signatures, regular transactions, no rule broken; a ledger flooded with loot indistinguishable from legitimate money. And the undecidability seen two sections ago would do the rest: the network could not even say with certainty that a theft had occurred, because a signature proves possession of the key, not the identity of whoever uses it.
The second: freeze them. It means that the network, on an announced date, stops accepting the old signatures, and in doing so makes other people's coins unspendable without their owners' consent. For a system built around «not your keys, not your coins» this is an almost constitutional taboo: it would be the first deliberate violation of property at the protocol level, however well intentioned, decided by those who are present at the expense of those who are not. If the owner of the dormant coins still exists, somewhere, the freeze expropriates them in order to protect them.
BIP-361, «Post Quantum Migration and Legacy Signature Sunset», signed by Jameson Lopp with five other authors and in draft since February 2026, takes the second road, and its own authors present it as a proposal «radically different from any other in Bitcoin's history, as radically different as the threat is». The design has two phases. Phase A, about three years after activation: it becomes impossible to send coins to vulnerable addresses, so that the problem at least stops growing. Phase B, another two years later, five in all: the old signatures stop being sufficient on their own. Not a blind wall, in the current version of the text: the idea is to bind legacy spends to «rescue protocols» founded on an asymmetry of knowledge, something the rightful owner knows and that a machine able to derive the private key from the public one would still not know. The most concrete example: most modern wallets derive their keys from a seed (BIP-32), and whoever holds the seed can prove it with a cryptographic proof without exposing anything attackable; the research on how to do this efficiently (zero-knowledge proofs, commit-reveal schemes) is declared open in the text itself. What remains uncovered is precisely the fossil: for the original P2PK no asymmetry is possible, the public key is all there ever was, and there the authors point to a possible complementary proposal for rationed spending. The freeze, in short, has been refined into a gradation: rescuable is whoever can prove something more than the key, rationed or halted is whatever can prove nothing.
It must be said with equal clarity what BIP-361 is not, because here accounts have often overstated. Lopp wrote it without mincing words: «I know folks don't like it; I don't like it either; I wrote it because I like the alternative even less.» And in the same intervention he clarified that this is neither a finished specification nor a proposal for activation: it is the outline of an emergency plan, which requires further research, and which the author hopes will never be needed. One can read this as a weakness. It is more honest to read it for what it is: the community is writing plan B in advance and in public, with years of margin, knowing that an emergency is not something to arrive at unprepared, nor something for which a consensus can be improvised.
The dissent, meanwhile, has organised itself into proposals, not into cheering. The most structured comes from BitMEX Research (April 2026), and it turns the philosophy around: no preventive freeze, but an alarm system. A vulnerable address is built whose private key is demonstrably unknown to anyone (there is a standard way of doing it: the point on the curve is generated from a public constant, so that nobody can hold its logarithm), funds are deposited in it as a bounty, and it is watched: it is the canary in the mine. As long as the canary sings, the vulnerable coins stay spendable; if someone empties that address, quantum computing capability is demonstrated in the most public way possible, and the freeze triggers then, automatically, with a safety window to manage the transition. The arguments: custody of funds is the responsibility of whoever owns them, not of the protocol; a preventive freeze damages the censorship resistance that gives Bitcoin its value; and the threat, as of today, remains a projection. The document admits its own weak points, and the admission is worth as much as the proposal: the bounty might be too small to tempt whoever has the machine, who might prefer real targets while keeping quiet about their capability; and the mechanism is more arbitrary and complex than a simple freeze. These are exactly the objections of the opposing side, and the fact that they are written in the document itself says that the disagreement is on the merits, between people who take each other seriously.
It is worth looking at the axis the debate moves along, because it is not technical. On one side the security of the whole: letting millions of coins be stolen pollutes everyone's trust, including that of those who migrated in time. On the other the principle of property: a protocol that freezes other people's coins for a good cause has established that it can do so, and that precedent stays. Both sides argue from Bitcoin's principles: it is a conflict between two readings of the same constitution, not between those who defend it and those who attack it. The text of this section does not choose, deliberately: the reader now has the elements to weigh it up. What neither side disputes is the point that leads to the next section: a decision will have to be taken, it will concern the coins of people who cannot take part in the decision, and the protocol, on its own, has no mechanism for taking it.
The generals return to the table
The problem Bitcoin was born from carries an academic name: the Byzantine generals problem, getting strangers who do not trust each other to agree, on a channel nobody controls, knowing that somebody may lie. For fifteen years the solution has worked so well as to seem definitive: the rule of the chain with the most work produces, every ten minutes, a planetary agreement on which history of the ledger counts, without anyone deciding and without anyone having to trust anyone. But it is worth looking precisely at what that mechanism produces, because here precision decides everything: it produces consensus on the history of the ledger, inside given rules. It does not produce, and cannot produce, consensus on the rules themselves. Proof-of-work can choose between two competing histories; it cannot choose between two versions of itself.
How do the rules change, then? In the oldest way there is: somebody proposes, the others discuss. The documents handled so far, BIP-360 and BIP-361, are exactly this, Bitcoin Improvement Proposals: written, public, numbered proposals, submitted to an open review whose change log could be read like a diary. Then the software: some implementation translates them into code. And finally activation, which does not resemble a vote: the new rules count to the extent that whoever runs a node chooses to run them. There is no written threshold, there is no quorum, there is no assembly that deliberates; there is an informal coordination among developers, miners and users, each with a piece of power and none with the last word. And whoever dissents always keeps the extreme exit: staying on the old rules, or writing their own, that is forking, taking away a copy of the ledger identical up to the point of separation and different from there on.
This nameless governance has already passed real tests. The hardest so far, between 2015 and 2017: an apparently technical dispute over block size became a years-long clash between two visions of the system, and it ended in the way the design foresaw, not in the way that was feared: the side that wanted bigger blocks forked, the ledger split in two, and the outsiders who treat a ledger as the only version of the facts concentrated overwhelmingly on one side only. But all the tests passed so far, that one included, had a convenient property: doing nothing was a liveable outcome. Taproot, the last important change (2021), was an optional improvement: whoever ignores it loses nothing. And in a governance where changing requires a very wide consensus while not changing requires none, the status quo always starts as the winner; for a system whose virtue is not letting itself be rewritten, this inertia is not a defect, it is the character.
Quantum computing is the first question that takes away inertia's innocence. It is not an optional improvement: it is compulsory maintenance, with an unknown deadline. Not deciding remains possible, but the previous section has shown that it is not neutral: leaving everything as it is coincides with one of the two ways out, the one that hands the coins of the silent to the first to arrive. When not acting coincides with one of the options in play, the status quo stops being a refuge: inertia, which until now guarded the system, becomes a choice with winners and losers, taken without anyone signing it.
And there is the scenario neither side wishes on itself: that convergence does not arrive. A community split over migration would produce two ledgers, one that freezes and one that lets spending happen, each calling itself Bitcoin, with the loot perfectly valid on one and non-existent on the other: the return of the original problem, many truths and none, brought about by the attempt to solve a new one. It is not a prophecy, it is the price written on the sign: and it is precisely the visibility of that price, which no participant has an interest in paying, that is the most serious force pushing towards a common decision.
None of this overturns the frame the text set out with: it refines it. The cost barrier really does guard the ledger's past, its uniqueness, its rules; but it guards them inside the cryptographic assumptions it is built on, and assumptions do not maintain themselves. As long as they hold, the system is what it promises: rules without rulers, agreement without trust. When one of them ages, and sooner or later one does, renewing it is not a computation some machine can perform: it is an act of coordination among people, with everything that follows, the debate, the factions, the weight of who speaks, the trust in whoever writes the code. Trust, thrown out of the protocol's door, tries to come back in through the window of human decisions. This is not a betrayal of the design: it is its perimeter, seen up close. «Rules without rulers» does not mean rules without maintenance; it means that maintenance requires the consensus of almost everyone, and that is at once the system's guarantee and its slowness.
Here the thread of the text closes. Quantum computing does not break consensus: it forces it to be used, at the level where it is hardest, that of the rules, on the most uncomfortable question, what to do with the property of those who are not there, and with empty seats at the table that nobody can fill. A machine that does not yet exist has already achieved something no computer attack ever achieved: forcing the system born to do without human decisions to prepare one, in public, years in advance. Which is, after all, the best way to take it.
In summary
Nine sections and a good many technical names later, it is right to line the answers back up for whoever has followed this far. Five questions, and the answers without a single acronym.
What will a quantum machine actually be able to do? Open some of the locks: derive the secret key from the public key, wherever the public one is visible. It will not be able to rewrite the ledger or forge its history: the agreement on what happened rests on fingerprints and accumulated work, and there the quantum advantage is not enough, at any sensible horizon.
When? Nobody knows, and precise dates are worth little. As of July 2026 the practical demonstrations are toys, very far from real keys, but the resources required fall year on year while the machines grow: the gap closes from both sides. And from the time of the attack the time of the defence must be subtracted, which here is measured in years: this is why it is being discussed now.
Which coins are at risk? Those whose public key is already in the open: the oldest, written in the clear when it seemed harmless, with the coins attributed to Satoshi among them, and all those left on an address that has already spent at least once. With one's own node, about a tenth of the total can be counted as a certain floor; taking reuse into account, the estimates exceed a third.
What can be done? Resistant signatures already exist, standardised: more bulky, but ready; the addresses that will host them are being worked on, and whoever holds the keys will be able to migrate. The hard point is not technical: it is the coins of those who can no longer move them, leaving them to the first to arrive or halting them by decree, and the plans for both roads are being written now, in public, years in advance.
Who decides? Nobody alone, and that is the character of the system: the rules change only if whoever runs a node chooses to adopt them, after public proposals and open debate, and whoever dissents can always leave with a copy of the ledger. The mechanism produces automatic agreement on history, not on the rules: on those, people decide. That decision is already being prepared, and it is the best news in the whole picture.
The same question, on a small scale
After weighing other people's locks, honesty asks for a look at one's own. At the foot of every text on this site there is a verification, made of three promises: a fingerprint of the content (this is it, it has not been touched), a time anchor to Bitcoin's ledger (it existed before this block), an author's signature (it comes from here). The map drawn in this piece applies exactly as it is, in miniature.
The first two promises hold. The fingerprint is a hash, and against hashes the quantum advantage halves the exponent without bringing down the wall: whoever recomputes a page's fingerprint will be able to speak to its integrity even on the day the machine exists. The anchor is made of fingerprints inside other fingerprints, up to those the ledger guards under its cost barrier: the clock keeps holding.
The third ages. The author's signature on these pages uses the same mathematical family as Bitcoin's signatures, the elliptic curves Shor breaks; and the public key needed to verify it is published by definition, it has to be, or nobody could check anything. It is exactly the condition of the coins of the origins: exposed by construction, not by mistake. The day the algorithm ran on a real machine, that signature would stop proving authorship: anyone could sign in this site's name.
And the solution is the same one seen for the coins, in miniature: pre-commit today to tomorrow's key, publishing only its fingerprint. A commitment made of hashes alone offers nothing to the algorithm that breaks signatures; when it is needed, the new key will be revealed and anyone will be able to check that it had been promised beforehand, in an unbroken chain. Writing this piece was the occasion to stop postponing it: the reserve key exists, it is kept offline, and it is a post-quantum signature built on hashes alone (the family discussed among the solutions). On the verification page its fingerprint can be found today, together with the declared scheme: the day the current signature stopped proving anything, there will be a key to reveal, not trust to ask for.
The point of this coda is not the anecdote. It is that the method of the piece, separating what rests on fingerprints from what rests on exposed keys and giving every assumption its expiry date, is not cheerleading for Bitcoin: it applies to any system of cryptographic proofs, including a homemade one like this. Assumptions do not maintain themselves, and knowing it in time is the only advantage available. This page too, like the ledger it talks about, declares its own date.
To redo the calculations in this piece: UTXO set snapshot at block 957,301
(txoutset_hash ec79aed9…cc58); fingerprint of the burnt locks
5fd579db…0ee7; canonical fingerprint of the revelations archive:
aacaf02d…9ced. The full fingerprints, the replication contract and the
pipeline are in the appendix of the data
piece; the complete code in
a dedicated follow-up, later on.
References
- P. W. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer, SIAM Journal on Computing 26(5), 1997 (conference version 1994): arxiv.org/abs/quant-ph/9508027
- L. K. Grover, A fast quantum mechanical algorithm for database search, STOC 1996: arxiv.org/abs/quant-ph/9605043
- D. Aggarwal, G. Brennen, T. Lee, M. Santha, M. Tomamichel, Quantum attacks on Bitcoin, and how to protect against them, Ledger 3, 2018 (the classic academic reference on signatures versus proof-of-work): arxiv.org/abs/1710.10377
- C. Gidney, M. Ekerå, How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits, Quantum 5, 2021: arxiv.org/abs/1905.09749
- C. Gidney, How to factor 2048 bit RSA integers with less than a million noisy qubits, May 2025 (the estimate that falls twenty-fold in six years): arxiv.org/abs/2505.15917
- R. Babbush, A. Zalcman, C. Gidney, M. Broughton, T. Khattar, H. Neven, T. Bergamaschi, J. Drake, D. Boneh, Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations, March 2026 (Google Quantum AI: fewer than 1,200 logical qubits and fewer than 500,000 physical ones, with the assumptions declared in the text): arxiv.org/abs/2603.28846 — disclosed responsibly on the Google Research blog, research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly
- M. Cain, Q. Xu, R. King, L. R. B. Picard, H. Levine, M. Endres, J. Preskill, H.-Y. Huang, D. Bluvstein, Shor's algorithm is possible with as few as 10,000 reconfigurable atomic qubits, March 2026 (neutral atoms and qLDPC codes; for a 256 bit key, about 26,000 physical qubits): arxiv.org/abs/2603.28627
- H. Luo, Z. Yang, Z. Wang, Y. Su, T. Li, Space-Efficient Quantum Algorithm for Elliptic Curve Discrete Logarithms with Resource Estimation, April 2026 (1,333 logical qubits for ECDLP-256, against the 2,124 of the previous reference estimates): arxiv.org/abs/2604.02311
- S. Tippeconnic, announcement of the first break of a 6 bit elliptic curve key on public quantum hardware (ibm_torino, September 2025): x.com/stevetipp/status/1962935033414746420
- Project Eleven, Q-Day Prize: 15 bit key broken with Shor's algorithm, awarded one bitcoin, April 2026: projecteleven.com/blog/project-eleven-awards-1-btc-q-day-prize…
- Deloitte, Quantum computers and the Bitcoin blockchain, analysis 2019-2020 (about 4 million vulnerable BTC, a quarter of the supply at the time): deloitte.com/nl/en/services/consulting-risk/perspectives/quantum-computers-and-the-bitcoin-blockchain.html
- Glassnode, Measuring Bitcoin's Quantum-Exposed Supply, 20 May 2026 (proprietary data; the structural floor at 1.92 million BTC): research.glassnode.com/measuring-bitcoins-quantum-exposed-supply
- Coinbase Quantum Advisory Council, position paper of 21 April 2026 with an update of June 2026 (about 7 million BTC exposed): coinbase.com/blog/coinbase-quantum-advisory-council-publishes-position-paper…
- NIST, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), August 2024 (the sizes in the signature table come from the tables of these two documents): csrc.nist.gov/pubs/fips/204/final and csrc.nist.gov/pubs/fips/205/final
- BIP-360, Pay-to-Merkle-Root (P2MR) (E. Beast, E. Heilman, J. Foxen Duke), status Draft, version 0.12.0 of 18 June 2026; the revision log cited in the text is the BIP's own: github.com/bitcoin/bips/blob/master/bip-0360.mediawiki and bip360.org
- BIP-361, Post Quantum Migration and Legacy Signature Sunset (J. Lopp, C. Papathanasiou, D. Smith, Z. Ross, K. Vaile, P.-L. Dallaire-Demers), status Draft, February 2026 (the two phases, the rescue protocol, the «more than 34%» figure as of 1 March 2026): github.com/bitcoin/bips/blob/master/bip-0361.mediawiki
- J. Lopp, public clarifications on BIP-361, April 2026 (the «I know folks don't like it…» quotation and the clarification that this is neither a finished specification nor a proposal for activation): x.com/lopp/status/2044406134178795748
- BitMEX Research, Avoiding An Unnecessary Quantum Freeze, 14 April 2026 (the canary built on a NUMS point, the reactive freeze and the weak points admitted by the authors): bitmex.com/blog/Avoiding-An-Unnecessary-Quantum-Freeze
- Bitcoin Optech, topic Quantum resistance, for the survey of the technical discussions referred to (commit-reveal, one-time signatures on hashes alone): bitcoinops.org/en/topics/quantum-resistance
- The numbers of the census, the method and the fingerprints to check them are in the companion piece, «Bitcoin and quantum computing: the data (July 2026)».