305a24ffea912b9cf428f29ebf952321c96dab5bab284fc0d0801562f5abab07, the mainnet spend using Avihu Levy’s Quantum-Safe Bitcoin, or QSB, construction. The specially protected output contained 10,000 satoshis, required no soft fork and no new opcode, and reached MARA Pool through its Slipstream miner-direct service. That is a genuine Bitcoin engineering milestone—but it did not change the cryptography protecting ordinary Bitcoin outputs. Bitcoin’s wider quantum-migration problem, including work around BIP-360 and Blockstream’s SHRINCS, is still very much open.If you want a broader grounding in how Bitcoin transactions, keys and UTXOs work before going deeper, see the CryptoLinks Bitcoin Wiki and learning resources and our review of the Bitcoin Developer Guide.
Key takeaways
- QSB worked under existing Bitcoin consensus rules. No soft fork, new opcode or Bitcoin Core consensus change was required for this demonstration.
- The transaction was non-standard under ordinary relay policy. It needed miner-direct submission through MARA Slipstream rather than normal public mempool propagation.
- QSB protects a specially constructed UTXO, not Bitcoin globally.
- Already-exposed elliptic-curve public keys remain a separate migration problem.
- BIP-360 remains a Draft soft-fork proposal centered on Pay-to-Merkle-Root, or P2MR.
- SHRINCS is not active on Bitcoin mainnet. Blockstream has demonstrated post-quantum work on Liquid, while the current Bitcoin-oriented SHRINCS specification remains research-stage.
What StarkWare actually put on Bitcoin mainnet
The mainnet confirmation matters because QSB is no longer only a paper construction.
The Bitcoin blockchain shows the QSB spend inside block 964,199, mined by MARA Pool at 20:48:34 UTC on August 26, 2026. StarkWare describes the transaction as what it believes to be the first quantum-safe Bitcoin-mainnet transaction.
| QSB mainnet fact | Result |
|---|---|
| Transaction ID | 305a24ffea912b9cf428f29ebf952321c96dab5bab284fc0d0801562f5abab07 |
| Bitcoin block | 964,199 |
| Block timestamp | August 26, 2026, 20:48:34 UTC |
| Miner | MARA Pool |
| QSB-protected output | 10,000 sats |
| Reported transaction inputs | 44,000 sats across two inputs |
| Reported transaction fee | 5,179 sats |
| Reported QSB locking script | Approximately 9,923 bytes |
| Ordinary mempool relay | No |
| Miner submission | MARA Slipstream |
| Soft fork required | No |
| New opcode required | No |
The important distinction is that the 10,000 sats were first placed into a specially constructed QSB-protected output and then spent using the QSB authorization mechanism. Saying simply that “10,000 sats were sent quantum-safely” hides the most interesting part of the demonstration.
Conceptually, the sequence was:
Ordinary Bitcoin funding transaction
↓
10,000-sat QSB-protected UTXO
↓
QSB spending transaction
↓
MARA Slipstream
↓
MARA Pool
↓
Bitcoin block 964,199
How can a quantum-resistant Bitcoin transaction work without a soft fork?
QSB does not install a new post-quantum signature algorithm into Bitcoin.
Instead, Levy’s construction uses functionality that Bitcoin already knows how to validate. The public implementation combines hash commitments, HORS/Lamport-style one-time-signature ideas, OP_RIPEMD160, existing signature checks and legacy transaction-sighash behavior.
The conceptual trick is unusual: the legitimate spender performs a very large computational search off-chain until transaction-derived values satisfy conditions that Bitcoin’s existing signature machinery already understands.
That turns an apparent limitation into a feature. Bitcoin still executes its old validation rules, but the authorization security of the QSB construction is designed to depend critically on hash preimages and transaction binding rather than the assumption that an elliptic-curve private key cannot be recovered from its public key.
This is why QSB can use Bitcoin’s existing ECDSA verification machinery without claiming that ECDSA itself becomes quantum-resistant.
For readers who want the deeper protocol mechanics behind scripts, sighashes and transaction validation, the Bitcoin Developer Guide is a useful companion resource.
Why ECDSA can appear inside QSB without securing it
At first glance, QSB looks contradictory.
Bitcoin’s legacy signature system uses ECDSA over secp256k1, while newer Taproot key-path spending uses Schnorr signatures over the same elliptic curve. A sufficiently capable fault-tolerant quantum computer running Shor’s algorithm could, in principle, break the discrete-logarithm assumption that protects both.
Yet QSB still invokes Bitcoin’s existing signature verification behavior.
The distinction is between ECDSA as a hardness assumption and ECDSA verification as a computational gadget.
Normal Bitcoin ownership assumes an attacker cannot derive the private key corresponding to a public key. QSB instead arranges values so that Bitcoin’s existing verifier becomes part of a larger hash-based puzzle. Levy’s security argument is therefore based on the difficulty of finding suitable hash preimages and modifying a transaction without repeating enormous searches.
QSB does not remove ECDSA from Bitcoin. It repurposes machinery Bitcoin already possesses.
Transaction pinning is a critical part of the construction
A quantum-resistant authorization system would not help much if an attacker could simply copy the authorization and change the destination.
QSB therefore binds its expensive search to the intended spending transaction.
Fields affecting the transaction sighash—including relevant outputs, sequence and locktime data—feed into the values used by the QSB construction. If an attacker changes the destination or another committed transaction field, the sighash changes.
That changes the values feeding the QSB puzzle, which means the expensive search has to be repeated.
The intended effect is that a future attacker cannot merely recover an exposed elliptic-curve private key, replace the owner’s destination and produce an ordinary competing signature.
I would still avoid interpreting this as proof that every conceivable implementation, malleability or miner-related attack has been eliminated. QSB remains experimental cryptography and should be independently reviewed as such.
Consensus-valid does not mean mempool-standard
This may be the most useful Bitcoin lesson in the entire experiment.
A transaction can be valid under Bitcoin consensus rules while still being rejected from ordinary nodes’ mempools under default policy.
Consensus determines what transactions may legally appear in a valid Bitcoin block. Standardness policy is an additional set of rules Bitcoin Core nodes typically apply when deciding what they will store and relay through the peer-to-peer network.
These are not the same thing.
QSB fits the unusual middle category:
- Bitcoin consensus can validate it.
- Default mempool policy does not normally relay it.
- A miner can still deliberately accept it.
- Once included in a valid block, fully validating nodes accept the confirmed transaction.
So the correct wording is not “Bitcoin nodes rejected QSB.”
The more accurate statement is: ordinary nodes would not relay the transaction under default policy, but Bitcoin nodes accept it as consensus-valid once it appears in a valid block.
Why MARA Slipstream mattered
Because the QSB spend could not travel through the ordinary public mempool, the researchers needed another route to block inclusion.
That route was MARA Slipstream, a service designed to let users submit certain non-standard Bitcoin transactions directly to MARA.
The MARA dependency is therefore operational rather than cryptographic.
QSB’s mathematics does not depend on MARA. In principle, another miner willing and able to accept the same consensus-valid transaction could mine it. But today, a usable QSB path depends on obtaining access to a miner that will accept the transaction outside normal relay policy.
That distinction—cryptographic decentralization versus practical relay accessibility—is important. You can learn more about how mining pools participate in Bitcoin block production in the CryptoLinks Bitcoin mining pools guide.
The GPU grinding that makes QSB possible—and expensive
QSB moves much of its cost away from Bitcoin nodes and into transaction construction.
The public implementation describes several large searches: transaction pinning, a first digest search and a second digest search. The relevant DER-format target has a probability of roughly 2-46.4 per random candidate at the consensus level.
That requires enormous amounts of trial-and-error computation.
This should not be confused with Bitcoin mining. QSB’s GPU grinding is off-chain transaction-construction work, not proof-of-work securing the Bitcoin blockchain.
| QSB computation stage | Public repository estimate |
|---|---|
| Transaction pinning | $25–$50 |
| Digest round 1 | $25–$50 |
| Digest round 2 | $25–$50 |
| Original modeled total | $75–$150 |
| Completed mainnet experiment | Approximately $150–$200 reported; computation took hours |
The narrower $150–$200 figure should be treated as a reported estimate for the completed experiment rather than an audited cloud-computing invoice. Exact mainnet GPU-hours, provider billing and the final hardware mix have not been publicly itemized in enough detail to present them as independently verified accounting data.
The QSB repository also estimates approximately 118 bits of second-preimage resistance under its Shor-threat model, with roughly 59 bits against an idealized Grover speedup. Those are Levy’s analytical estimates, not an independent cryptographic certification.
What QSB actually protects from a future quantum computer
The key issue is not simply whether an address has been spent from. It is whether the relevant elliptic-curve public key is already visible to an attacker.
There are two useful categories.
Long-exposure attacks
In a long-exposure scenario, a public key is already visible on-chain for months or years before its owner attempts to spend.
Examples can include:
- old P2PK outputs;
- Taproot/P2TR outputs, where an elliptic-curve key is committed directly in the output;
- reused P2PKH or P2WPKH addresses after the relevant public key has already appeared in a previous spend.
Short-exposure attacks
Fresh P2PKH and P2WPKH outputs can initially expose a hash of the public key rather than the public key itself.
The public key becomes visible when the owner spends.
A hypothetical sufficiently fast quantum attacker would then have the confirmation window to recover the corresponding private key, construct a conflicting spend and try to get it confirmed first.
QSB is especially interesting because its transaction-binding construction aims to defend against this kind of replacement attack without requiring Bitcoin to know a new post-quantum signature opcode.
The biggest catch: already-exposed Bitcoin keys cannot simply be rescued
This is the limitation I would emphasize most strongly.
If a cryptographically relevant quantum computer exists and an output’s elliptic-curve public key is already visible, the attacker does not have to wait for the legitimate owner to initiate migration.
The attacker can attack that public key directly.
If they obtain the classical private key first, moving the legitimate owner’s next output into QSB does not restore the secrecy that has already been lost.
| Existing Bitcoin output/state | Public key exposed? | QSB migration potential before a CRQC? | Main issue |
|---|---|---|---|
| Fresh P2PKH | Usually no | Potentially yes | Key is revealed during migration spend |
| Fresh P2WPKH | Usually no | Potentially yes | Same short-exposure window |
| Reused P2PKH | Often yes | Limited once exposed | Previous spend revealed key |
| Reused P2WPKH | Often yes | Limited once exposed | Previous spend revealed key |
| P2PK | Yes | Can migrate ahead of threat | Long exposure |
| P2TR / Taproot | Yes | Can migrate ahead of threat | Long exposure |
| QSB-protected output | Hash-based construction | Intended protection | Experimental and non-standard |
This is also why QSB should not be presented as a way for Satoshi-era P2PK coins to remain safe after a quantum attacker becomes operational. Many early P2PK outputs already publish their public keys.
Why Taproot has a different quantum-exposure profile
Taproot is not insecure today.
The concern exists only in the hypothetical presence of a sufficiently capable quantum attacker.
A P2TR output commits directly to an elliptic-curve public key. That key is visible before the output is spent, creating a long-exposure profile.
Fresh P2PKH and P2WPKH outputs are different because a public-key hash can remain on-chain until the first spend reveals the actual public key.
This difference is one reason BIP-360 was proposed.
BIP-360: the protocol-level Pay-to-Merkle-Root route
BIP-360 is currently a Draft Bitcoin consensus soft-fork proposal for a new output type called Pay-to-Merkle-Root, or P2MR.
P2MR preserves much of Taproot’s script-tree functionality while removing the ordinary elliptic-curve key-path spend. Instead of committing to an internal public key plus a script tree, a P2MR output commits to the Merkle root of the script tree itself.
Its immediate purpose is to reduce long-exposure quantum risk.
But BIP-360 is not a complete post-quantum signature system by itself. Short-exposure protection and practical post-quantum signatures still require additional work.
That means these two statements should always appear together:
QSB required no soft fork for its August 26 mainnet transaction.
A protocol-level upgrade is still the more practical long-term path if Bitcoin wants standardized, wallet-compatible post-quantum protection.
A soft fork should also not be confused with a hard fork. Bitcoin soft forks introduce stricter validation rules within Bitcoin’s established upgrade model.
Blockstream’s SHRINCS takes a different approach
Blockstream Research is working on a more conventional hash-based signature direction.
SHRINCS is designed as a compact post-quantum signature construction optimized around Bitcoin-like block-space constraints. It uses SHA-256-based hash signatures rather than relying on elliptic-curve hardness for its post-quantum security target.
Blockstream demonstrated post-quantum signing on the Liquid Network in March 2026.
Liquid is a production Bitcoin sidechain, not Bitcoin mainnet. That makes the SHRINCS milestone real and technically relevant, but it should not be described as a Bitcoin-mainnet post-quantum transaction.
There is also an important status update for readers following older SHRINCS coverage. The current public SHRINCS draft specification lists:
- 48-byte public keys;
- 548–4,619-byte stateful signatures;
- 5,777-byte stateless signatures.
The specification currently labels itself Draft and still shows its BIP number as unassigned. SHRINCS is therefore not an activated Bitcoin feature.
Blockstream’s related SHRIMPS work deals with an especially awkward property of compact stateful hash-based signatures: signing devices must safely track state.
If a stateful wallet restores an old backup and unknowingly rewinds its signing state, it can reuse secret material in ways that undermine security.
This becomes especially important for hardware wallets, multisig custody and multi-device setups.
That is a useful reminder that post-quantum migration is not simply a matter of swapping Schnorr for another signature algorithm. Wallet backups, device synchronization, derivation, multisig, recovery and institutional procedures all matter.
QSB vs. BIP-360 vs. SHRINCS
| Criterion | QSB | BIP-360 / P2MR | SHRINCS |
|---|---|---|---|
| Bitcoin mainnet today | Yes, experimental demonstration | No | No |
| Soft fork required | No for demonstrated construction | Yes | Bitcoin integration would require consensus functionality |
| Main idea | Hash-based spend using existing Bitcoin rules | Quantum-safer output architecture | Purpose-built hash-based signatures |
| Standard relay today | No | Not applicable until activation | Not applicable until activation |
| Long-exposure protection | Yes for QSB outputs | Primary goal | Intended with PQ spending conditions |
| Short-exposure protection | Intended | Not solved alone | Intended |
| Already-exposed keys | No automatic rescue | Migration problem remains | Migration problem remains |
| Wallet-ready | No | No | No |
| Primary practical cost | Grinding, script size and miner routing | Consensus coordination | Signature size and state management |
| Status | Mainnet proof of concept | Draft BIP | Draft research/specification |
I would not treat these projects as direct competitors where one winner makes the others irrelevant.
They answer different questions.
QSB asks: Can Bitcoin validate a hash-secured spending construction today without changing consensus?
BIP-360 asks: Can Bitcoin gain an output architecture that removes a permanently exposed elliptic-curve key path?
SHRINCS asks: What could an efficient Bitcoin-oriented post-quantum signature system look like if Bitcoin consensus eventually learns to verify it?
Why Bitcoin cannot simply adopt any post-quantum signature
NIST has already standardized post-quantum signature systems, including ML-DSA and the hash-based SLH-DSA.
That does not mean Bitcoin can simply choose one and call the problem solved.
Bitcoin has unusually expensive bytes. Every signature competes for block space, propagates across the peer-to-peer network and has to be processed by validating infrastructure.
| Scheme / construction | Approximate size | Status for Bitcoin |
|---|---|---|
| BIP-340 Schnorr | 64-byte signature | Live |
| ML-DSA-44 | About 2,420-byte signature | NIST standard; not Bitcoin consensus |
| SLH-DSA-SHA2-128s | 7,856-byte signature | NIST standard; not Bitcoin consensus |
| SHRINCS current draft | 548–4,619 bytes stateful; 5,777 bytes stateless | Research/draft |
| QSB mainnet experiment | Approximately 9,923-byte locking Script reported | Experimental Bitcoin-mainnet demonstration |
The last row deserves a warning: QSB’s roughly 9,923-byte figure describes its reported locking Script, so it should not be compared one-for-one with a standalone 64-byte Schnorr signature.
The hard problem is not finding post-quantum cryptography. It is fitting post-quantum cryptography into Bitcoin’s block space, wallet model, hardware devices, custody infrastructure and governance process.
QSB is a lifeboat, not Bitcoin’s final quantum upgrade
The “lifeboat” analogy is useful if we do not push it too far.
A lifeboat gives you an emergency route.
It does not redesign the ship.
It does not automatically accommodate every passenger.
And it does not remove the reason to strengthen the underlying system.
QSB’s advantages are substantial:
- it moved from a paper into a real Bitcoin-mainnet block;
- it required no consensus change;
- it required no new opcode;
- it demonstrates surprising flexibility in existing Bitcoin Script;
- it offers researchers a measurable emergency fallback;
- it provides real-world data about compute, block space, miner policy and deployment friction.
Its limitations are equally real:
- large and unusual Script construction;
- hours of off-chain computation;
- meaningful GPU cost;
- non-standard relay;
- miner-direct submission;
- no ordinary wallet workflow;
- no mainstream hardware-wallet integration;
- no mature recovery or descriptor standard;
- no automatic rescue for already-exposed keys;
- no network-wide post-quantum protection.
Mainnet demonstration is not the same as production readiness
A useful way to judge QSB is as a development ladder.
- Paper: mathematical construction exists — reached.
- Reference implementation: software exists — reached.
- Local/test environment: construction can be exercised — reached.
- Mainnet demonstration: real Bitcoin transaction mined — reached August 26, 2026.
- Standard relay: normal public mempool propagation — not reached.
- Mainstream wallet integration: normal user-facing wallet support — not reached.
- Hardware-wallet/custody support: robust production signing and backups — not reached.
- Broad interoperable adoption: ecosystem-wide deployment — not reached.
- Protocol-level standardized PQ migration: network-wide long-term solution — not reached.
Mainnet success is important without being production readiness.
Does QSB solve the Satoshi-era and lost-coin problem?
No.
Some of Bitcoin’s oldest outputs use P2PK and expose public keys directly. If a cryptographically relevant quantum computer becomes capable of deriving the associated private key before those coins have migrated, an attacker could potentially compete for them using the same classical spending authority.
QSB does not answer what Bitcoin should eventually do with vulnerable coins whose owners never migrate.
Possible policy approaches discussed across the broader quantum debate include leaving vulnerable outputs spendable forever, freezing certain old outputs after a migration period, requiring new proofs or creating special migration rules.
Every option has serious tradeoffs.
Leaving everything untouched preserves Bitcoin’s current ownership rules but could allow future quantum theft. Freezing vulnerable outputs could prevent theft but might permanently immobilize coins belonging to legitimate owners.
Bitcoin has not settled that governance question, and QSB does not settle it either.
What Bitcoin holders should do now
No immediate wallet action is required solely because this transaction was mined.
There is no publicly demonstrated cryptographically relevant quantum computer currently breaking Bitcoin’s secp256k1 signatures. Nobody can responsibly give Bitcoin holders a guaranteed “Q-Day” date based simply on a physical-qubit count or a vendor roadmap.
The useful conclusion is preparedness rather than panic.
- Avoid unnecessary address reuse where practical.
- Keep wallet software supported and updated.
- Use established wallet and backup practices.
- Follow Bitcoin Core and wallet-vendor guidance if a widely supported migration standard develops.
- Never enter seed phrases into online “quantum checkers.”
- Treat anyone selling an urgent QSB migration service skeptically.
For normal security today, see our secure crypto storage guide and the CryptoLinks Blockchain and Bitcoin Security section.
My conclusion: QSB changes Bitcoin’s fallback, not the migration problem
The strongest conclusion from August 26 is not that Bitcoin solved quantum computing.
It is that Bitcoin’s existing rules turned out to contain enough flexibility for an experimental hash-based authorization construction to protect and spend a specially designed output on the real mainnet.
That matters.
The choice is no longer quite as simple as “activate a post-quantum soft fork immediately or have zero possible protection.” QSB demonstrates that an emergency transaction-level escape hatch can exist within rules Bitcoin already validates.
But it also demonstrates why an escape hatch is not a mass migration plan.
Hours of GPU computation, substantial off-chain cost, a roughly 10-kilobyte locking construction, non-standard relay, miner-direct routing, experimental software and the inability to restore secrecy to already-exposed elliptic-curve keys are not properties millions of ordinary Bitcoin users should be expected to manage.
BIP-360 and purpose-built post-quantum signature work such as SHRINCS remain important precisely because Bitcoin eventually needs something that can become standard, interoperable, wallet-compatible, auditable and scalable.
I would therefore describe QSB as a resilience demonstration rather than a recommendation for ordinary cold storage today.
It proves Bitcoin may already have a quantum lifeboat.
It does not mean the ship has finished its quantum upgrade.
Frequently asked questions
What is QSB?
QSB, or Quantum-Safe Bitcoin, is Avihu Levy’s experimental method for creating and spending specially protected Bitcoin outputs using current consensus rules and hash-based security assumptions.
Did a quantum-resistant Bitcoin transaction really reach mainnet?
Yes. A QSB-protected Bitcoin output was successfully spent in block 964,199 on August 26, 2026. “Quantum-resistant” describes this specific construction, not the Bitcoin network as a whole.
What is the QSB transaction ID?
The mainnet QSB spending transaction is 305a24ffea912b9cf428f29ebf952321c96dab5bab284fc0d0801562f5abab07.
How much Bitcoin was involved?
The specially QSB-protected output contained 10,000 satoshis. Reporting on the transaction indicates the spending transaction used two inputs totaling 44,000 sats, so 10,000 sats should not be confused with the total input value.
Which Bitcoin block contains it?
Block 964,199. MARA Pool mined the block on August 26, 2026 at 20:48:34 UTC.
Did QSB require a Bitcoin soft fork?
No. This particular construction required no consensus change or new opcode. That does not mean Bitcoin will never need a soft fork for practical network-wide post-quantum migration.
Why did ordinary Bitcoin nodes not relay QSB?
Because consensus validity and mempool standardness are different. QSB can be valid inside a Bitcoin block while falling outside the default policy ordinary nodes use for public mempool relay.
What is MARA Slipstream?
MARA Slipstream provides a route for certain non-standard Bitcoin transactions to be submitted directly for mining. QSB used that route because ordinary public relay was insufficient.
Does QSB use STARK proofs or Starknet?
No. QSB operates using Bitcoin functionality and does not require STARK proofs, Starknet, STRK or a cross-chain bridge.
Can Ledger, Trezor, Coldcard or normal Bitcoin wallets use QSB?
There is no mainstream production QSB workflow for ordinary wallets today. The construction remains research-oriented and experimental.
Can QSB protect Satoshi-era Bitcoin?
It cannot restore secrecy to public keys that are already exposed once a capable quantum attacker exists. That is especially relevant to many old P2PK outputs.
Is Taproot quantum-resistant?
Taproot is secure against known practical attacks today, but its visible elliptic-curve output key creates long-exposure risk in the hypothetical presence of a sufficiently capable quantum computer.
What is BIP-360?
BIP-360 is the Draft Pay-to-Merkle-Root proposal. It proposes a new P2MR output type through a Bitcoin soft fork and removes the ordinary elliptic-curve key-path structure associated with P2TR.
Is SHRINCS live on Bitcoin?
No. SHRINCS has reached research, public-specification and Liquid-demonstration stages, but it is not an activated Bitcoin-mainnet consensus feature.
Is Bitcoin quantum-safe now?
No. Ordinary Bitcoin ECDSA and Schnorr spending paths remain elliptic-curve based. QSB demonstrated one specialized hash-based protection mechanism.
Should Bitcoin holders move their coins today?
No immediate migration is required solely because QSB was demonstrated. Holders should prioritize ordinary wallet security, avoid unnecessary address reuse and monitor future Bitcoin Core and wallet-vendor migration guidance.
CryptoLinks resources for further reading
- CryptoLinks homepage — curated Bitcoin and cryptocurrency resources
- Latest CryptoLinks cryptocurrency news
- Bitcoin Wiki and crypto learning resources
- Bitcoin Developer Guide review
- Blockchain and Bitcoin Security
- Secure Crypto Storage guide
- Best Bitcoin Mining Pools
- Crypto guides and courses
- Bitcoin and cryptocurrency guides for beginners
Sources and methodology
This analysis prioritizes primary technical and on-chain evidence. Mainnet status, scope and the miner-direct path were checked against StarkWare’s August 26 QSB announcement and the public QSB implementation. Block height, timestamp, miner and transaction inclusion were checked against Bitcoin block data. BIP-360 status was checked against the Bitcoin BIPs repository. SHRINCS status and current signature parameters were checked against its current public draft specification and Blockstream Research material. NIST post-quantum standards are used only for context and are not presented as selected Bitcoin upgrades.
Research and status cutoff: August 27, 2026. QSB, BIP-360 and SHRINCS are active areas of research and their specifications or implementation status may change after publication.