The RIPEMD-160 That Wasn't

In August, StarkWare and Avihu Levy landed something a lot of people assumed was still years away: a quantum-safe Bitcoin transaction, confirmed on mainnet, with no soft fork and no new opcodes. It rides entirely on Bitcoin’s existing legacy Script rules. The non-standard transaction was mined directly by MARA’s Slipstream service, since it never would have survived normal relay policy. The scheme is called QSB, Quantum Safe Bitcoin, and the write-up is genuinely clever.

I wanted to see it work with my own eyes rather than take the announcement on faith. So I rebuilt the whole thing from public data: the confirmed transaction, its funding transaction, and the pinned source repository. I re-executed the spend against unchanged Bitcoin Core, funded a copy of the exact locking script on a private regtest node, and measured how hard the puzzle actually is on commodity hardware. The transaction is real and it verifies. But while reproducing it, one detail refused to line up with the paper.

The deployed script does not use the hash function the paper says it uses.

What QSB actually does

Standard Bitcoin transactions are protected by ECDSA signatures. Shor’s algorithm breaks ECDSA outright, so a large quantum computer could forge them. QSB sidesteps this by moving the security out of the elliptic curve and into a hash function, using a trick that has been floating around for a while: the output of a hash function is, very occasionally, a structurally valid DER-encoded ECDSA signature.

That sounds like nonsense until you look at what “valid DER” means. A DER signature has a rigid shape: a 0x30 tag, a total-length byte, two 0x02 integer fields whose lengths must be internally consistent, and positive integers with no stray leading zeros. A random 32-byte string satisfies all of those constraints only about once in every few trillion tries. So you can turn “find an input whose hash happens to be a valid signature” into a proof-of-work puzzle whose difficulty depends only on the hash function, never on the curve. That is what makes it quantum-safe: Shor buys you nothing, and even Grover only halves the exponent.

The construction chains three pieces together for each check:

A hardcoded signature, sig_nonce, baked into the locking script with a fixed SIGHASH_ALL flag. Because it commits to the whole transaction, it pins every field.
ECDSA public-key recovery, a public computation anyone can run, turns that fixed signature plus the transaction’s sighash into a transaction-bound key, key_nonce. Change any part of the transaction and this key changes.
The script hashes key_nonce and demands that the result be a valid DER signature. That is the puzzle. Finding a transaction whose derived key hashes to a valid signature is the ~2⁴⁶ work.

The full transaction wraps this in two “digest rounds” that select subsets of dummy signatures via a HORS one-time signature and Bitcoin’s legacy FindAndDelete quirk, so the chosen subset itself becomes part of the signed message. It is a beautiful abuse of consensus rules that were never meant to compose this way. The published locking script is 9,923 bytes and lands on exactly 201 non-push opcodes, right against Bitcoin’s legacy limit.

The tell

Every piece of QSB’s public documentation says the puzzle hash is RIPEMD-160. The repository’s README states the script “hashes a transaction-bound public key via OP_RIPEMD160” at a ~2^-46 target. The paper weighs SHA-256 against RIPEMD-160 and then commits, in as many words:

“SHA-256 has a slightly higher DER probability (~2^-45.4 vs. ~2^-46.4), reducing off-chain work by roughly 2×, but the larger puzzle target slightly weakens the security analysis. … For simplicity, we adopt RIPEMD-160 throughout.”

— the QSB paper, on choosing the hash function

When you actually disassemble the locking script from the confirmed transaction, the puzzle opcode at all three sites, the pinning check and both digest rounds, is OP_SHA256 (0xa8). Not OP_RIPEMD160 (0xa6). The shipped artifact is the SHA-256 variant the paper described and then explicitly set aside.

	Paper & README say	The mainnet transaction does
Puzzle hash	`OP_RIPEMD160`	`OP_SHA256` (`0xa8`)
Hash output	20 bytes	32 bytes
DER hit probability	2^-46.43	2^-45.43
Advertised work	~2⁴⁶	~2^45.4 (about half)

I recomputed both probabilities from first principles rather than trusting the paper’s round numbers: count the byte strings of each length that form a syntactically valid DER signature, divide by the total. A 32-byte SHA-256 output clears the bar with probability 2^-45.43; a 20-byte RIPEMD-160 output, 2^-46.43. That one-bit gap is exactly the ~2× the paper flagged. In other words, the transaction the world saw as the ~2⁴⁶-work quantum-safe demonstration actually ran a puzzle costing about half that.

