A quantum-safe Bitcoin transaction cost about $320 to build in August. This week it costs about $67. No chip shipped, no laboratory announced anything, and the mathematics underneath did not move by a single bit. Forty people wrote faster code for seven days.
That is the headline, and it is the less interesting half of what StarkWare published. Near the end of the same post is a sentence almost nobody quoted: “StarkWare is working both sides of the same number, driving down what the attack costs to run and what the defense costs to build. The gap between them is how much time there is to prepare.”
Two competitions. Two numbers. One subtraction. And the subtraction is the only thing here that tells you whether you are safe, which is precisely why nobody performs it.
TL;DR
- An open competition run by StarkWare, Yukon Research and Eigen Labs cut the estimated cost of building a quantum-safe Bitcoin transaction from about $320 to about $67 in one week, a 79.06% reduction achieved entirely in software.
- The security level did not change. The search is still roughly one in 70 trillion, about 46 bits of work. What changed is candidates per second on an unchanged RTX 4090: 146.09 million to over 820 million, a factor of 5.61.
- A bit count is a property of the design. A dollar figure is a quotient, and its denominator belongs to whoever felt like optimising this week.
- StarkWare ran a second competition, ECDSA.fail, on the attack side, cutting Google’s March estimate by more than half. Security is the difference between those two numbers, and only one of them is published.
- Satoshie’s draw contains no cost parameter at all: a VRF word has exactly one valid value given key and seed, so no speedup anywhere creates a second one. Our wallets are still elliptic curve, and our contracts have no upgrade procedure. Both are stated below.
Two competitions, one subtraction
The Quantum-Safe Bitcoin Optimization Challenge is the defence side. It exists because the QSB construction, the one that landed an experimental quantum-resistant spend on Bitcoin mainnet last month without a fork, is expensive in a specific and unusual way. It puts a hash where Bitcoin expects a signature: a public key derived from the transaction goes through RIPEMD-160, and the resulting 20 bytes are handed to the script in the slot a signature would normally occupy. Bitcoin checks signature formatting first, so those 20 bytes have to be shaped like a valid DER signature or the script fails. About one in 70 trillion hash outputs has that shape, and nothing lets you steer a hash toward a particular output, so you change an input, hash, check, and repeat until one fits.
That search runs on your own hardware before anything touches the network, which is why it never appears as a Bitcoin fee. It appears as a GPU bill. Double the candidates per second and the same work costs half as much.
ECDSA.fail is the attack side, run on the same model. It spent two months driving down the estimated cost of the arithmetic behind a quantum attack on elliptic-curve cryptography and cut Google’s March figure by more than half. Seven people from StarkWare and the Starknet Foundation are named co-authors on the resulting September paper.
Both stories were covered. They were covered separately, as two pieces of encouraging progress, which is roughly like reporting a company’s revenue and its costs in different newspapers and calling each one a profit.
The bits did not move
Here is the distinction the coverage flattened, and it is the whole post.
A hardness assumption is a claim about operations. The QSB search is about 46 bits of work. The paper puts second-preimage security at roughly 118 bits, falling to about 59 under a rough Grover reduction. Those numbers are properties of the construction. They did not change this week, they will not change next week, and no amount of clever CUDA will touch them.
Nobody deploys an assumption. What a user actually faces is operations divided by operations-per-second-per-dollar, and the denominator is not a property of anything. It is a fact about other people’s week.
The arithmetic is worth doing yourself, because it is more lopsided than the headline suggests. On the pinning track, throughput went from 146.09 million verified candidates per second to just over 820 million on the benchmark RTX 4090, a factor of 5.61. Subset selection went from about 62 million to 623,518,629, a factor of 10.06. Yet the end-to-end cost only improved by a factor of 4.78, from $320 to $67. The composite is smaller than either track it is built from, which tells you the $67 is a weighted model with parts that do not move together, not a measurement of anything.
Take the 46-bit search alone. At 146.09 million candidates per second that is about 133.1 hours on one card. At 820 million it is about 23.7 hours. The same search, the same silicon, 109.4 hours of difference, and nobody bought anything. The August transaction actually consumed roughly 3,100 GPU-hours, some twenty-three times a single search, and that multiple is the part of the construction no coverage describes at all.
Sixty-two improvements were promoted across both tracks in a week. That is one accepted record every 2.71 hours, continuously, for seven days.
StarkWare are notably straight about all of this. They say plainly that the $67 is an estimate under stated hardware assumptions rather than a price, that it moves every time a solver beats the record, and that the benchmark “builds no Bitcoin transactions of its own”, so a speedup there still has to be measured against the production implementation. That is a better disclosure than most security claims in this industry receive. It is also an admission that the number is a model output, and models decay quietly.
Why the subtraction is never performed
Three reasons, none of them stupidity.
The two terms live in different literatures. The defence cost is engineering: kernels, register pressure, memory traffic, occupancy. The attack cost is cryptanalysis and quantum resource estimation. Very few people read both, and most who do are running these competitions.
Only one of the terms has a dashboard. qsb.fast publishes a live figure. There is no equivalent public counter for what a real adversary can do, because a real adversary does not maintain one for you.
And the asymmetry that should actually bother you: the defence side optimises in public by design, and the attack side does not. Every verified improvement on qsb.fast resets the floor and is published, specifically so the next entrant starts from the best known solution rather than from scratch. That is excellent competition design. It also means the defence number is the most accurate number in the system, while the attack number is a lower bound on publicly known capability. Every margin you can compute is therefore the optimistic reading by construction, and the error runs in exactly one direction.
None of which is a reason to distrust StarkWare’s figures. It is a reason to notice that “how long have we got” is treated everywhere as a question about physics, about when a large enough quantum computer exists, when this week showed it is substantially a question about who is optimising what, on both sides, with no obligation to tell anyone.
What this looks like in a casino
Almost every fairness claim in crypto gaming is stated in one of two kinds of units, and the industry treats them as interchangeable. They are not.
Claims stated in counts: there is exactly one valid VRF output for this key and seed; there are 10,000 tickets; the proof verifies or it does not. These survive a good week for somebody else’s GPU kernel, and they survive a hostile stranger checking them in 2035.
Claims stated in costs: nobody could brute-force our server seed; it would cost more to grind this than the pot is worth; our commitment is computationally infeasible to invert. Every one of these has a denominator that forty strangers just moved by a factor of five in seven days, for prize money, in public, and not one system relying on such a claim was notified, because the number does not live in any system. It lives in a decision somebody made when the number was different.
A hash commitment over a short server seed was never secure and was never insecure either. It was priced. The price fell. Nothing was patched, nothing was exploited, no disclosure was owed, and the property quietly changed hands anyway.
This is a different seam from three we have already opened, and the differences matter. It is not the fortieth instalment’s point that defences are priced in either mathematics or attention, because this is a mathematics-priced defence whose dollar cost fell 79% while its hardness assumption held perfectly. It is not the HAWK story, where the assumption itself weakened under AI cryptanalysis in sixty hours; here nothing weakened. And it is not last week’s argument about who supplies the last ingredient of a random number, which was about candidate counts rather than candidate prices. The new claim is narrower and more awkward: a security level and a security cost are different measurements, they move independently, and the industry quotes whichever one is currently flattering.
Where we sit, narrowly
Satoshie’s resolution path contains no cost parameter at all.
A Chainlink VRF word has exactly one valid value given the coordinator’s committed key and the request seed. The coordinator verifies the proof on-chain before the callback may run, and every alternative value fails verification. There is no search anywhere between staking and payout, so there is no quantity that a 5.61x speedup makes cheaper. A faster kernel does not manufacture a second valid word, because the constraint was never that grinding was expensive. It was that there is nothing to grind.
What you can check without asking us: the contracts are on Base, the resolution logic is verified and immutable on BaseScan, the VRF coordinator address is fixed in deployed code and readable before you stake, ticketsMinted is contract state you can read before buying, and the VRF request and fulfilment transaction ids are published with every result. All of it is answerable by a stranger who never played and has no account.
Three things we will not oversell
Our signatures are exactly what Shor breaks. The draw has no cost parameter; the wallet certainly does. The key authorising your entry and receiving your payout is secp256k1, and StarkWare’s framing applies to us in full: every chain that authenticates with elliptic-curve signatures carries the same exposure. Saying our draw is search-free is a statement about the draw and about nothing else in the path.
We have no crypto agility, and immutability is the reason. StarkWare’s word for what decides whether a network survives is crypto agility: how fast a broken primitive can be replaced under pressure. Starknet has a real answer, since native account abstraction keeps signature logic inside the account contract, so a wallet can move to a post-quantum scheme without a network-wide fork. We have no answer. We advertise contracts with no admin key and no upgrade path, and the honest translation of that is not “we will not change the rules on you”, it is “there is no procedure”. Bitcoin can soft-fork after a decade of arguing. A deployed immutable contract cannot do anything at all. The property we sell as protecting you from us is the same property that would stop us repairing a broken hash for you, and anyone selling immutability without saying that second part is selling you one side of a subtraction too.
This post convicts a post we published five days ago. Our piece on combining entropy sources argued that grinding is bounded by how many candidate values an attacker can cause to exist rather than by compute, and asserted in passing that keccak256 “runs millions per second on a laptop”. We still think the structural claim is right. We never dated that compute figure, never said what hardware it referred to, and would not have thought to re-measure it. A week like this one is what that omission looks like from the outside.
Three questions worth asking any operator
- Which numbers in your fairness claim are counts and which are costs? Only one of those two kinds survives somebody else’s good week.
- If the cost half halved tomorrow, what in your system would change, who is watching the number, and by what route would I hear about it?
- If the hash or the curve underneath you breaks, what is the procedure? Not the intention, not the roadmap. The procedure, and whether it can be executed without my consent.
We fail the third one, and we would rather say so than let you find out later.
The part that is genuinely funny
StarkWare’s remaining prize pools pay out by raffle. A 3% improvement qualifies you for a draw. So the people currently driving down the cost of cryptographic defence, who re-derive every submission on a CPU reference implementation and time it against inputs the solver has never seen, chose to allocate the reward by chance. We would only ask them the question we expect to be asked ourselves: what selects the winner, and can an entrant verify it afterwards?
The valuable thing StarkWare did this week was not the 79%. It was publishing both terms and saying out loud that the gap between them is the answer. Everyone downstream will quote one number. A security claim with a single number in it is not a claim about security at all. It is half of a subtraction, and the other half belongs to whoever bothered to open the kernel this week.
The silicon in the photograph did not change. The number did.
📷 Photo by Alexandre Debiève on Unsplash
