Quantum safe bitcoin: defending Btc from quantum attacks without a protocol fork

There’s a growing concern in the Bitcoin world that quantum computers, once powerful enough, could tear through the cryptography that secures the network today. Now, a new research proposal claims Bitcoin can be hardened against that threat-without touching the core protocol or requiring a fork.

Avihu Mordechai Levy, a researcher at StarkWare, has outlined a transaction design he calls “Quantum Safe Bitcoin” (QSB). The idea is bold: use only the tools that Bitcoin already supports-no new opcodes, no consensus changes-and still make transactions secure even in a world where Shor’s algorithm runs on real, large-scale quantum machines.

In his paper, Levy argues that QSB can keep Bitcoin funds safe even if elliptic-curve cryptography (ECC)-the backbone of Bitcoin’s current signature scheme-is fully broken by quantum computers. Instead of relying on ECC-based signatures like ECDSA or Schnorr, QSB swaps them out at the transaction layer for hash-based cryptography and Lamport-style signatures, one of the earliest and most studied post-quantum signature constructions.

Crucially, this is all done within Bitcoin’s existing scripting capabilities. The scheme is designed so that nodes and miners would see valid Bitcoin scripts and standard transactions. No soft fork, hard fork, or protocol upgrade is required; the network doesn’t need to “know” that the transaction is quantum-safe. It just needs to validate it according to the rules it already enforces.

How the threat works today

Bitcoin’s security relies on two related ideas: hashing and public-key cryptography. Hashes (like SHA-256) are believed to be relatively robust against quantum attacks, at least compared to public-key systems. The weak spot is the elliptic-curve signatures that prove ownership of coins.

If a powerful quantum computer can run Shor’s algorithm at scale, it could derive a private key from a public key in a practical timeframe. For Bitcoin, that matters most in two scenarios:

– When coins are sent from an address, the public key is revealed in the transaction.
– Older “pay-to-pubkey” outputs (common in the early days of Bitcoin) already expose public keys on-chain.

In a quantum-capable future, any funds tied to known public keys could be stolen if their owners don’t move them to safer outputs in time. That’s why researchers and developers have been exploring post-quantum signature schemes and, in some cases, entirely new protocols.

Why avoiding a fork matters

Upgrading the cryptography of a global monetary network is not trivial. A hard fork, which changes the rules in an incompatible way, risks splitting the chain and fragmenting liquidity. Even a soft fork, which tightens rules in a backward-compatible manner, requires broad consensus, careful engineering, and years of coordination.

Levy’s proposal tries to sidestep that complexity. QSB is intentionally designed as a “layer 0.5” solution: it lives inside the existing scripting and transaction language without altering how consensus is reached. In other words, the Bitcoin protocol remains exactly as it is, while users who care about quantum resistance can start using new, more complex locking scripts.

That approach has two major advantages:

– It can be deployed unilaterally by wallets and users who choose to adopt it.
– It doesn’t force the rest of the ecosystem to upgrade at the same time.

From elliptic curves to hash-based signatures

At the core of QSB is a switch from elliptic-curve signatures to hash-based and Lamport-style signatures. Lamport signatures rely only on one-way functions (hashes), which are far more resistant to known quantum attacks than discrete-log or factoring-based systems.

In a simplified view, Lamport signatures work roughly like this:

– A private key is a large set of random values.
– The public key is obtained by hashing those values.
– To sign a message, you reveal specific pieces of the private key corresponding to bits of the hashed message.
– The verifier checks that the revealed pieces hash to the correct parts of the public key.

This structure has two major properties:

– It is believed to be secure even against an adversary with a large quantum computer, as long as the underlying hash function remains unbroken.
– It is “one-time use”: reuse of the same Lamport key for multiple signatures leaks information and undermines security.

That one-time nature is a serious constraint, but Bitcoin’s UTXO model already aligns fairly well with single-use semantics: each output is usually spent once. QSB leverages this: each output can embed a Lamport- or hash-based structure that allows exactly one secure quantum-safe spend.

Fitting QSB into Bitcoin’s current script

Bitcoin Script is intentionally restrictive. It doesn’t have loops, is not Turing-complete, and is heavily optimized for simple spending conditions like “prove you know the private key that matches this public key” or “multiple signatures must approve this transaction.”

Levy’s QSB shows how to construct scripts that emulate hash-based, one-time signatures using existing opcodes such as:

– OP_HASH256 and related hash operations
– OP_EQUAL and OP_VERIFY for equality checks
– Basic stack manipulation and conditional logic

The general idea is:

1. The locking script (scriptPubKey) of an output contains commitments to a “public key” in the Lamport sense-essentially a collection of hashed values.
2. When spending the output, the unlocking script (scriptSig/witness) reveals the corresponding preimages (the secret values).
3. The script verifies that the hashes of those revealed values match what was originally committed in the locking script, and that they correctly correspond to the message or transaction being signed.

Because all of this is done with hash and comparison operations that Bitcoin nodes already support, the network doesn’t need any changes. Nodes simply see a more complex script and verify it as normal.

Security “against Shor’s algorithm”

