Bitcoin is the longest-running deployment of public-key cryptography on the internet. Every Bitcoin transaction relies on ECDSA or Schnorr signatures over the secp256k1 elliptic curve. Both of these schemes are broken by Shor's algorithm, the quantum algorithm that solves discrete logarithm problems efficiently on a sufficiently large quantum computer. So when people ask "is Bitcoin quantum-safe," the answer is no, but the more useful question is which Bitcoin holdings are at risk and which are still protected.
This article walks through the script types Bitcoin uses for outputs, what each one reveals on chain, and how the various ages of Bitcoin coins map to different levels of quantum exposure. Some Bitcoins are sitting on chain with their public keys fully visible right now. Others are protected behind hashes that buy users time to migrate before quantum threats become real.
The Core Quantum Problem
Bitcoin uses ECDSA signatures over secp256k1 for traditional transactions and Schnorr signatures over secp256k1 for Taproot transactions. Both ECDSA and Schnorr produce signatures that contain enough information for a verifier to reconstruct the public key (in Bitcoin, the public key is included in the spending data, not derived from the signature alone, but the math is closely related).
The quantum threat is concrete: Shor's algorithm, run on a sufficiently large quantum computer, derives the private key from the public key in polynomial time. Once a quantum adversary has the public key, the private key is recoverable. They can then sign a transaction that moves the funds.
The window of opportunity for a quantum adversary depends on whether the public key is on chain. If only a hash of the public key is on chain, the adversary cannot run Shor's algorithm directly: hashes are protected against Grover's algorithm with reasonable margin (Grover only halves the security of a hash function, so SHA-256 still gives 128 bits of post-quantum security, which is adequate). But if the public key itself is on chain, the adversary can start computing immediately, with no need to wait for a transaction.
This is why Bitcoin script types matter so much for quantum risk.
P2PK: Pay-to-Public-Key
The original Bitcoin script type, used for the first thousands of blocks, was P2PK. The locking script for a P2PK output looks like:
The full public key sits on chain, in plain view. To spend the output, the spender provides a signature; the script verifies the signature against the public key embedded in the script.
Many of Satoshi's coinbase outputs from 2009 and 2010 are P2PK outputs. They are still unspent, holding well over 1 million BTC across thousands of addresses. These coins represent the largest known reservoir of quantum-vulnerable Bitcoin. A quantum adversary who can break secp256k1 can spend these coins immediately, without needing to wait for a transaction or harvest data from the network.
P2PK is no longer used for new outputs. Modern wallets use P2PKH, P2WPKH, or P2TR (Taproot). But the historical P2PK outputs cannot be retroactively changed; they remain on chain in their original form unless and until they are spent.
P2PKH: Pay-to-Public-Key-Hash
P2PKH (and its segregated-witness equivalent, P2WPKH) hashes the public key before putting it on chain. The locking script for P2PKH is:
OP_DUP OP_HASH160
The pubkey-hash is RIPEMD-160 of SHA-256 of the public key, which is what Bitcoin addresses encode. The address represents only the hash, not the public key itself.
When you receive Bitcoin to a P2PKH address, the public key is not on chain. A quantum adversary watching the chain sees only the hash. To spend the output, the owner provides their public key in the spending transaction (along with a signature), at which point the public key is revealed on chain.
This creates a clean threat model:
- UTXOs that have never been spent: protected by the hash, quantum-safe in the harvest-now-decrypt-later sense
- UTXOs that have been spent (or where the address has been reused): public key is on chain, vulnerable to a future quantum adversary
Address reuse, which is common despite years of advice against it, undermines the hash protection. If you receive Bitcoin twice to the same address, the second receipt's public key was revealed when you spent the first one.
For more on the cross-chain context, see our Ethereum and quantum detail article.
P2SH and P2WSH: Script Hash
P2SH and P2WSH wrap arbitrary scripts behind a hash. The locking script puts a hash on chain, and the spending data reveals the actual script, which then runs to validate the spend. P2SH was originally used for multisig (2-of-3, 3-of-5, etc.) before Taproot subsumed many of these use cases.
For multisig wallets, P2SH means the public keys of all participants are revealed when the output is spent. So multisig outputs are quantum-protected until they are spent, after which all the public keys involved are exposed. This is mostly a concern for cold-storage hardware wallet setups using 2-of-3 schemes.
P2TR (Taproot)
Taproot, activated in November 2021 (BIP 340, BIP 341, BIP 342), introduces a more compact and private output type. P2TR outputs are 32 bytes, encoding an x-only public key on secp256k1. The locking script is essentially:
OP_1 <32-byte tweaked pubkey>
When the output is spent via the key path (a Schnorr signature on the joint key), only the signature appears on chain. When spent via the script path, the relevant script branch is revealed.
For quantum risk, P2TR is interesting because the public key is on chain in the locking script. Unlike P2PKH, where only the hash is published, P2TR publishes the (tweaked) public key directly. This means Taproot outputs have the same quantum-exposure profile as P2PK: their public keys are visible from the moment funds are received.
This was a deliberate design trade-off. Taproot enables key-path spends that look like simple signatures, providing better privacy and lower transaction fees. But it does so at the cost of revealing the public key on chain. The Taproot designers were aware of this and considered the trade-off acceptable because (a) Bitcoin will need a hard fork to migrate to post-quantum signatures anyway, and (b) the privacy and fee benefits of Taproot outweigh the concern in the short term.
The implication is that all funds in P2TR addresses are quantum-vulnerable from the moment they are received, not just when they are spent. This is one reason some long-term Bitcoin holders have stayed on P2WPKH instead of migrating to Taproot.
How Much Bitcoin Is at Risk?
Various researchers have analyzed the Bitcoin UTXO set to estimate quantum exposure. The estimates vary based on definitions, but a few observations are widely accepted:
Roughly 25 percent of all Bitcoin (around 5 million BTC) sits in addresses where the public key is currently on chain. This includes P2PK outputs (mostly old and dormant), P2TR outputs (newer, growing), and reused P2PKH/P2WPKH addresses that have already been spent from.
The remaining 75 percent (or so) sits in P2PKH or P2WPKH outputs that have not yet revealed their public keys. These are protected by the hash, which is quantum-safe in the sense that Grover's algorithm only halves the security parameter.
These percentages shift with each transaction. As Taproot adoption grows, more BTC moves into addresses where the public key is on chain. As cold-storage holders migrate to fresh addresses, the exposed share fluctuates.
The dormant P2PK outputs from 2009-2010 are the most striking case. Several hundred thousand BTC, including most of Satoshi's mining rewards, are sitting on chain with their public keys visible right now. A quantum adversary who can break secp256k1 can move these coins on Q-day. Whether they actually do, and what happens to the price if they do, is a major open question.
The Migration Problem
Migrating Bitcoin to post-quantum signatures requires a soft fork or hard fork that adds new opcodes for post-quantum signature verification. The leading candidates are ML-DSA (lattice-based, NIST FIPS 204) and SLH-DSA (hash-based, NIST FIPS 205). Our ML-DSA versus SLH-DSA article compares the two.
ML-DSA signatures are around 2420 bytes (ML-DSA-44), much larger than the ~64-byte ECDSA signatures Bitcoin uses today. SLH-DSA signatures are even larger (7856 bytes for SLH-DSA-128s). Both increase block sizes substantially. This is a real cost: Bitcoin's block size limit is finite, and bigger signatures mean fewer transactions per block.
Soft-fork proposals would add new script versions for post-quantum signatures, leaving classical Bitcoin scripts intact. New addresses would use post-quantum scripts; old addresses would remain on classical signatures. Users could migrate at their own pace.
The hard part is what to do about the exposed public keys (P2PK outputs, reused addresses, Taproot outputs that have not been moved). Those keys are already harvested, in a quantum sense. A migration window where users move coins from exposed addresses to fresh post-quantum addresses is the obvious solution. But there is no consensus on how aggressive that window should be, or what happens to coins that do not migrate.
Some researchers have proposed "quantum-safe migration" rules where exposed addresses become unspendable after a deadline. Others argue that any such rule violates Bitcoin's core principles. The debate is ongoing.
What Holders Should Do Today
The pragmatic advice for Bitcoin holders concerned about quantum risk:
Avoid address reuse. Every time you reuse an address, you give a future quantum adversary another piece of data linked to your funds. Use fresh addresses for each receipt.
Stay on P2WPKH for cold storage. Until post-quantum scripts are deployed, P2WPKH (the segregated-witness version of P2PKH) gives you hash-based protection. Your public key is not on chain until you spend.
Reconsider Taproot for long-term holdings. Taproot is great for active wallets and channel operations, but it puts your public key on chain immediately. If you have BTC you do not plan to touch for ten years, P2WPKH is currently the safer choice.
Encrypt backups with post-quantum tools. Seed phrases, hardware wallet backups, and multisig keys are all quantum-vulnerable if recovered. Encrypting them with a tool that uses ML-KEM-1024 plus X25519 in hybrid mode gives you defense-in-depth that does not depend on Bitcoin protocol upgrades. QNSQY does exactly this.
Plan to migrate eventually. Whenever Bitcoin adds post-quantum signature support, plan to move your holdings to the new address types. This is a future project, but knowing it will come matters.
For the broader threat model, see our harvest now, decrypt later explainer.
FAQ
Are my Bitcoin funds safe today? Yes, in the sense that no quantum computer powerful enough to break secp256k1 exists. The risk is forward-looking: data harvested today (exposed public keys) could be cracked years or decades from now. The funds in your wallet are safe until quantum computers exist, which will likely happen by 2035-2040 according to NSA projections.
What is the most quantum-vulnerable Bitcoin? P2PK outputs from 2009-2010 (most of Satoshi's mining rewards), reused addresses where the public key is on chain, and Taproot outputs (since their keys are on chain immediately). Dormant P2PK outputs are particularly notable because they cannot be moved without a private key.
Should I move my BTC out of Taproot addresses? If your Bitcoin is in active use (Lightning, frequent transactions), Taproot is fine because the public key was already revealed on first spend anyway. If your Bitcoin is in long-term cold storage and you do not need Taproot's specific features, P2WPKH gives you stronger quantum protection by keeping the public key behind a hash.
Will Bitcoin add post-quantum signatures? Eventually, yes. There is no committed timeline. The cryptographic primitives are now NIST-standardized, but Bitcoin protocol changes are slow and conservative. Expect years of research, proposals, and consensus building before deployment.
Can I protect my seed phrase against quantum attacks? Yes. Encrypt your seed phrase backups with a tool that uses ML-KEM-1024 with X25519 in hybrid mode. QNSQY does this, and it gives you confidentiality that does not depend on the underlying Bitcoin protocol's quantum migration timeline.
Sources
- NIST FIPS 203 (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final
- NIST FIPS 204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final
- NIST FIPS 205 (SLH-DSA): https://csrc.nist.gov/pubs/fips/205/final
- Bitcoin BIP 340 (Schnorr Signatures): https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
- Bitcoin BIP 341 (Taproot): https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
- Bitcoin BIP 342 (Validation of Taproot Scripts): https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
- Bitcoin Core Documentation: https://bitcoin.org/en/developer-documentation
Related Articles
- What is Post-Quantum Cryptography
- Harvest Now, Decrypt Later
- PQC, Blockchain, Bitcoin, Ethereum
- ML-DSA vs SLH-DSA
- NIST FIPS Guide
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.