Dr. Sarah Chen
Bitcoin Has a Post-Quantum Problem With No Clean Solution
Bitcoin's quantum vulnerability is not a hypothetical. The Coinbase quantum threat report identified 6.9 million BTC held in addresses whose public keys are already exposed on-chain. A fault-tolerant quantum computer running Shor's algorithm could derive the private keys for those addresses without their owners doing anything. The funds would simply be gone.
Bitcoin developers have been aware of this for years. The proposed response is BIP-360, which would introduce a new transaction output type called Pay-to-Quantum-Resistant-Hash (P2QRH). Understanding what BIP-360 actually proposes, what it does not solve, and why the timeline matters requires working through the specifics of the proposal, the migration challenge it faces, and the broader context of how long cryptographic changes take to deploy on Bitcoin.
What Is BIP-360?
BIP-360 is a Bitcoin Improvement Proposal that introduces P2QRH: Pay-to-Quantum-Resistant-Hash. The proposal follows the same structural logic as earlier Bitcoin output type upgrades, specifically SegWit (BIP-141) and Taproot (BIP-341). It defines a new script type that Bitcoin nodes would recognise and validate using a post-quantum signature scheme rather than ECDSA.
The key design choice in BIP-360 is that it uses a hash-committed approach. When a user sends funds to a P2QRH address, they commit to a hash of their post-quantum public key, not the public key itself. The full public key, along with the post-quantum signature, is only revealed when the funds are spent. This preserves Bitcoin's existing pattern of hiding the public key until spend time, which provides some quantum protection for unspent outputs even before the full migration is complete.
BIP-360 does not specify a single post-quantum algorithm. The proposal is algorithm-agnostic and lists CRYSTALS-Dilithium, FALCON, and SPHINCS+ as candidate signature schemes. The final algorithm selection would need to be determined through the Bitcoin developer consensus process before the BIP could be implemented. Given the signature size differences between these options (666 bytes for FALCON-512, 2420 bytes for Dilithium2, 17088 bytes for SPHINCS+-128f), this choice has significant consequences for transaction fees and throughput.
The Address Migration Problem
BIP-360 creates a new, secure output type. It does not automatically protect funds currently held in ECDSA addresses. Any funds that remain in an existing P2PKH, P2WPKH, or P2TR address after a cryptographically relevant quantum computer exists are still vulnerable, regardless of whether BIP-360 has been activated.
This creates a migration challenge with no precedent in Bitcoin's history. Moving funds from a vulnerable ECDSA address to a P2QRH address requires users to sign a transaction from the old address, which reveals the ECDSA public key during the signing process. That final reveal, at the moment of migration, is itself a window of quantum vulnerability. If a quantum computer exists and is capable of deriving private keys from public keys in the time between transaction broadcast and confirmation, the migration transaction itself could be front-run.
The time window for a classical ECDSA transaction to be confirmed is typically 10 minutes to an hour under normal network conditions. Current estimates for the time a quantum computer would need to derive a private key from a secp256k1 public key start in the range of hours to days, even at the hypothetical hardware capability levels projected for the coming decade. This means a migration transaction broadcast under normal conditions is unlikely to be front-run in the near term, but the window narrows as quantum hardware improves, and any period of network congestion that extends confirmation time increases the risk.
Our analysis of how many qubits it takes to break Bitcoin covers the hardware requirements for a key recovery attack in detail.
The Scale of the Migration Challenge
The 6.9 million BTC in already-exposed addresses identified by Coinbase represents roughly a third of the circulating supply. These are addresses where the public key has already been revealed on-chain through a prior spending transaction, meaning no migration transaction is needed to expose the key: it is already exposed. Quantum recovery of these private keys requires only the key derivation computation, with no race condition against confirmation time.
Beyond those already-exposed addresses, every pay-to-public-key (P2PK) output, including those believed to belong to Satoshi Nakamoto from Bitcoin's early blocks, exposes the public key directly in the output script rather than hashing it first. These are also immediately readable by any observer with access to the blockchain history.
Getting the owners of these addresses to migrate requires active participation. Some owners are unreachable: they have lost their keys, they are deceased, or they are institutions that no longer exist. Others hold addresses as cold storage specifically because they do not interact with the network regularly. A coordinated migration campaign would require reaching and motivating a substantial fraction of Bitcoin's holder base, many of whom are precisely the users who have minimised their on-chain footprint as a security measure.
For a full picture of what happens to Bitcoin and its holders if a quantum computer capable of key recovery arrives before migration is complete, see what happens on Q-Day.
The Throughput Cost of Any Post-Quantum Upgrade
Whichever signature scheme BIP-360 adopts, Bitcoin's throughput will decrease during and after the migration. FALCON-512 at 666 bytes is the most compact NIST-standardised post-quantum option, but it is still 10.4 times larger than ECDSA's 64-byte signature. Adopting Dilithium2 at 2420 bytes reduces block capacity by roughly 90% under current block size limits. SPHINCS+ is too large for practical use on a 1 MB block structure.
The Bitcoin community would need to increase the block size limit to maintain current throughput levels after a post-quantum migration. This is a politically contentious change in Bitcoin's governance history: the block size debate consumed years of developer energy and resulted in a hard fork (Bitcoin Cash) the last time it was seriously contested. Adding post-quantum signatures as the forcing function for a block size increase does not make that debate easier.
What BIP-360 Does Not Solve
BIP-360 addresses forward security for new transactions: funds sent to P2QRH addresses after activation will be protected by post-quantum signatures. It does not address the following:
- Retroactive protection: Funds in ECDSA addresses are not automatically migrated. Owners must take action to move their funds.
- Lost or inaccessible wallets: Any address whose owner cannot or does not migrate before a cryptographically relevant quantum computer exists will remain permanently vulnerable.
- Throughput degradation: Post-quantum signatures are substantially larger than ECDSA signatures. BIP-360 does not change Bitcoin's block structure to accommodate this overhead without a separate block size change.
- Algorithm selection: The proposal is algorithm-agnostic. Developer consensus on which post-quantum scheme to adopt has not been reached, and the choice has large consequences for fee markets and node resource requirements.
- Activation timeline: Bitcoin soft fork activations require supermajority miner signalling and typically take months to years from proposal to activation. BIP-360 has not yet reached the activation stage.
The blockchain quantum migration problem article examines why retroactive migration is structurally harder for all established chains, not just Bitcoin.
A Different Approach: Building Quantum-Native From the Start
BIP-360 is a reasonable proposal for a chain that was not designed with quantum resistance in mind. It addresses the forward security problem within Bitcoin's existing governance and deployment constraints. But it is, by design, a retrofit: it adds a new output type that coexists with the vulnerable legacy system rather than replacing it.
A blockchain designed from the first block for quantum resistance operates under different constraints. QuanChain's TADEQS architecture ensures that no public key is ever exposed on-chain. The SpendAndRotate mechanism derives a new child key for each transaction and retires the used key, so there is no accumulated pool of exposed public keys to protect retroactively. The quantum migration problem, as it exists for Bitcoin, does not apply because there was never a period of ECDSA operation from which keys need to be migrated.
This is not a criticism of the Bitcoin development community, which is working within the constraints of an existing deployed system with hundreds of billions of dollars of value at stake. It is an observation about the structural difference between retrofitting quantum resistance and building for it from genesis. For a direct comparison, see Bitcoin's full quantum vulnerability analysis.
BIP-360 is Bitcoin's most concrete post-quantum proposal. It is also, by design, incomplete: it protects new funds without automatically protecting existing ones, and it defers the most difficult governance decisions about algorithm selection and block size to future debates that have no guaranteed resolution timeline.
For users holding Bitcoin in ECDSA addresses, the practical implication is clear: migration to a P2QRH address, once BIP-360 activates, should be treated as a time-sensitive operation rather than an optional upgrade. The guide to assessing your Bitcoin quantum risk covers the criteria for deciding when and whether to act.
