Bitcoin Tests Two Quantum-Security Paths in One Day

Key Takeaways

One transaction method and one signature proposal

How StarkWare built QSB with Bitcoin Script

A sufficiently capable quantum computer running Shor’s algorithm could derive a Bitcoin private key from its public key and forge a signature. Publicly known machines remain far below that capability. QSB explores a contingency based on hash functions, which are affected differently by known quantum algorithms.

The sender performs an intensive offchain search for parameters that satisfy a Bitcoin Script condition. Once found, those parameters create an extra hash-based lock on the coins. StarkWare’s official explanation describes the method, and the onchain transaction records the test on Bitcoin.

The first practical obstacle appeared before mining. StarkWare submitted the transaction through MARA’s Slipstream service because public nodes generally decline to relay this script format. Slipstream sends eligible transactions directly to a miner, and Bitcoin’s consensus rules accepted the result.

The search is also expensive. The project’s open-source repository estimates $75 to $150 in cloud GPU costs for its documented setup. StarkWare places the latest run at several hundred dollars. Cloud prices, hardware and search time account for some of that variation.

QSB also depends on timing. The relevant public key must remain concealed until the coins reach the extra lock. Pay-to-public-key-hash and native SegWit addresses usually reveal that key when they are spent. Taproot outputs and older pay-to-public-key outputs expose it earlier. An address whose public key was published before the protective transaction falls outside QSB’s coverage.

The announcement identifies one mined transaction. Reproducing it requires project-specific tools, significant computation and access to a miner-direct service. A standard-wallet workflow for creating and later spending the protected output has yet to be published.

SHRINCS gives Bitcoin a signature candidate

SHRINCS, short for Shrunken SPHINCS, is a signature design aimed at Bitcoin’s block-space limits and hardware-wallet constraints. Blockstream’s research overview introduces the project. Its full specification currently reads “BIP: ?,” “Status: Draft” and “Assigned: ?.” The document also marks the security proof as unfinished.

The proposed public key is 48 bytes. Stateful signatures range from 548 to 4,619 bytes, depending on the signing path. A stateless recovery signature reaches 5,777 bytes. Taproot’s Schnorr signature is 64 bytes.

An earlier SHRINCS implementation was demonstrated on Liquid in March. Liquid is a Bitcoin sidechain with its own network rules. The August specification gives reviewers a fuller proposal for Bitcoin. Bitcoin nodes currently lack SHRINCS verification code.

Why the compact signature needs a memory

Each compact SHRINCS signature consumes a fresh one-time signing slot. The wallet must record every used slot. Restoring an old device backup could roll that record backward and cause a slot to be reused. The specification warns that reuse may give an attacker enough information to forge a signature.

Dedicated hardware can maintain the counter during normal operation. A lost device or uncertain counter triggers the stateless recovery path. That path preserves access to the coins. Its 5,777-byte signature consumes considerably more block space and would increase transaction fees.

Wallet makers would have to prove that counters survive device restoration, multisignature coordination and interrupted signing. Reviewers also need to examine incompatible implementations. Independent cryptographic analysis must complete the missing proof before the scheme can advance through Bitcoin’s proposal process.

Bitcoin still needs a network plan

A network-wide plan needs three elements:

QSB: a specialized transaction method accepted by current Bitcoin nodes. SHRINCS: a candidate signature format for protocol review. BIP-361: a proposed process for moving funds away from quantum-vulnerable signatures.

In the past our team examined Bitcoin’s proposed five-year quantum migration plan under BIP-361. Its timetable depends on an approved post-quantum signature standard and output type. SHRINCS supplies one candidate for the signature component. Developers would still have to define the output, implement it, review the code and secure network support before the BIP-361 clock could begin.

QSB sits outside that proposed timetable because it uses a specialized transaction path available under today’s rules. Wide protection requires software that wallets, exchanges and custodians can support consistently.

What Bitcoin holders should do today

There is no live upgrade, supported post-quantum address format or activation date. Bitcoin wallets continue to operate normally. QSB requires research tooling. SHRINCS remains under technical review.

Treat unsolicited messages about an “urgent quantum upgrade” as suspicious. The projects publish research materials only. A message asking for bitcoin or a seed phrase is a scam warning sign. Long-term holders can ask their custodian how it tracks quantum research, public-key exposure and future wallet upgrades.

What researchers still have to prove

QSB now needs independent reproduction, security review and a complete wallet-style lifecycle. Easier access to miners would determine whether researchers can repeat the transaction beyond a one-off demonstration.

SHRINCS still needs a finished security proof, outside cryptographic analysis, a BIP assignment, deployment rules and hardware-wallet testing. Any network proposal would then enter Bitcoin’s public review and consensus-building process.

Ordinary wallet support is the threshold that matters to users. Reaching it requires reviewed cryptography, stable software and a coordinated rollout. The August 26 releases give researchers code and specifications they can now challenge in public.

The post Bitcoin Tests Two Quantum-Security Paths in One Day appeared first on Coindoo.