Quantum-Safe Bitcoin Without a Soft Fork? It's Clever. But Read the Fine Print

On 9 April 2026, Avihu Levy of StarkWare published “QSB: Quantum Safe Bitcoin Transactions Without Softforks,” a paper describing a way to sign Bitcoin transactions in a quantum-safe manner today, on the live network, with no protocol changes. If you care about Bitcoin’s post-quantum future, I think this is worth understanding. It is also worth understanding why it is not the answer.

Table of Contents

What the paper does

The core problem is straightforward. Bitcoin transactions are authorised by ECDSA or Schnorr signatures. Both are broken by Shor’s algorithm. Even if you lock your coins behind a spending condition that is itself quantum-safe (say, knowledge of a hash preimage), the signature binding the transaction together is still ECDSA. A quantum attacker can observe your transaction, extract the preimage, build a different transaction sending the coins to their own address, forge the ECDSA signature, and broadcast it. The spending condition was quantum-safe. The transaction was not.

QSB addresses this by building on Robin Linus’s Binohash scheme. The idea is to use Lamport signatures, which are hash-based and quantum-safe, to sign a cryptographic digest of the transaction entirely within Bitcoin Script.

The clever part is how that digest gets constructed. The scheme exploits FindAndDelete, a legacy quirk of how pre-SegWit OP_CHECKMULTISIG computes sighashes. Before computing the hash that a signature commits to, the script interpreter scans the scriptCode and removes every occurrence of each signature being verified. By embedding a pool of dummy signatures in the locking script and varying which ones are selected, the spender can generate many distinct sighash candidates from a single fixed transaction. A proof-of-work search over those candidates produces the digest, which is then Lamport-signed.

The original Binohash scheme relied on a signature-size puzzle to perform this proof of work. That puzzle depends on ECDSA hardness, which means it is itself broken by Shor’s algorithm. QSB replaces it with a “hash-to-sig” puzzle: hash a transaction-bound public key via RIPEMD-160 and check whether the output happens to be a valid DER-encoded ECDSA signature. This occurs with probability roughly 2⁻⁴⁶. Because the puzzle’s difficulty depends only on the pre-image resistance of RIPEMD-160, not on any elliptic curve assumption, it survives Shor’s algorithm. It also hardcodes SIGHASH_ALL, which eliminates a sighash flag vulnerability present in Binohash.

The result: approximately 118-bit second pre-image resistance under the Shor threat model, fitting within Bitcoin’s legacy script constraints of 201 opcodes and 10,000 bytes, using nothing but existing consensus rules. No soft fork required.

That is genuinely impressive cryptographic engineering.

The cost

Now for the fine print.

Constructing a single QSB transaction costs an estimated $75 to $200 in GPU compute at current cloud pricing. The cost comes from searching for valid subsets across both digest rounds, dominated by SHA-256 sighash computation and ECDSA key recovery for each candidate. The work is embarrassingly parallel (wall-clock time scales with the number of GPUs), but the dollar cost is relatively fixed.

For context, a standard Bitcoin transaction costs a few dollars in fees at typical congestion. QSB adds one to two orders of magnitude in off-chain compute on top of that. This is not a rounding error. It is a structural cost of the scheme, arising from the fixed 2⁴⁶ puzzle target set by the RIPEMD-160 DER probability. There is no parameter to tune it down.

The paper is upfront about this. It explicitly describes QSB as a “last-resort measure” and identifies three limitations: the cost and throughput do not scale to Bitcoin’s full user base, the user experience is significantly more complex than a standard transaction, and the scheme does not yet cover all use cases. Lightning Network channels, for example, are out of scope.

Built on bugs

Here is where I start to get uncomfortable.

QSB works because of two specific behaviours in legacy Bitcoin script execution. The first is FindAndDelete: when OP_CHECKMULTISIG verifies a signature, it removes that signature from the scriptCode before computing the sighash. This is what allows different dummy signature subsets to produce different sighash candidates. FindAndDelete was removed in SegWit (BIP 143) because it introduced complexity and potential attack vectors.

