A quantum computer running Shor's algorithm could break Bitcoin's ECDSA signature scheme and expose millions of BTC. This is not science fiction — it is a known, dated deadline on the current security model of every Bitcoin wallet in existence. This post explains exactly why, and how the HNS Protocol gives you a way out.
Let's Start With What Bitcoin Actually Trusts
When you send Bitcoin, you prove you own it by producing a digital signature. That signature is created using your private key and verified by anyone on the network using your public key. No signature, no transaction. The scheme used to produce this signature is called ECDSA — Elliptic Curve Digital Signature Algorithm, running on a specific curve called secp256k1.
Bitcoin has trusted ECDSA since the genesis block in 2009. It works because recovering a private key from a public key requires solving the Elliptic Curve Discrete Logarithm Problem — a mathematical problem so hard that even the fastest classical supercomputers would need billions of years to crack a single key.
That sentence contains a word you should pay close attention to: classical.
The Quantum Threat: Shor's Algorithm
In 1994, mathematician Peter Shor published an algorithm that can solve the discrete logarithm problem — the very foundation of ECDSA — in polynomial time on a quantum computer. Not in billions of years. In hours, possibly minutes, on a sufficiently powerful quantum machine.
A quantum computer that runs Shor's algorithm against a Bitcoin public key does not need to brute-force anything. It exploits the mathematical structure of the elliptic curve to derive the private key directly. From public key to private key — game over.
The question is not whether this is possible. It is when the hardware will exist to do it at scale. NIST, the US National Institute of Standards and Technology, began standardising post-quantum cryptography algorithms in 2016 — and finalised the first three standards in 2024. Governments and financial institutions are already migrating. Bitcoin, by design, cannot be patched from the top down. Its users have to act.
Which Bitcoin Addresses Are at Risk — and When
Not all Bitcoin addresses face the same risk level. Understanding the attack window matters.
P2PK outputs — at risk right now
Early Bitcoin transactions used a format called Pay-to-Public-Key (P2PK), where the public key is exposed directly in the output script. Satoshi's own coins are largely in this format. These addresses expose the public key permanently on-chain. A quantum attacker with a capable machine could target them today — without waiting for the owner to ever spend.
Estimates suggest approximately 1.7 million BTC sits in vulnerable P2PK outputs. That is over $100 billion at current prices, with its public keys already visible on the blockchain.
Reused P2PKH addresses — at risk on spend
In a standard Pay-to-Public-Key-Hash (P2PKH) transaction, the public key is only revealed when you spend. Before you sign, the address is just a hash — quantum-resistant by nature, because hash functions are not broken by Shor's algorithm. But the moment you broadcast a transaction, your public key is in the mempool. A quantum attacker with a fast enough machine could derive your private key during the confirmation window — typically 10 minutes — and broadcast a competing transaction that drains your wallet before yours confirms.
This is called the transaction interception attack. It requires real-time quantum computation, which is further out — but it represents the end-game of unprotected Bitcoin spending.
P2TR (Taproot) addresses — better, but not immune
Taproot, introduced in 2021, uses Schnorr signatures and tweaked public keys. It improves privacy and efficiency but still relies on elliptic curve cryptography. Taproot gives you a larger attack window than P2PKH — the public key structure is better hidden — but it does not solve the fundamental problem. It buys time. It is not a permanent answer.
What Post-Quantum Cryptography Actually Is
Post-quantum cryptography (PQC) refers to cryptographic algorithms that are believed to be secure even against quantum computers. They don't use elliptic curves or integer factorization — the two families that Shor's algorithm destroys. Instead, they rely on mathematical problems that quantum computers do not appear to have efficient solutions for.
In 2024, NIST standardised three algorithms as the new baseline:
- CRYSTALS-Dilithium (FIPS 204) — a lattice-based signature scheme. Keys are larger than ECDSA but the math is built on problems that remain hard even for quantum machines. This is the general-purpose recommendation for most applications.
- FALCON (FIPS 206) — also lattice-based, with significantly more compact signatures. Harder to implement correctly but powerful where bandwidth matters.
- SPHINCS+ (FIPS 205) — hash-based signatures. The most conservative choice: its security depends only on hash functions, which we have far more confidence in than any new lattice assumption.
The trade-off is size. A Dilithium3 public key is 1,952 bytes. A secp256k1 public key is 33 bytes. Bitcoin's block size and fee structure were designed around the latter. You cannot simply swap in a PQC signature scheme and call it done. You need a migration protocol.
The HNS Protocol: A Two-Phase Migration Path
The Hybrid Name-Space (HNS) Protocol is a structured migration framework for binding post-quantum identities to existing Bitcoin addresses — before a quantum attack becomes possible, and without requiring any changes to Bitcoin's consensus rules.
It works in two phases: Anchor and Bind.
Phase 1 — Anchor: Commit Your PQ Key On-Chain
Before anything else, you generate a post-quantum key pair — for example, a Dilithium3 keypair. You then compute the SHA-256 hash of your PQ public key. This 32-byte hash is embedded into a Bitcoin transaction as an OP_RETURN output.
OP_RETURN outputs are provably unspendable data carriers. Bitcoin allows up to 80 bytes in an OP_RETURN output, which is exactly enough room for our commitment. The payload structure is:
Bytes 0–3: HNS magic prefix (0x484E5301 = "HNS\x01")
Bytes 4–35: SHA-256(PQ_pubkey) (32 bytes — the anchor commitment)
Bytes 36–55: SHA-256(btc_address) truncated to 20 bytes
Bytes 56–59: Network ID + version flags
Total: 60 bytesThis transaction does two critical things. First, it creates an immutable, timestamped, on-chain record that you held this PQ key at this point in time. Second, it links that PQ key to your Bitcoin address — publicly and permanently, on the most censorship-resistant ledger that exists.
The anchor does not move any funds. It does not require revealing your private key. It just says: "The owner of this Bitcoin address also holds this PQ key, as of this block."
Phase 2 — Bind: Prove PQ Ownership
After anchoring, you produce a post-quantum signature over a canonical binding message:
HNS/v1/bind/{network}/{btc_address}/{pq_pubkey_hash_hex}This signature — produced by your Dilithium3 private key — is stored in the HNS Registry alongside your full PQ public key. The registry can be IPFS-based (censorship-resistant, content-addressed), an L2 sidechain, or a local database for offline use.
The bind step proves that the entity holding the PQ private key is the same entity that created the anchor transaction. Anyone can verify this: take the PQ public key from the registry, check the bind signature, then verify that the SHA-256 of that public key matches the anchor payload on-chain. The chain of cryptographic proof is complete.
On-chain: SHA-256(PQ_pubkey) in OP_RETURN (block 900,000)
Off-chain: Full PQ_pubkey + Dilithium3 signature over bind message
Verification:
1. Fetch anchor TX from blockchain
2. Extract pq_pubkey_hash from OP_RETURN
3. Fetch PQ_pubkey from HNS Registry
4. Verify: SHA-256(PQ_pubkey) == pq_pubkey_hash ✓
5. Verify: Dilithium3.verify(bind_message, bind_sig, PQ_pubkey) ✓
6. Conclusion: PQ key owner is the proven owner of this BTC addressThe Migration: Sweep to Safety
Once your PQ identity is anchored and bound, you have a complete, verifiable claim to your Bitcoin address that does not rely on ECDSA. When the quantum threat materialises — whether that is two years or ten years from now — you can broadcast a sweep transaction moving your funds to a new Taproot address secured by a PQ key commitment, long before an attacker can derive your private key.
The sweep transaction is a standard Bitcoin transaction, signed with your classical ECDSA key as normal. What has changed is that the destination is now a P2TR address whose spending condition is bound to a PQ key — and the world already knows, from your anchor TX, exactly which PQ key that is.
Why Handshake Domains Belong in This Protocol
Here is where the HNS Protocol connects to Handshake in a way that goes beyond the name.
The HNS Registry — the off-chain component where PQ public keys and bind signatures are stored — needs to be permanent, censorship-resistant, and publicly verifiable. A centralised server fails that test. IPFS alone has no human-readable addressing. ENS .eth subdomains are not owned at the root. All of the same problems that make centralised DNS inadequate for property NFTs, vehicle identities, and music tokens apply here too.
A Handshake TLD — for example, quantum.btc/ or shield.btc/ — can serve as the root of a fully sovereign HNS Registry namespace. Every registered Bitcoin address gets its own second-level entry under that TLD. The bind record lives in a DNS TXT record on the Handshake chain, content-addressed and verifiable by any HNS resolver without contacting a centralised API.
bc1q...xyz.shield.btc/— HNS Registry entry for a Taproot address, TXT record contains PQ pubkey hash and bind signature IPFS CID.anchor.bc1q...xyz.shield.btc/— Links to the on-chain OP_RETURN anchor TX ID.status.bc1q...xyz.shield.btc/— Current HNS lifecycle status: pending / anchored / bound / migrated.
The TLD owner controls the namespace. The entries are issued as NFTs on the HNS chain. The registry is publicly readable, permanently archivable on Arweave, and immune to the takedown orders and registrar failures that make centralised alternatives inadequate for a cryptographic security protocol.
Handshake's model — where the root is owned permanently, by a key, with no annual fee and no revocation mechanism — is precisely what a quantum-migration infrastructure needs. You are not asking a certificate authority to vouch for you. You are anchoring your identity in the same way Bitcoin anchors transactions: by writing it to a chain that no single authority controls.
The Timeline: How Urgent Is This?
The cryptographically relevant quantum computer — one large and stable enough to run Shor's algorithm against a 256-bit elliptic curve key in practical time — does not exist today. Current quantum hardware operates in the range of hundreds to low thousands of physical qubits, and breaking secp256k1 is estimated to require somewhere between 1,500 and 4,000 logical qubits (each logical qubit requiring many physical qubits for error correction).
But the migration timeline matters more than the attack timeline. Consider:
- The anchor transaction is cheap and can be done today, in minutes, at the cost of a standard Bitcoin fee.
- Bitcoin transactions are irreversible. Once your ECDSA private key is cracked and your funds are stolen, there is no recourse.
- NIST's post-quantum standards are finalised. The algorithms are ready. The tools exist.
- Any address with a public key already exposed on-chain — P2PK, reused P2PKH — has zero additional warning time when quantum hardware matures.
The standard advice from cryptographers is to migrate now, not when the threat arrives. The HNS Protocol is designed for exactly that: a low-cost, non-invasive commitment you make today, that gives you provable PQ ownership when the moment comes.
Step-by-Step: What the Migration Looks Like in Practice
Here is the full journey from a vulnerable classical wallet to a quantum-safe HNS-bound identity.
Step 1 — Generate your PQ keypair offline. Use a NIST-standardised implementation of Dilithium3. Keep the private key on an air-gapped machine or hardware security module. Back it up with the same rigour you apply to your ECDSA seed phrase.
Step 2 — Compute your anchor payload. Calculate SHA-256 of your PQ public key. Construct the 60-byte OP_RETURN payload using the HNS magic prefix, your PQ key hash, and a truncated hash of your Bitcoin address.
Step 3 — Broadcast the anchor transaction. Create a Bitcoin transaction with one output: an OP_RETURN output carrying your payload, and one change output returning the remainder to yourself. Broadcast it to the network. Record the TXID.
Step 4 — Produce the bind signature. On your air-gapped machine, sign the canonical bind message with your Dilithium3 private key. The bind message encodes your Bitcoin address, your PQ key hash, and the network identifier.
Step 5 — Publish to the HNS Registry. Upload your full PQ public key, your TXID, and your bind signature to IPFS. Register the IPFS CID in a DNS TXT record on your Handshake domain. Your HNS identity is now publicly verifiable and quantum-safe.
Step 6 — When it's time, sweep. Generate a new P2TR address bound to a fresh PQ key. Broadcast a standard transaction sweeping your funds from the old address to the new one. The world can verify, from your anchor TX and bind record, that you are the legitimate owner making this sweep — not a quantum attacker.
A Note on What This Is Not
The HNS Protocol is not a change to Bitcoin's consensus rules. It does not require a soft fork, a hard fork, or any cooperation from miners, node operators, or other participants. It is a layer built on top of what Bitcoin already supports — OP_RETURN data outputs, standard transactions, and deterministic key derivation.
It is also not a complete replacement for ECDSA. Until Bitcoin itself adds native PQC signature verification (which would require a coordinated protocol upgrade), the HNS Protocol functions as a commitment and claim system — proving, in an auditable and cryptographically verifiable way, that you made your PQ ownership claim before a quantum attack occurred.
The strength of this system lies in its simplicity. A hash in an OP_RETURN output is permanent and cheap. A Dilithium3 signature is verifiable by anyone with an open-source library. The Handshake chain is public, uncensorable, and permanent. Put them together and you have an identity layer for Bitcoin that survives the quantum transition — regardless of how slow or fast the protocol itself evolves.
Frequently Asked Questions
What is Shor's algorithm and why does it threaten Bitcoin?
Shor's algorithm is a quantum computing algorithm published in 1994 that can efficiently solve the mathematical problems underlying both RSA encryption and elliptic curve cryptography — including secp256k1, the curve Bitcoin uses. A quantum computer running Shor's algorithm against an exposed Bitcoin public key can derive the corresponding private key, allowing an attacker to steal funds from that address. Classical computers cannot do this; quantum hardware operating at sufficient scale can.
How many Bitcoin are currently at risk?
Estimates vary, but researchers have identified approximately 1.7 million BTC in P2PK outputs — where the public key is permanently visible on-chain — as directly vulnerable to a future quantum attack without any additional exposure required. A much larger portion of the supply is in P2PKH or P2TR addresses where the public key is revealed on spend, creating a narrower but still real attack window during transaction broadcast.
What is the HNS Protocol?
The HNS Protocol (Hybrid Name-Space Protocol) is a two-phase commit-and-claim system for migrating Bitcoin ownership to post-quantum keys. In Phase 1, you commit a hash of your PQ public key to the Bitcoin blockchain via an OP_RETURN output. In Phase 2, you sign a canonical binding message with your PQ private key and publish the full record to a decentralised registry — preferably anchored to a Handshake TLD for permanent, censorship-resistant storage. Together these two steps create an auditable, quantum-safe chain of ownership over your Bitcoin address.
Which post-quantum algorithm should I use?
For most users, CRYSTALS-Dilithium3 (FIPS 204) is the recommended choice. It is the general-purpose NIST standard, well-studied, with good performance and multiple open-source implementations. FALCON-512 offers smaller signatures at the cost of a more complex and error-prone implementation. SPHINCS+-SHA256-128f is the most conservative option — its security rests entirely on hash function assumptions — but it produces very large signatures (17 KB) that are impractical for many use cases.
Does this require a Bitcoin protocol change?
No. The HNS Protocol operates entirely within Bitcoin's current rules. OP_RETURN outputs are already supported in the protocol and have been used for data anchoring since 2014. The anchor transaction is a valid standard transaction. No consensus change, soft fork, or miner cooperation is required. The protocol is a layer on top of Bitcoin, not inside it.
Why does this need Handshake domains?
The off-chain binding record — containing your full PQ public key and bind signature — needs to be stored somewhere permanent, public, and censorship-resistant. A centralised server can go offline. IPFS content without naming is not discoverable. A Handshake TLD provides a sovereign root under which every registered address gets a permanent, human-readable, on-chain entry. The same properties that make Handshake the right home for property NFTs, vehicle identities, and music tokens make it the right home for a quantum-migration registry: you own the root, no one can take it down, and it resolves globally without a gatekeeper.
The Bottom Line
Bitcoin's security model is based on mathematics. For sixteen years, that mathematics has been unbreakable in practice. Quantum computing does not break the mathematics — it solves it. That is a different kind of threat: not a flaw in the design, but a change in what hardware is capable of.
The HNS Protocol does not fight this change. It anticipates it. An anchor transaction today costs a few dollars in fees and takes ten minutes. A Handshake domain registration is permanent and gives your PQ identity a sovereign, globally verifiable home. A Dilithium3 keypair is generated in milliseconds with open-source tools that exist right now.
The quantum transition will not announce itself. The window between "a capable machine exists" and "someone points it at P2PK outputs" could be very short. The HNS Protocol is the migration you do before that window opens — not after.
Your Bitcoin is worth protecting. The tools to protect it are ready. The blockchain that makes the protection permanent is the same one you have been building on: Handshake.
Technical architecture and original protocol design by NIHON — Handshake Infrastructure & Web3 Identity, June 2026. The BTC-Quantum-Shield open-source repository implementing the HNS Protocol in Python is available at github.com/your-org/btc-quantum-shield. For more on building with Handshake, explore LearnHNS.