The Quantum Apocalypse Is Coming Any Decade Now, So Here Is the Solution to a Problem That Will Not Exist
On native-Script WOTS+, ECDSA r-puzzles with hash-committed nonces, and the consulting-hours industry that has been built on a threat that will arrive shortly after fusion power and right before ...
On native-Script WOTS+, ECDSA r-puzzles with hash-committed nonces, and the consulting-hours industry that has been built on a threat that will arrive shortly after fusion power and right before the meaningful AGI deadline.
I. A short note on what I actually believe
Let me get this out of the way first, because otherwise the rest of this essay reads as if I am drafting it through clenched teeth, which I am.
I do not believe in quantum computing. Not in the sense that I deny the existence of the apparatus humming away in some refrigerated basement at IBM Yorktown Heights, which I am told is real and which I am perfectly willing to grant exists, in the same way that I grant the existence of nuclear-pumped lasers, large hadron colliders, and Olympic-grade synchronised swimming. They are real. People are doing them. Money is being spent. Press releases are being issued. Sort or…
I believe in BS QC as much as I do in refusing funds from Epstein. Both are holes you do not want to get into.
What I do not believe here and now is that any of this will ever produce a machine which factors a 2048-bit RSA modulus on demand, breaks a secp256k1 ECDLP on demand, or in any other way performs the cryptographically interesting feats that the post-quantum-industrial complex has been promising for thirty years and continues to promise in five-year increments which slide gently rightward at exactly the rate required to keep the grant cycle going. I do not believe a fault-tolerant quantum computer of cryptographically interesting size will exist in your lifetime. I do not believe one will exist in your children’s lifetime. I think it is possible, though I would not bet a coffee on it, that one might exist in a hundred years, by which point the question will be of the same historical interest as whether the Antikythera mechanism could play whist.
The consensus disagrees with me. The consensus has been disagreeing with me since approximately 1994 when Peter Shor wrote down his algorithm and a generation of physicists reasoned that since the algorithm was beautiful, the machine to run it must merely be a matter of engineering. Engineering, it turns out, has its own opinions. After three decades of throwing money at the problem we have machines that have, on a good day, with a following wind, factored 21 into 3 times 7. The 21 was carefully chosen. The 3 and the 7 were known in advance. There was champagne. There were graphs. There was a period, around 2019, when Google announced quantum supremacy on a problem that turned out to be a problem they had constructed for the purpose of announcing quantum supremacy on it. The classical solution was published shortly thereafter and ran on a laptop.
None of this is to disparage the physicists. The physics is genuinely beautiful. The mathematics is genuinely deep. The engineering, alas, is the engineering of trying to keep a thousand simultaneously-decohering objects in coherent superposition for long enough to do something useful, which is approximately the engineering of trying to keep a thousand simultaneously-melting ice sculptures in the shape of the Sydney Opera House for long enough to sell tickets. It is admirable. It is also, in my view, not going to scale.
So why am I writing a paper specifying a quantum-resistant signature scheme on Bitcoin SV?
Because the consensus believes otherwise, and the consensus controls the standards committees, and the standards committees control what banks and governments and infrastructure operators are required to deploy, and the infrastructure operators control what runs on the chain. NIST has standardised post-quantum signatures. ETSI has issued guidance. The European Banking Authority is making noises about quantum-readiness audits. Whether or not the threat is real, the compliance regime around it is real, and the compliance regime is what gets you sued if you ignore it.
So here we are. I have written the solution to a problem I do not believe exists, because the people who do believe it exists have rule-making authority, and because, against my own better judgement, I would rather have a working solution sitting on the shelf for the day they are wrong than spend the rest of my career being told I should have prepared. There is also a non-zero chance, perhaps three percent on my own count, that they are right and I am wrong, and three percent of catastrophic loss is enough to motivate cheap precautions. Cheap is the operative word here. The construction below adds, at the high end, two-tenths of one cent per transaction. If the apocalypse arrives, it has been worth it. If it does not, no one was meaningfully out of pocket.
That is the spirit in which the rest of this is written. Not believer’s enthusiasm. Insurance.
II. The problem, briefly, for the people who have not been paying attention
Bitcoin, in all its forms, signs spending transactions with ECDSA on the secp256k1 elliptic curve. The private key is a number. The public key is that number multiplied by a fixed point on the curve. The signature involves hashing the transaction, doing some modular arithmetic, and producing a pair of numbers that prove you knew the private key without revealing it. The whole edifice rests on the elliptic-curve discrete logarithm problem being hard, which means that given the public key, you cannot in any reasonable time work out what the private key was.
This is true classically. It is, the consensus claims, not true quantumly. Shor’s algorithm factors integers in polynomial time on a quantum computer, and a variant solves the discrete logarithm in polynomial time too. Given a public key, the private key falls out. Given the private key, every wallet associated with that key is empty before the next block confirms.
If this happens, every Bitcoin address whose public key has ever been published is at risk. On Bitcoin Core, where address reuse is rampant and where many old wallets are pay-to-public-key rather than pay-to-public-key-hash, the public keys are sitting on chain in plain view, waiting for the day. On Bitcoin SV, where the protocol mandates one address, one key, one use, the situation is genuinely better, because the public key is exposed only in the small window between broadcast and confirmation. But “better” is not “fine,” and a quantum-capable adversary who can act inside that window can still race-replace the legitimate spend with their own.
So a defence is required. Or at least, a paper specifying a defence is required, because that is the regulatory game we are now playing.
III. What everyone else is proposing, and why most of it is silly
The post-quantum-cryptography community has produced a small zoo of proposed signature replacements. Lattice-based, like Dilithium. Code-based, like Classic McEliece. Hash-based, like SPHINCS+. Multivariate, like Rainbow, which was broken last year, which is the kind of detail that the post-quantum-cryptography community finds slightly embarrassing and the rest of us find quite amusing. NIST standardised three of them, of which one was promptly broken, and now there are two and a bit.
Of these, hash-based signatures have the longest pedigree and the cleanest theory. They were invented by Lamport in 1979 — that is, before most of the audience for this essay was born — and they reduce to a single, simple, brutally honest assumption: hash functions are hard to invert. That is it. No exotic structures. No code-based assumptions. No lattices that nobody outside a small coterie of cryptographers actually understands. Just SHA-256 — a function which the entire planet has been beating on for twenty-five years and which has not budged.
The rest of this essay is about how to use one of these hash-based schemes, specifically the Winternitz one-time signature scheme, as a native Bitcoin SV spending authorisation. No soft fork. No new opcodes. No off-chain trust. Just the existing Genesis-restored opcode set, doing what it was designed to do, signing things in a way that does not collapse when an imaginary quantum computer arrives.
I will also describe a hybrid construction, because if you are going to put down two-tenths of a cent per transaction in insurance, you might as well also put down the additional thousandth of a cent for the belt-and-braces version that defends both classically and quantumly. This is what serious people do.
IV. Construction A: the cheap insurance
Before getting to the proper post-quantum scheme, let us deal with the cheap version, which is what most actual deployments will use. I call it Construction A. It is an ECDSA signature with a hash-committed nonce, and it is the kind of construction that exists primarily to handle the case where someone who believes in quantum computers is your auditor and you need to put a check mark in a box.
The idea is straightforward. When you fund a UTXO, you commit at funding time not just to a public key but to a hash h, where h is the SHA-256 of the r-component of a future signature concatenated with a secret pre-image you have set aside. The locking script enforces, at spending time, that the signature you produce has the committed r-component, and that you reveal the pre-image whose hash matches. The signature is also, by virtue of how Bitcoin’s SIGHASH machinery works, bound to the specific transaction outputs you are signing — so a miner who sees your spend in the mempool cannot redirect funds without invalidating your signature.
What does this buy you? Classically, nothing new. ECDSA already authorises the spend; the hash check is dead weight. Quantumly, however, it changes the picture. A quantum-capable attacker who has Shor’s algorithm and who sees your public key on chain during the broadcast-to-confirmation window can recover your private key and forge a signature. But to spend the UTXO, the forged signature must also have an r-component matching your committed hash. Choosing a different r-value means the hash check fails. Choosing the same r-value as your legitimate signature accomplishes nothing — it does not redirect the funds. To redirect, the attacker must find a different (r, k_s) pair that hashes to the same h, which is a SHA-256 second-pre-image, which is computationally infeasible even to a Grover-equipped quantum machine, because Grover gives you only a quadratic speedup and SHA-256’s 256-bit output is enough headroom that 128 bits of quantum work is still wildly out of reach.
So Construction A does not eliminate the quantum threat. It bounds it to the broadcast-to-confirmation window. After confirmation, the UTXO is consumed and the key is retired forever — that is the BSV protocol rule, not an assumption — and the attacker has nothing to chew on. Eighty-nine bytes per transaction, one-thirteenth of a cent. Cheap. Worth doing on principle even if quantum computers turn out to be the perpetual-motion machine of the early twenty-first century.
I would deploy Construction A on every transaction by default and not lose any sleep about it.
V. Construction B: the actual post-quantum thing
If you want full post-quantum spending — meaning the spending authorisation does not depend on ECDSA at all and does not collapse when a Shor machine fires up — you need a hash-based one-time signature inline in the locking script. This is Construction B, and it is where things get interesting, because it has not been done in native Bitcoin Script before, and the reason it has not been done is that on Bitcoin Core, the OP_CAT opcode was disabled in 2010 by a paranoid developer who was worried about denial-of-service attacks and who, in disabling it, accidentally hobbled the language for fifteen years.
Bitcoin SV, mercifully, restored OP_CAT in the Genesis upgrade of February 2020, along with OP_SPLIT, OP_AND, OP_DIV, OP_NUM2BIN, and the rest of the original Satoshi opcode set. With these opcodes available, you can do real string manipulation in the locking script. With real string manipulation, you can verify a hash-based signature. With a hash-based signature verifier in the locking script, you can sign spends without ECDSA. The path is open.
The signature scheme is Winternitz, parameterised at w=16. For each 256-bit message you want to sign, you generate 68 secret seeds — 64 for the message digits, 4 for a checksum that prevents trivial forgeries by ensuring no message dominates another in the digit ordering. Each secret seed is hashed 15 times to produce a public-key element. The 68 public-key elements are concatenated and hashed once more to produce the 32-byte WOTS+ public-key digest, which is what goes into the locking script.
To sign a 256-bit message, you parse it into 64 base-16 digits. For each digit bi, you publish the value of the i-th hash chain at position bi — that is, you reveal Hbi(ski). Then you compute the Winternitz checksum, parse it as 4 more digits, and reveal those positions in the checksum chains too. Sixty-eight 32-byte values per signature: 2,176 bytes of signature data, plus the checksum, plus the destination commitment, plus a few hundred bytes of housekeeping. The unlocking script lands at about 2,400 bytes.
To verify the signature, the locking script must — for each of the 68 chains — take the revealed signature element, hash it forward by exactly (15 - bi) more times, and check that the resulting 68 values, concatenated and hashed, match the stored public-key digest. Hashing forward by a variable count is the part that requires the verifier to do real computation in Script, and this is the engineering work. Native Bitcoin Script does not have a stack-controlled loop. It has OP_IF, but the IF cannot itself be parameterised by stack data in the way that would let you write a clean for-loop. So the loop has to be unrolled.
You unroll it as a 15-deep cascade of conditional hash applications, each looking like this:
OP_DUP OP_0 OP_GREATERTHAN
OP_IF
OP_SWAP OP_SHA256 OP_SWAP OP_1SUB
OP_ENDIF
which is to say: duplicate the count on top of the stack, test whether it is greater than zero, and if it is, swap the chain value to the top, hash it once with SHA-256, swap it back, and decrement the counter. After 15 levels, the counter is at zero and any further passes are no-ops. After 15 levels and a final OP_DROP to remove the spent counter, you have the candidate public-key element on the stack. You stash it on the alt stack, repeat for the next chain, and after 68 chains you concatenate the alt-stack contents back together, hash with SHA-256, and check against the stored digest.
Each cascade level is nine bytes. Fifteen levels per chain plus one OP_DROP plus one OP_TOALTSTACK is 137 bytes per chain. Sixty-eight chains is 9,316 bytes. Add 481 bytes of digit extraction, 350 bytes of checksum computation, 135 bytes of concatenation, 35 bytes of destination check, and a smattering of pushes, and you get a locking script of exactly 10,423 bytes.
I wrote a compiler in Python to verify this. It is shipped with the supplementary material to the paper. You can run it. It produces 10,423 bytes. Not “approximately 10,000,” not “in the order of 10 KB,” not “approximately 12,500.” Ten thousand four hundred and twenty-three bytes, exactly, every time, deterministically, and you can put the binary output through a Bitcoin SV consensus validator and watch it accept the script.
This is the part that I want to dwell on, because it matters. Most papers in this area give you envelope estimates: “the verifier will be approximately 10 KB,” “the proof system requires approximately 100,000 constraints,” “the signature is on the order of a few kilobytes.” Those numbers are useful for hand-waving and useless for compliance. A real paper, which is what I am trying to write, gives you the exact byte count of the exact bytecode that the exact compiler emits for the exact construction. The paper has it. The compiler has it. The bytecode has it. You can audit each one against the others. If you find a discrepancy, you have found a bug, and bugs at this layer are findable, fixable, and bounded.
VI. The simplification we made, and why we made it, and why it is probably fine
RFC 8391, the IETF specification of WOTS+ as a building block of XMSS, calls for a chaining function that is more complicated than just plain SHA-256. The RFC version takes a public seed K, an address tweak that encodes the chain index and the iteration position, and a per-position bitmask, and computes the hash of the concatenation of all these things with the chain value XOR’d against the bitmask. The reason for this is a security reduction: with the tweakable chaining function, WOTS+ security reduces to second-pre-image resistance of the chaining function, which is a 128-bit-quantum-secure property under Grover. With the plain SHA-256 chaining function, WOTS+ security reduces to collision resistance, which under the Brassard-Høyer-Tapp bound is only 85-bit-quantum-secure.
This is the part where a sufficiently aggressive reviewer will object that 85 bits is not 128 bits and therefore the construction does not meet the NIST PQ Category 1 floor. This reviewer is, technically, right.
So we did the calculation. The RFC 8391 chaining function, expanded into native BSV Script, requires per-iteration computation of the address tweak, of the bitmask via a separate PRF, and of the XOR — adding approximately 175 bytes per cascade level instead of 9. Multiplying through, the RFC-compliant Construction B locking script comes to about 180,000 bytes. At BSV reference fees that is about two and a half cents per spend. Not catastrophic. But fourteen times the cost of the simplified version, for the sake of a security improvement that exists only against an adversary capable of mounting 285 quantum collision queries — which is, to put it gently, not a threat that I expect to wake up to in the next forty years.
So the paper specifies both. The simplified version is the default, on the grounds that 285 quantum collision queries is enough headroom for any threat anyone can plausibly articulate before 2050, and the RFC-compliant version is in the appendix for the deployments that are required to tick the NIST PQ Cat. 1 box because some compliance officer somewhere insists on it.
This is, for what it is worth, the kind of careful trade-off that does not appear in essentially any other quantum-resistant blockchain proposal I have read. Most of them claim NIST Cat. 1 by hand-waving. We compute the cost of meeting it, compute the cost of nearly meeting it, and let the reader pick.
VII. Construction C: belt and braces
Construction C is the hybrid envelope: the locking script enforces both Construction A and Construction B simultaneously. Spending requires both a valid ECDSA signature with hash-committed nonce, and a valid WOTS+ signature on the destination commitment.
This is the construction I would actually use for high-value UTXOs during the transition period. Why? Because if it turns out I am right and quantum computers are a thirty-year-away problem that will, on inspection, be revealed to be a fifty-year-away problem and then a hundred-year-away problem, the ECDSA layer carries the load and the WOTS+ layer is wasted bandwidth costing two-thousandths of a cent per spend. If it turns out I am wrong and a Shor-capable machine appears, the WOTS+ layer carries the load and the ECDSA layer is the irrelevant one. Either way the construction holds. The cost is the sum of both, which is to say a hair over the cost of the WOTS+ alone, because Construction A is so cheap as to be statistically indistinguishable from zero.
An ACM reviewer will tell you that defence-in-depth is a good idea. A real engineer will tell you that paying twice for safety is the cheapest insurance you will ever buy. Two-tenths of a cent per spend, and the construction is robust against both classical and quantum attackers at the same time. There is no good argument against this except the argument that it is fashionable to have an opinion about which threat model is more important and to commit to it loudly.
VIII. The single-use rule, which is not an assumption
One thing I want to push back hard against is the language one sees in essentially every other paper in this space, which describes the requirement that addresses be used at most once as an “assumption” in the security analysis. It is not an assumption. It is a protocol-level rule of how Bitcoin SV is operated. Every wallet that the BSV ecosystem ships enforces it. Every backend infrastructure built on the chain assumes it. The few people who reuse addresses are, by community standards, doing something wrong, and when their funds are stolen because of it the community shrugs.
This matters because the entire point of a one-time signature is that it is one-time. Sign twice with the same WOTS+ key, and the second signature reveals enough information to forge a third signature on a related message. This is not a flaw. It is the design. The Lamport scheme of 1979 was one-time on purpose. The Winternitz scheme of 1979 was one-time on purpose. SPHINCS+ uses a hyper-tree to compose many one-time keys into a many-time scheme; for a system like BSV which mandates single-use anyway, the hyper-tree is overhead and plain WOTS+ is strictly more efficient.
So when you read a paper saying “this construction assumes one-time use,” what you should read is “this construction works in the BSV protocol-level discipline that everyone in this ecosystem already follows,” which is a different and much weaker condition. Outside that discipline, the construction does not apply. Inside it, the discipline does the work.
IX. The threshold case, which we did not solve
One thing the paper is honest about is that we did not solve the threshold version of Construction B. Threshold-ECDSA is a solved problem; the Lindell protocol and the Gennaro-Goldfeder protocol have formal universal-composability proofs and have been deployed in production for a decade. Threshold-Construction-A, which is just threshold-ECDSA with a hash-committed nonce, is a clean composition. Done.
Threshold-Construction-B, which would require multiple parties to jointly compute a WOTS+ signature without any single party learning the combined seed, is genuinely an open problem. The hash-chain structure of WOTS+ does not compose linearly under Shamir secret sharing, and the standard MPC-friendly hash protocols have not been formally analysed in this composition.
The paper says so. It does not paper over the gap with a “future work” wave, it states the problem precisely, and it stops. There is too much of the opposite practice in the literature, where a half-thought is decorated as a theorem and the reader is expected to be impressed. The honest version is to say what is known, what is not known, and where the boundary is.
This is, by the way, the right time to mention that I do not actually want to solve the threshold-Construction-B problem until and unless someone is willing to fund the threshold-hash-chain protocol research, which is a real piece of cryptographic engineering that takes a real cryptographer six months to a year to produce a publishable proof for. The construction is not blocked on insight; it is blocked on labour, and labour costs money, and the quantum threat is not real enough for me to do it on spec.
X. What would actually have to be true for the apocalypse to arrive
Let me close with the prediction that motivates this whole essay, because if you have read this far you might want my actual numbers.
For Shor’s algorithm to break secp256k1 in any operationally interesting timeframe, we need a quantum computer with several thousand logical qubits, fault-tolerant, with circuit depth on the order of 109 gates, running coherently. The current state of the art is around 1,000 physical qubits, which by the most generous error-correction overhead estimate gives you about ten logical qubits. To get to several thousand logical qubits we need either (a) a 100,000× improvement in physical-qubit count, (b) a 1,000× improvement in physical-qubit error rate, or (c) some combination. The historical rate of improvement is approximately 2× per three years. Linear extrapolation to 100,000× takes about fifty years. Logarithmic extrapolation, which assumes the field stops being able to recruit physicists eventually, takes longer.
And Shor on secp256k1 specifically requires solving an elliptic-curve discrete logarithm, which is somewhat harder than integer factorisation, and the existing demonstrations are for very small curves. Scaling up has not been linear. There are believed-to-be-solvable engineering challenges to scaling, but “believed-to-be-solvable” is the part where I depart from the consensus, because in my experience the engineering challenges to scaling exotic physics experiments are very rarely solvable in the timescales the believers project.
So my honest probability estimates are: a Shor machine capable of breaking secp256k1 in the next ten years, less than one percent. In the next twenty years, perhaps three percent. In the next fifty, perhaps fifteen percent, and I would haggle this number down if pushed. In the next century, maybe forty percent, but at that point so many other things will have changed about computing that the question becomes essentially a science-fictional one.
If you ask me to defend an infrastructure deployment against the three-percent-in-twenty-years risk, I deploy Construction A by default everywhere, deploy Construction C on high-value treasury holdings, and call it done. Total cost is less than a tenth of a cent per transaction. Total benefit, if I am wrong about quantum computing, is the protection of the entire chain. Total cost, if I am right, is two-tenths of a cent per high-value spend, which is not even a rounding error in the operational cost of a treasury operation.
This is the calculation that the post-quantum-cryptography industry does not want you to do, because if you do it the answer is “deploy a small inexpensive thing, sleep well, do not give me a six-figure consulting contract for the panicked re-architecture of your entire stack.” The answer they want you to reach is “rip everything out, replace ECDSA with Dilithium-or-SPHINCS+-or-the-current-favourite, accept the ten-times signature size, accept the fork, accept the new attack surface from the fresh and lightly-vetted standardised primitives, and pay them by the hour to make this happen.” That is the answer I am writing this essay against.
XI. The construction in one paragraph
For the reader who has scrolled to the end, the whole thing summarised: on Bitcoin SV, native Script can verify a 68-chain Winternitz one-time signature in 10,423 bytes of locking script, costing about two-tenths of one cent per spend. The signature is bound to a destination commitment fixed at funding time so an adversarial miner cannot redirect funds. The construction is one-time by virtue of the WOTS+ design, and one-time is enforced by the BSV protocol rule that addresses are not reused. A simpler companion construction adds a hash commitment to ECDSA’s nonce, which provides race-window resistance against quantum public-key recovery for an extra eighty-nine bytes. The hybrid of both is what I would actually deploy. The whole thing requires no soft fork, no new opcodes, no off-chain trust, and no consensus changes, because Bitcoin SV restored the original Satoshi opcode set in February 2020 and has been waiting patiently for someone to actually use it for this purpose. I have, at last, used it for this purpose.
The paper is on arXiv. The compiler is on the supplementary site. The bytecode is in a binary file you can run through your favourite Bitcoin SV transaction validator and confirm it is exactly 10,423 bytes long.
If quantum computing turns out to be real in your lifetime, the construction will protect your funds. If it does not, you will have spent a tiny amount of money for nothing, which is what insurance is. Either way, the engineering exists, the proofs are written down, and the matter is now closed pending the arrival of either a quantum computer or a more interesting threat model.
I do not expect either, but the next time someone tries to sell you a panicked migration to one of the exotic post-quantum signature schemes, you can point them at this essay and walk away.
If you wish to argue with the substance of the construction, the paper is at the link in this post. If you wish to argue with my disbelief in quantum computing, you can join the queue, which is long, and which has been forming since 1994.