Shor’s algorithm is the main existential threat to ECC-based systems. If a quantum computer can run Shor’s algorithm at huge scale, it can crack ECDSA and Schnorr signatures, making today’s Bitcoin addresses vulnerable.

Levy emphasizes that QSB is designed to remain secure “even in the presence of Shor’s algorithm.” That claim rests on two assumptions:

– The security of Bitcoin’s hash functions (e.g., SHA-256) remains intact or at least only partially weakened by quantum algorithms like Grover’s, which offer quadratic speedups but don’t fully break the scheme.
– The Lamport-style signatures and hash-based constructions are implemented carefully, avoiding key reuse and ensuring sufficient entropy and parameter sizes.

If those assumptions hold, an attacker with a quantum computer could not simply derive the private data from the public commitments in a QSB transaction the way they could with traditional elliptic-curve public keys.

Trade-offs: size, complexity, and usability

QSB is not free. Replacing compact elliptic-curve signatures with hash-based or Lamport-style signatures has notable downsides:

– Larger transactions: Lamport signatures can be quite bulky. Even optimized variants are far larger than ECDSA or Schnorr signatures. That means QSB-enabled transactions would likely consume more block space and pay higher fees.
– One-time keys: The one-time nature of the scheme requires careful wallet design. Reusing keys can degrade security, so wallets must manage key material more aggressively and ensure each output uses fresh data.
– More complex scripts: While still valid under current rules, the scripts are more involved than standard pay-to-pubkey-hash or pay-to-witness-pubkey-hash. That adds complexity for wallet developers and may reduce compatibility with some tools until they are updated.

Despite those trade-offs, Levy’s work suggests that, as a transitional or optional security layer for high-value holdings, QSB could be appealing. Large holders might accept fatter transactions and higher fees in exchange for significantly greater resilience against a hypothetical quantum attacker.

What this means for existing Bitcoin addresses

One of the open questions in any quantum-safe migration is what happens to existing coins, especially those with exposed public keys. Many long-dormant addresses, including some believed to belong to early miners and possibly Satoshi Nakamoto, are in formats that reveal public keys on-chain.

QSB, by itself, does not magically protect these addresses. Quantum-safe protection requires funds to be moved into outputs that use the QSB-style scripts. In practice, that means:

– Users who are concerned about quantum threats would need to send their coins to new, QSB-enabled addresses.
– Any unspent outputs using traditional public-key scripts would remain vulnerable if quantum computers become practical before their owners migrate.

However, because QSB requires no change to the protocol, migration could be done gradually, without waiting for ecosystem-wide consensus on a fork or a mandatory upgrade. Wallets could start offering “quantum-safe” destination addresses as an option well before the threat becomes imminent.

Implications for other blockchains

Although Levy’s proposal is explicitly focused on Bitcoin, the underlying concept-emulating post-quantum signatures inside existing scripting systems-has broader relevance. Any blockchain that supports sufficiently expressive scripts and robust hashing could, in principle, implement similar constructions.

However, Bitcoin’s UTXO model and relatively conservative script actually make it a particularly clean fit for one-time, hash-based signatures. Account-based systems and smart contract platforms may require different approaches or more complex tooling to achieve the same guarantees.

Why research like this matters now

Most experts agree that practical, large-scale quantum computers capable of running Shor’s algorithm on Bitcoin’s key sizes do not yet exist. Estimates for “when” vary widely, from decades away to unlikely within this century. But cryptographic transitions in global systems move slowly.

History shows that moving from one cryptographic primitive to another-whether in web security, messaging, or payments-can take many years, even after the new tools are standardized and available. For a system as decentralized and politically sensitive as Bitcoin, waiting until quantum computers are obviously imminent would be risky.

Research like QSB serves multiple purposes:

– It demonstrates that quantum-safe designs are already possible using today’s rules.
– It gives wallet developers and infrastructure providers a concrete blueprint for experimentation.
– It opens a path for voluntary, bottom-up adoption instead of top-down, contentious upgrades.

Not the final word on Bitcoin and quantum

QSB is not a comprehensive solution to all quantum-related risks, nor is it the only approach being explored. Other researchers are investigating entirely new signature schemes, alternative key structures, and protocol-level changes that might, one day, be proposed as network upgrades.

There are also broader uncertainties: the real timeline of quantum hardware development, the viability of new cryptographic assumptions, and the economic incentives that will drive or delay adoption of post-quantum protections.

What QSB shows, however, is that Bitcoin is not locked into its current cryptography by design. Even without a fork, the existing scripting language is powerful enough to host quantum-resistant transaction patterns today, for users willing to pay the overhead.

A quantum-aware future for Bitcoin

If Levy’s ideas gain traction, the Bitcoin ecosystem could see a gradual emergence of “quantum-aware” wallets and services. High-security custody providers, institutional holders, and long-term savers could be the first to adopt QSB-style outputs, treating them as a premium security layer for assets that may remain untouched for many years.

Over time, as quantum computing research advances and the risk picture becomes clearer, broader adoption could follow-still without forcing a disruptive protocol-level change. In that sense, QSB acts as a bridge: a way to start hardening Bitcoin against a distant but serious threat, using only the tools that are already in every node today.