The second is the SIGHASH_SINGLE bug. When SIGHASH_SINGLE is used for an input whose index exceeds the number of outputs, Bitcoin sets the signed message to z = 1 regardless of transaction content. This allows the dummy signatures and their corresponding public keys to be precomputed once and reused across all transactions. It is, by any reasonable definition, a bug.

These are not features. They are artefacts of early implementation decisions that were subsequently deemed undesirable and removed or bypassed in later protocol versions.

Because QSB depends on both of them, it cannot use SegWit. It cannot use Taproot. The transactions are non-standard under default relay policy, meaning they will not be propagated by regular Bitcoin Core nodes. To broadcast one, you need to submit it directly to a mining pool that accepts non-standard transactions, such as Marathon’s Slipstream service.

The question I keep coming back to is simple: would you trust significant value to a scheme whose security depends on deprecated script behaviours and an acknowledged implementation bug? The consensus rules that permit QSB transactions exist today. But they exist because they have not been removed, not because they are actively maintained. If a future consensus change were to clean up FindAndDelete semantics or fix the SIGHASH_SINGLE bug, QSB would break. The scheme has no upgrade path within its own framework. It is worth asking why these behaviours have not already been cleaned up. The likely answer is that removing them at the consensus level risks breaking any existing UTXOs that depend on them, however obscure. A fix would probably require a versioned replacement (a SIGHASH_SINGLE_V2 or equivalent) rather than a direct removal, which means a soft fork, which brings us back to the coordination problem QSB was trying to avoid.

Security under Grover

Under the Shor-only threat model (ECDSA broken, hash functions unaffected), QSB achieves its full classical security: 118-bit pre-image resistance, 78-bit collision resistance. This is the scenario the scheme is designed for, and those numbers are solid.

Under the combined Shor and Grover threat model, the picture changes. Grover’s quadratic speedup reduces pre-image resistance to approximately 69 bits and collision resistance to approximately 65 bits. The paper argues, reasonably, that Grover is far less practical than Shor. It does not parallelise efficiently, and implementing the search oracle as a quantum circuit requires significant qubit overhead. That is currently the consensus view in the field.

But 69-bit pre-image resistance is not a number that gives me long-term confidence for a system securing financial value. NIST’s post-quantum security levels start at Category 1, which targets at least 128-bit security against quantum adversaries. QSB under Grover falls well short of that. The paper’s own framing of this as a “last resort” is appropriate.

What this actually is

QSB is a proof of concept. It demonstrates that Bitcoin’s existing consensus rules contain enough flexibility to construct quantum-safe transactions without protocol changes. I find that genuinely interesting. It shows that the cryptographic primitives available in legacy Bitcoin Script, combined with creative exploitation of implementation quirks, stretch further than most people assumed.

But as a practical path to quantum safety for Bitcoin, I do not think it works at scale. The authors know this and say so. The cost is prohibitive for ordinary users. The user experience is complex. The transaction format is non-standard. Lightning is out of scope. And the mechanisms it depends on are legacy artefacts that exist at the sufferance of consensus rules that could, in principle, be tightened at any time.

The paper closes by stating that “to the extent that the quantum threat is believed to be real, it remains necessary to continue the ongoing effort to research and implement the best possible solution for Bitcoin, one that is maximally efficient, user-friendly, and answers Bitcoin’s needs, through protocol-level changes.”

I think that is the right conclusion. QSB is an ingenious demonstration that a quantum-safe Bitcoin transaction is technically possible today. It is not a substitute for BIP-360, post-quantum signature opcodes, or the broader protocol-level migration that Bitcoin will eventually need. The existence of an emergency procedure does not remove the need for the actual upgrade.

What QSB does underline is just how seriously parts of the ecosystem are now taking the quantum threat. Google Quantum AI’s recent resource estimates have compressed the timeline considerably. While researchers here respond by building quantum-safe transactions out of bugs and deprecated script behaviours, some blockchains (such as QRL) have been post-quantum secure from day one without needing to retrofit their way there.