What I did to be sure

A claim like this is worthless unless it reproduces, so the point was to make every number fall out of a script anyone can rerun against public data.

Re-executed the whole spend. Feeding the confirmed transaction’s witness back through the published locking script under legacy semantics reproduces every check: all four CHECKSIGVERIFY stages, both 10-of-10 CHECKMULTISIG rounds, and all fifteen HORS HASH160/EQUALVERIFY checks pass. The recovered key_nonce matches the on-chain witness, and its SHA-256 hash is valid DER while its RIPEMD-160 hash is not, the difference stated plainly.
Confirmed it against real consensus. I funded output 0 of the recorded funding transaction, the exact 9,923-byte script, on an isolated regtest node with valueless coins, and unchanged Bitcoin Core 31.1 accepted and mined it.
Measured the puzzle. I ran a bounded search for a fresh pinning solution, varying the transaction and re-deriving the key each time, using libsecp256k1 from the same unchanged Core tree.

The search results are the honest anticlimax you would predict for a 2⁴⁵-scale puzzle on a single CPU:

Search	Candidates	Key trials/sec	DER hits
Pure-Python reference	14,336	226	0
Native libsecp256k1	9,852,928	164,205	0

Zero hits is exactly right. Each candidate yields two independent key trials (one per valid recovery branch), so the roughly ten million native candidates are about 19.7 million key trials, and at 2^-45.4 per key trial the expected number of hits is about four in ten million. Extrapolating from the native rate, a single core would need on the order of nine years to solve the deployed SHA-256 puzzle once, or about eighteen for the RIPEMD-160 variant. The QSB team did not wait nine years; they rented GPUs, roughly $75 to $150 worth, which is the whole practical point of the scheme. The work is embarrassingly parallel and the search touches no secrets, so you can safely rent it out.

What this is, and what it isn’t

Let me be careful here, because it would be easy to inflate this. This is not a vulnerability and not a break. The mainnet transaction is completely valid; Bitcoin Core accepted it; the money moved. Both hash variants are described in the paper, and SHA-256 is a legitimate, deliberate QSB option, arguably the better engineering choice, since it is cheaper to grind and lets you shrink the script. Nothing here weakens Bitcoin or QSB in any operational sense.

What it is is a small, precise discrepancy between the documented design and the deployed artifact, the kind that only surfaces when you stop reading the paper and start disassembling the bytes. The headline security figure everyone will cite is ~2⁴⁶. The transaction that actually shipped ran at ~2^45.4, about half. If you are going to reason about QSB’s margins, quote them, or build on the scheme, that is worth knowing, and it is a good argument for the documentation to match the chain.

Mostly, though, it is a reminder of why reproduction matters. A confirmed transaction is a wonderful thing: it is a claim you can check all the way down, byte by byte, without anyone’s permission. So I checked.

Reproduce it

Everything above derives from public data, so anyone can check it independently. The reference transaction is 305a24ffea912b9cf428f29ebf952321c96dab5bab284fc0d0801562f5abab07, confirmed at block height 964,199 with a 5,179-sat fee, and the QSB sources are pinned at commit 2c917205 of the public QSB repository. The three checks are self-contained:

Disassemble the puzzle opcode. Parse the funding transaction’s output script and read the byte at each of the three puzzle sites; it is 0xa8 (OP_SHA256), not 0xa6 (OP_RIPEMD160).
Recompute the DER probabilities. Count the byte strings of length 32 and length 20 that form a syntactically valid DER signature and divide by the total; you get 2^-45.43 and 2^-46.43.
Verify against consensus. Feed the confirmed spend and its funding parent to Bitcoin Core’s script verifier, then fund the same script on an isolated regtest node and confirm Core accepts it.

I ran these through a small reproduction harness, now public at github.com/posix4e/btc-pq:

git clone https://github.com/posix4e/btc-pq
cd btc-pq
python -m btc_pq.cli baseline    # verify the confirmed spend under Core 31.1
python -m btc_pq.cli phase3      # fund the exact script on regtest; bounded puzzle search

Regtest only, valueless coins, public data, no keys that hold funds. The SHA-256 and RIPEMD-160 DER probabilities are recomputed from scratch in the run and match the figures above. Nothing in the harness is required to confirm the finding, since every input is on-chain or in the public QSB repository.