On August 26, 2026, StarkWare reported that a QSB transaction had been mined on Bitcoin mainnet without changing Bitcoin’s consensus rules. The report concerns a construction—not a network-wide change—that places particular bitcoin outputs behind an additional hash-based condition while retaining Bitcoin’s existing elliptic-curve authorization.
Using currently accepted rules, a sender can move coins into a specially constructed output with this more narrowly scoped protection. QSB therefore does not make the Bitcoin network universally quantum-resistant, replace Bitcoin’s signature system, or retroactively protect all coins.
What StarkWare’s quantum-safe Bitcoin transaction actually changed
Bitcoin transactions normally rely on elliptic-curve cryptography to establish who may spend an output. QSB adds a separate hash-based lock, making spending depend on a condition designed to rest on the difficulty of reversing a hash rather than solely on recovering a private key. A holder moves coins into a hash-dependent output and later uses the method to spend that output.
According to StarkWare’s announcement, that construction was used in a Bitcoin mainnet transaction without changing Bitcoin consensus rules or requiring nodes and miners to validate a new signature algorithm. Its backward compatibility is limited to existing consensus accepting the transaction; QSB is not a blanket security upgrade for every address or unspent output.
The quantum threat targets exposed elliptic-curve public keys
QSB addresses a defined quantum risk: Bitcoin’s elliptic-curve signatures are vulnerable in principle to Shor’s algorithm, which could allow a sufficiently capable quantum computer to derive a private key from an exposed public key. This is a threat to conventional public-key authorization’s mathematical foundation, not evidence that quantum computers can immediately seize every bitcoin.
Its protection depends on timing and output type. StarkWare says already exposed public keys are outside the method’s protection; coins must instead be moved into a QSB-style, hash-dependent output. The construction places a hash-based lock alongside Bitcoin’s existing elliptic-curve authorization, rather than making Bitcoin universally quantum-safe or replacing its cryptographic design.
That targeted approach fits the broader post-quantum landscape. The National Institute of Standards and Technology lists hash-based signatures, including SLH-DSA, among its post-quantum cryptography standards and warns that quantum computing threatens many widely used public-key systems. QSB’s potential usefulness lies in that hash-dependent spending condition, not in a wholesale redesign of Bitcoin’s cryptography.
How signature grinding turns a transaction hash into a second lock
The unusual part of QSB comes when the protected output is spent. The sender does not produce an ordinary elliptic-curve signature in the usual way for this component. Instead, the sender searches off-chain for a transaction whose hash can be accepted as a validly formatted Bitcoin signature.
This search process is known as signature grinding. The sender varies transaction details and hashes candidate transactions until finding one that satisfies the required signature-format rules. Once a satisfactory candidate is found, the transaction can be submitted for mining.
A simplified sequence looks like this:
- A holder moves bitcoin into an output incorporating the hash-dependent QSB condition.
- When spending, the holder constructs candidate transactions off-chain.
- The holder repeatedly hashes candidates, searching for a result that meets Bitcoin’s signature-format requirements.
- The successful transaction is sent for mining and, once confirmed, spends the protected output.
The security premise is hash preimage resistance: an attacker should not be able to work backward from the relevant hash value to obtain the required input. The associated QSB research paper describes the construction in those terms and says it modifies Binohash by replacing its non-quantum-safe component with a hash-to-signature puzzle.
That differs from simply attaching a second conventional key to an output. The additional condition is arranged so that the transaction hash itself serves a role in satisfying Bitcoin’s existing signature-format expectations. The result is clever precisely because it works within the rule set already deployed, but that compatibility comes with a substantial computational burden.
Why the transaction reached mainnet without a soft fork
A soft fork changes the set of transaction forms that upgraded nodes treat as valid, while remaining compatible with older nodes in a defined way. QSB did not require that process for its mainnet demonstration because the resulting transaction was accepted under existing consensus rules.
Consensus acceptance and ordinary network propagation are not the same thing, however. StarkWare says the QSB transaction format is nonstandard and required a direct mining route rather than normal network relay. In practical terms, a sender could not assume that standard transaction relay channels would carry the transaction through the network in the same manner as a conventional payment.
That separates the roles of the main participants. The sender performs the costly off-chain search. A miner willing and able to receive the transaction directly can include it in a block. Bitcoin’s consensus rules then determine whether the block and transaction are valid. The proof of construction established that these pieces could work together on mainnet; it did not establish frictionless wallet support, standard mempool relay, or broad mining availability.
Which coins QSB can protect—and which it cannot
QSB can apply to coins that are deliberately moved into the new hash-dependent output. The timing of that move matters because the approach is aimed at avoiding reliance on an elliptic-curve public key that has already been exposed under the transaction’s threat model.
It cannot protect addresses whose public keys were previously exposed, according to StarkWare. Nor does the existence of one mined QSB transaction alter the security properties of bitcoin that remain in ordinary outputs. A holder must take the specific action of moving eligible coins into the construction before receiving its intended protection.
The more immediate practical limitation is computation. The open-source implementation by Avihu Levy describes signature grinding as requiring substantial computation. This is not comparable to generating a routine signature in a wallet. The sender must search for a transaction hash with the needed characteristics, and the cost of that search constrains routine use.
The direct-mining requirement adds another operational constraint. Even if a user can perform the search, they need an available route to a miner for a nonstandard transaction. QSB thus demonstrates an available construction under present rules, rather than a plug-and-play spending method for the average Bitcoin wallet user.
Official announcement graphic for the first quantum-safe Bitcoin transaction mined on mainnet without a soft fork. — Source: StarkWare
QSB versus a protocol-level quantum migration such as BIP 360
QSB and a protocol proposal such as BIP 360 address related concerns at different layers. QSB is a workaround built from existing consensus behavior: it creates a particular kind of output and uses off-chain grinding to form a spend that Bitcoin can accept today.
BIP 360, by contrast, proposes Pay-to-Merkle-Root as a new soft-fork output type. The proposal is intended to support quantum-resistant script trees and reduce exposure to future attacks on elliptic-curve cryptography. Because it would introduce a protocol-level output type, it depends on the Bitcoin ecosystem’s process for considering and activating soft forks.
The comparison is not one of competing claims that Bitcoin is already or not yet “quantum safe.” They solve different implementation problems. QSB demonstrates that selected coins can receive a hash-based layer without a consensus change, at the cost of expensive computation and nonstandard transaction handling. A protocol-level migration would seek more systematic support, but would require agreement on new rules and deployment.
StarkWare’s mined transaction is consequently best read as evidence about construction feasibility. The underlying risk remains the prospective ability of a sufficiently capable quantum computer to exploit exposed elliptic-curve public keys through Shor’s algorithm. The demonstration provides one way to protect certain newly moved outputs against that particular concern, not a completed migration for Bitcoin as a whole.
Frequently Asked Questions
Did StarkWare make all Bitcoin quantum-resistant?
No. The QSB construction protects only coins moved into its hash-dependent output and does not change Bitcoin’s consensus rules or the security of all existing outputs.
What is signature grinding in the QSB method?
It is an off-chain search for a spending transaction whose hash meets Bitcoin’s signature-format requirements. The search is computationally intensive under the currently described implementation.
Why is an exposed public key relevant to quantum risk?
QSB does not protect keys that were already exposed: if a sufficiently capable quantum computer existed, Shor’s algorithm could, in principle, derive a private key from an exposed elliptic-curve public key.
Did the QSB transaction require a Bitcoin soft fork?
No: it was mined under existing consensus rules. Its format was nonstandard, however, so it required a direct route to a miner rather than ordinary network relay.
How does QSB differ from BIP 360?
QSB is a transaction-level construction using present rules. BIP 360 proposes a soft-fork output type, Pay-to-Merkle-Root, intended to support quantum-resistant script trees at the protocol level.
