This is the third article in a series on Bitcoin's quantum transition. The first covered what breaks in the infrastructure around Bitcoin. The second proposed a one-way shelter architecture and left its exit path openly unresolved. This one is about a development that closes part of that gap and invalidates part of the design.
On 26 August 2026, at 20:48:34 UTC, MARA Pool included transaction 305a24ff…ab07 in block 964 199. It is 1 403 bytes, 5 282 weight units, 1 321 virtual bytes, and it paid 5 179 sat — a little under 4 sat per vB, which tells you something about how it reached a miner. Two inputs of 39 179 and 10 000 sat, one output of 44 000. The scriptSig on the second input is 1 168 bytes long, and its nSequence and nLockTime are both unusual values rather than the defaults. StarkWare announced it as the first quantum-safe Bitcoin transaction.
The coverage that followed mostly said Bitcoin had become quantum-safe. It has not, and StarkWare did not claim it had. What happened is narrower, real, and more interesting than the headline: a specially prepared output was spent under an authorization whose forgery resistance rests on hashes rather than on the hardness of the discrete logarithm.
I have a specific reason to care about this one. In April I published an architecture I called quantum parking, and I was explicit that its exit path was the weakest part. QSB looks like a candidate for that exit. Working through it, I found something I did not expect: it closes the gap I described, and in doing so it invalidates the deposit format the whole design was built on.
What was actually demonstrated
Two things get compressed into one in most of the coverage, and separating them is the first useful move.
This was a two-transaction demonstration. On 16 July 2026 at 17:16:53 UTC, in block 958 306, a funding transaction created the special output: 10 000 sat locked behind a 9 923-byte script. The spend followed 5 893 blocks later, roughly 41 days.
Decoding both transactions makes a detail visible that the announcement glosses over. The funding transaction produced two outputs, not one. The first is the QSB output. The second is an ordinary 39 179 sat P2WPKH output, and that output is the other input of the August spend — the one that paid the fee. So the fee input was not found and attached in August. It was created in July, in the same transaction, as part of the same preparation.
Both halves of the operation were positioned six weeks before either was used. That matters more than it sounds, and I will come back to it.
So QSB did not add quantum protection to an arbitrary existing UTXO at the moment of spending. The coins had to be parked in a purpose-built output first, at a cost of roughly ten kilobytes of block space, along with the funds that would later pay to move them.
The second distinction worth making is between consensus rules and relay policy. The transaction and its large bare-script output are consensus-valid, but nonstandard under normal relay policy, which means the ordinary P2P network is under no obligation to propagate them. StarkWare submitted directly to MARA through Slipstream. Once MARA put it in a valid block, full nodes did not ignore it — they validated the block under consensus rules and accepted it, which is exactly what they are supposed to do.
That is not a validity problem. It is a liveness problem, and it belongs in a different column of the risk register: miner channel availability, censorship resistance, and fee predictability.
The mechanism, and why the terminology matters
QSB uses a HORS-like one-time signature. When the output is prepared, the owner generates a set of random secrets, computes their hash commitments, and puts the commitments, a set of dummy signatures, and the verification logic directly into the locking script. The secrets themselves stay off-chain and function as the actual signing material.
To spend, the owner reveals only those preimages whose indices are determined by a digest of the specific spending transaction. The script hashes them and checks them against the commitments.
The hard part in Bitcoin was never checking preimages. It was binding them to the whole transaction. An attacker who can already break ECDSA sees the revealed preimages, copies them into a different transaction that pays himself, and forges the ordinary signature. QSB's contribution is a hash-based staple that makes finding such a substitute transaction expensive.
The staple works through a property of ECDSA that is rarely put to use: given a message and a signature pair, you can recover a public key that would have produced it, without knowing any private key. QSB fixes a signature in the script, recovers the key that matches the sighash of the specific transaction being built, then computes RIPEMD160 of that key and asks whether the resulting 20 bytes happen to parse as a valid DER-encoded signature. A random 20-byte string satisfies DER's structure with probability around 2⁻⁴⁶·⁴, which puts the expected search at roughly 92.9 trillion candidates.
Finding such a match takes work, and the search runs over the transaction fields covered by the signature hash — primarily nSequence and nLockTime, which can be varied without changing where the money goes. That is visible in the transaction itself. The QSB input carries nSequence 0x80001adc and the transaction carries nLockTime 0x34e20e81, neither of which is a value any wallet would produce by default. Those two fields are the search residue, left in the open. Change an output afterwards and the match dies, which is precisely the point: the binding is enforced by the cost of redoing the search.
Elliptic curve math stays inside the interpreter as a computational vehicle. The security assumption moves off it. An attacker running Shor still has to find a hash preimage that satisfies a structural puzzle, and Shor does not help with that.
Which is why I would not call the result quantum-safe. The accurate term is Shor-resistant transaction binding. The scheme removes the catastrophic zero that ECDSA and Schnorr have against Shor. It does not deliver 128-bit post-quantum security.
The published figures for the recommended configuration are about 2¹¹⁸ second-preimage resistance in a model where Shor breaks secp256k1 but hashes are attacked classically, about 2⁷⁸ collision resistance in the same model, and roughly 2⁵⁹ under full Grover. NIST's PQ Category 1 targets something in the neighbourhood of an AES-128 key search. 2⁵⁹ sits well below that line.
The middle figure deserves a second look, because it does not come from where a reader will assume. A birthday bound on a 2¹¹⁸ space gives 2⁵⁹, not 2⁷⁸, so the collision number is not that calculation. For a HORS-like scheme the binding quantity is subset-resilience rather than plain hash collision, and such a bound can legitimately sit above the birthday line. I have not reproduced the derivation, and the repository's own README states the 118 and 59 figures without naming the quantity behind the 78. I flag it because anyone who reaches for the birthday shortcut will conclude the number is wrong, and that conclusion would be too quick.
I want to be careful about how much weight that last number carries. A Grover attack is not a number you divide by two and then panic about. It needs a large fault-tolerant circuit, reversible SHA-256 and RIPEMD-160, reversible EC recovery, and it parallelizes badly. 2⁵⁹ is not a prediction that someone breaks this next year. It is a measure of margin, and the honest reading is that the margin is thinner than the label suggests.
Where I was wrong in April
In the quantum parking article I described QSB in one line as "quantum-safe transactions using STARK proofs without a soft fork." That is wrong. QSB does not use STARK at all. It is a Bitcoin Script construction built on legacy consensus semantics, hash-based one-time signatures, and three GPU searches. There is no proof system in it.
The error is small in word count and large in what it reveals. In April I had two different things sitting in the same mental bucket: hash-based proof systems on an execution environment, and hash-based authorization on Bitcoin's base layer. They are not the same layer and they do not solve the same problem.
Stated properly:
A STARK proof system can attest to state on the execution side — ownership, reserves, burns, withdrawal conditions. It says nothing about who is allowed to move a Bitcoin UTXO, and it cannot make a Bitcoin transaction resistant to substitution.
QSB does one thing: it binds an authorization to one specific Bitcoin transaction using work that Shor does not shortcut. It proves nothing about state anywhere else.
A full architecture needs both, in different places. Conflating them, as I did, produces a design that looks complete on a diagram and has a hole exactly where the two layers were supposed to meet.
The part that breaks the deposit
Here is the finding that made me rewrite rather than extend.
The April architecture rested on a specific and deliberate choice: the Bitcoin-side address is receive-only P2WSH. The public key sits behind a hash and never appears on-chain, because the address never spends. I called the missing spending path the security feature rather than a limitation, and I still think that reasoning was sound on its own terms.
QSB cannot be attached to that. A QSB spend is only possible from an output that was created as a QSB output. The locking script with its commitments and dummy signatures has to be there from the beginning. You cannot hold coins in an ordinary hash-protected P2WSH deposit and then apply QSB at the moment of exit.
Which means the sentence I wrote in April — hold BTC behind a hash, and when the exit is needed, use whatever mechanism has matured by then — does not survive contact with this particular mechanism. The choice has to be made at deposit time, not at exit time.
The reframing is not subtle:
Not "park BTC in an ordinary hash-protected address and apply a quantum-safe spend later," but "create a purpose-built one-time vault, or a chain of pre-positioned vault states, before the attacker exists."
This also changes what the exit scenarios look like. Of the three I laid out in April, Scenario A (a ZK proof of key ownership accepted by consensus) and Scenario B (a dormant PQC script branch) both still depend on future Bitcoin consensus changes and are unaffected by this development. Scenario C, permanent wrapped representation, is likewise untouched. QSB is not a fourth scenario bolted onto the same deposit. It is a different deposit with its own exit, and it competes with the P2WSH construction rather than completing it.
There is a compensating advantage, and it is the reason this is worth the rewrite. The three GPU searches cost roughly the same whether the output holds 10 000 sat or a large aggregated balance. Public estimates put the search at something like 75 to 150 dollars in the repository's own accounting, or a few hundred in the more cautious framing from the paper and StarkWare, against a measured rate of 238 million candidates per second on an RTX PRO 6000 and a real hit in about six hours on eight GPUs. The on-chain cost of a roughly 10 KB funding transaction plus a 1.4 KB spend is fixed too. Fixed costs against a variable balance is exactly the shape that suits a rare, large, aggregated vault exit and does not suit a wallet.
Those dollar figures should not be carried into a crisis scenario, though. In a period of blockspace scarcity and heavy demand for miner-direct submission, the on-chain fee would dominate the GPU cost, and the miner channel itself becomes the scarce resource.
What it protects, and what it does not
Worth stating both lists plainly, because most of the coverage gave only the first.
It protects a pre-prepared QSB output, the binding of a specific spend to specific inputs and outputs, and the on-spend window during which one-time preimages have already become public. It protects against an attacker who breaks ECDSA or Schnorr with Shor but cannot practically find the required hash preimages.
It does not protect ordinary P2PK, P2PKH, P2WPKH, P2TR or multisig outputs, and it does not retrofit onto them. It does not protect the transfer into a QSB output if the source UTXO has to be spent while an attacker is already active. It does not help an address whose public key was exposed before the protective transaction. It does not protect coins after a QSB spend if they land in an ordinary output. It says nothing about Lightning, miner availability, censorship, fee spikes, reorgs, or the owner losing the HORS secrets.
There is one item on that list I would flag above the others. Private submission to a miner reduces the window during which a transaction is visible, but it does not create a cryptographic guarantee. QSB's author notes the case directly: if a public key is revealed in a mined block, another miner with quantum capability can attempt to build a competing block and redirect the funds. That pushes the whole design toward pre-positioning rather than emergency evacuation. A lifeboat you have to build after the ship starts sinking is not a lifeboat.
This is where the fee input comes back. In the demonstration, the coins that paid to move the QSB output were themselves prepared in advance, in the same transaction, six weeks earlier. That was probably operational convenience rather than a security requirement. But think about what it would mean under an active attacker. The fee input is an ordinary P2WPKH output, and spending it reveals its public key in the same transaction that unlocks the QSB output. If you have to source that fee from an ordinary wallet at the moment of exit, you have reintroduced exactly the exposure the QSB output was built to avoid, on the same transaction. Pre-positioning is not just about the vault. It extends to whatever pays to open it.
What has not been shown
The demonstration proves that the construction executes. A special output was created, a specific spending transaction was accepted by a miner and included in a mainnet block, and Bitcoin's consensus implementation validated it. A complex legacy-script construction ran in production rather than on paper. That is not nothing.
It does not prove that the exact mainnet parameters deliver the claimed 118, 78 and 59 bits. It does not rule out shortcut, combinatorial or script-level attacks. It does not establish that the implementation matches the model in the paper. One mined block is evidence about consensus validity, not about cryptographic strength.
The public repository is also not yet a turnkey reproducibility package, and the open items in it are worth reading before treating the parameters as settled. An open pull request warns that after fixes to an off-by-one and to SIGHASH_SINGLE handling, different copies of the pipeline and their generated artifacts are out of sync. An open issue asks about the correspondence between a recovered key and two different sighashes in the paper's notation, and has no published resolution. State and solution files are excluded from the repository because they contain HORS preimages and nonces, which is the right call before spending and unhelpful for parameter verification after confirmation.
None of that means the mainnet transaction is broken, and I want to be explicit that I am not claiming it is. It means the gap between one mined block and an independently verified security claim has not been closed yet, and closing it needs artifacts that are not public: the exact configuration of the mainnet spend, a manifest tying paper version to commit to funding transaction to spending transaction, and a reproducible pipeline someone else can run.
Formal security proofs are listed in the paper as future work. I found no peer-reviewed publication and no independent cryptographic audit. There is a technical critique from QRL that is useful on legacy dependencies and the Grover margin, and should be read knowing that QRL promotes its own post-quantum network.
How this sits next to the protocol work
QSB and the BIP track are solving different time horizons, and treating them as competitors is a category error.
BIP-360 proposes Pay-to-Merkle-Root without a Taproot key path, which addresses long exposure but explicitly leaves short exposure open — at spending time a post-quantum signature may still be required. BIP-361 sketches the wider migration: restrict creation of new legacy outputs once quantum-resistant outputs exist, then later introduce encumbrance and rescue rules for the ECDSA and Schnorr set.
Against that, QSB is an expensive emergency construction available under today's consensus for an output prepared in advance. A native post-quantum signature type, whenever it arrives, is the scalable answer. QSB is a bridge technology, and StarkWare's own framing of it as a lifeboat is the right one — the word is Eli Ben-Sasson's, after comparing crypto to passengers on the Titanic, and it is worth noting he put a soft fork on the other side of that sentence.
The component that is actually missing
If I were building on this now, the blocker would not be cryptography and would not be the GPU bill.
A QSB spend consumes the entire output. Any partial withdrawal from a large aggregated vault means spending the whole thing: paying out what is needed, and returning change into a new protected output. That new output requires fresh HORS secrets, another roughly 10 KB locking script, and another miner-direct inclusion. The mainnet demonstration spent a QSB input into an ordinary output. A QSB-to-QSB rollover with a protected change output has not been shown.
For a live vault that is the whole game. One-time key material has to be generated, reserved and protected in advance across many future states. Losing the secrets means losing access. Reusing them is not an option, because the material becomes public the moment it is used. And each rollover has to clear the same nonstandard-relay hurdle, which currently means one miner with a working submission channel.
So the honest position at the end of this is narrower than where I started in April, and I prefer it that way.
QSB is not the missing piece of quantum parking. It is a well-built Bitcoin-side actuator for a vault that was pre-positioned as a QSB output from the beginning, and it makes a specific attack — copy the revealed witness, redirect the output, forge the signature — expensive in a way that survives Shor. That is a real contribution to a problem that had no answer inside current consensus rules.
The architecture question it leaves is rollover. Not proof systems, not curve mathematics, not the cost of a GPU cluster. Whether a chain of one-time vault states can be operated over years, with protected change at every step, secrets managed without loss or reuse, and inclusion that does not depend on a single mining pool.
If someone has thought through the key management side of a multi-state rollover, I would like to read it. That is the part where I do not yet have a design I would defend.
Disclosure and scope
This is independent technical commentary reflecting my own views. No entity discussed commissioned, sponsored, paid for, reviewed, or approved it, and I hold no financial interest in the instruments, protocols or organizations mentioned. It is not investment, legal or tax advice.
On the sourcing: the transaction figures above — sizes, weight, inputs, outputs, script lengths, nSequence, nLockTime, block heights and timestamps, and the relationship between the July funding transaction and the August spend — were decoded from the raw transactions and are independently checkable by anyone. The combinatorial figures are arithmetic and can be recomputed. Everything else, including the search cost estimates, the hardware throughput numbers, and the 118, 78 and 59 bit security claims, comes from the scheme's authors and their published materials; I have not verified those independently, and I am not aware of a published audit. Where I describe what a construction does not establish, that is a statement about available public evidence, not an assertion of a defect. On-chain facts and repository state are as of 28 August 2026.