How to Make Bitcoin
Post-Quantum

1 Taproot PQ Commitment (No Fork Required) 4–6 Weeks

This is the approach that works today, on the current Bitcoin network, with no protocol changes. Bitcoin’s Taproot upgrade (SegWit v1), active since November 2021, supports hidden script paths inside the Taproot tree. You can create a Taproot address that commits to post-quantum public keys at the time of address creation, then spend normally with Schnorr signatures until quantum threatens, at which point you reveal the PQ script path and spend using the pre-committed post-quantum signatures.

The architecture:

• Key path (normal): Standard Schnorr (secp256k1). Fast, cheap, private. Indistinguishable from any other Taproot spend on-chain.
• Script path (quantum escape): A hidden leaf in the Taproot tree that commits to Dilithium (ML-DSA-65, FIPS 204) and FALCON-512 public keys. This leaf is invisible on-chain until revealed.
• Temporal binding: The commitment hash is computed at address creation time. SHA3-256(Ed25519_pk || Dilithium_pk || FALCON_pk). This proves the PQ keys existed before any quantum attack could have been mounted.

When quantum threatens, the holder reveals the Taproot script path, provides the PQ public keys (which match the commitment), and signs the spend with Dilithium and FALCON. A quantum attacker who has broken the Schnorr key cannot forge the PQ signatures because they were committed before the attacker had the capability.

// Generate a quantum-hedged Taproot address (Rust)
let secp = Secp256k1::new();

// Classical Schnorr keypair (normal spending)
let keypair = Keypair::new(&secp, &mut rand::thread_rng());
let (x_only_pk, _) = XOnlyPublicKey::from_keypair(&keypair);

// PQ keypairs (escape path)
let (dil_pk, dil_sk) = mldsa65::keypair();   // ML-DSA-65 (FIPS 204)
let (fal_pk, fal_sk) = falcon512::keypair(); // FALCON-512 (NTRU)

// Commitment: SHA3-256 of all PQ public keys
let commitment = sha3_256(ed_pk || dil_pk || fal_pk);

// Build Taproot tree with PQ escape leaf
let pq_script = Script::builder()
    .push_opcode(OP_SHA256)
    .push_slice(sha256(&commitment))
    .push_opcode(OP_EQUALVERIFY)
    .push_opcode(OP_TRUE)
    .into_script();

let address = Address::p2tr(&secp, x_only_pk, merkle_root);
// bc1p... — looks like a normal Taproot address

Why this works without a fork: Taproot already supports arbitrary scripts in the tree. We are not adding new opcodes — we are using the existing OP_SHA256 and OP_EQUALVERIFY to validate that the revealer knows the pre-image (the PQ public keys) of the committed hash. The actual PQ signature verification happens off-chain today. In a future soft fork that adds PQ opcodes, the same commitment structure would enable on-chain verification with no address migration.

The tradeoff: The PQ signature verification is off-chain. This means the Bitcoin network does not natively enforce the PQ signatures. The commitment proves the PQ keys existed before quantum, and the script path proves the revealer knows the PQ keys, but a quantum attacker who compromises the Schnorr key could race the legitimate holder to spend via the key path before the holder uses the script path. This is a timing race, not a cryptographic break — and it can be mitigated with monitoring and pre-signed PQ spending transactions held in reserve.

2 Post-Quantum Custody Vault 2–3 Weeks

The fastest path to production. Users deposit Bitcoin into a vault controlled by a threshold multisig (2-of-3 or 3-of-5) where the authorization layer is entirely post-quantum. Classical Bitcoin transactions handle the on-chain movement. Dilithium and FALCON signatures handle the authorization to spend.

The architecture:

• User sends BTC to the vault’s Taproot address
• H33 issues a Dilithium-signed receipt for every deposit
• Withdrawals require H33-3-Key triple signature: Ed25519 (classical) → Dilithium (MLWE lattice, FIPS 204) → FALCON (NTRU lattice, independent family)
• ZKP attestation proves the vault holds sufficient reserves without revealing individual holdings
• Temporal binding on every operation proves ordering

The tradeoff: Semi-custodial. Users trust the vault’s threshold signers. This is the same trust model as any custodial Bitcoin service (exchanges, institutional custody providers), but with the critical difference that the authorization layer is quantum-safe. For institutional holders who already use custodial solutions, this adds quantum protection with zero workflow change.

Who this is for: Funds, treasuries, exchanges, and institutional holders who need quantum protection now and are already comfortable with custodial or semi-custodial models. A fund holding $500M in Bitcoin cannot wait for a soft fork — they need protection deployed this quarter.

3 Post-Quantum Layer 2 3–6 Months

A Layer 2 network where all off-chain transactions use post-quantum signatures. Channel opens and closes use classical Bitcoin (on-chain), but every state update within a channel is signed with Dilithium and FALCON. This is architecturally similar to the Lightning Network, but with quantum-safe state management.

The architecture:

• Channel open: Classical Bitcoin transaction (on-chain)
• State updates: H33-3-Key triple signature (off-chain, PQ-safe)
• Dispute resolution: The PQ-signed latest state is broadcast if a channel partner disappears or attempts fraud
• Channel close: Classical Bitcoin transaction with the PQ-attested final state
• Temporal binding proves which state is newest — quantum replay attacks are cryptographically impossible

The tradeoff: Complexity. Layer 2 networks require liquidity, routing, and channel management infrastructure. The on-chain footprint (channel open and close) remains classical Bitcoin, meaning those transactions are still vulnerable during the brief window they are in the mempool. This window can be minimized with batching and fast confirmation strategies, but it cannot be eliminated without a protocol change.

Who this is for: Payment processors, Lightning node operators, and high-frequency Bitcoin users who need quantum-safe transaction throughput. The Layer 2 approach is ideal for operational transactions where speed matters more than long-term cold storage security.

4 Bitcoin Protocol Soft Fork 6–12 Months to Build, Years to Activate

The permanent solution. A new SegWit version (v2 or later) that natively accepts post-quantum signatures in the witness data. This requires a Bitcoin Improvement Proposal (BIP), extensive review, testnet deployment, and community consensus for activation — the same process that Taproot went through from 2018 to 2021.

The technical requirements:

• New witness version: SegWit v2 programs that recognize Dilithium or FALCON signatures
• Signature size: Dilithium signatures are 3,309 bytes (vs Schnorr’s 64 bytes). FALCON signatures are approximately 690 bytes. This requires careful witness discount calibration to avoid fee explosion.
• Key size: Dilithium public keys are 1,952 bytes. FALCON public keys are 897 bytes. These are significantly larger than the 32-byte Schnorr keys, impacting blockchain growth.
• Aggregation: Schnorr signatures support MuSig2 aggregation (multiple signers, one signature). Dilithium and FALCON aggregation is an active research area. Without aggregation, multisig transactions become much larger.
• Backward compatibility: Old nodes must still validate the chain. The soft fork must be designed so that old nodes see the PQ transactions as "anyone-can-spend" (the standard SegWit forward-compatibility mechanism).

The candidate algorithms:

FALCON is the most practical for on-chain use due to compact signatures (690 bytes). Dilithium is the most conservative choice (NIST’s primary recommendation). SPHINCS+ is hash-based (no lattice assumptions, maximum diversity) but signatures are impractically large for a blockchain. The optimal strategy uses FALCON for on-chain efficiency and Dilithium for off-chain attestation, with the option to fall back to SPHINCS+ if lattice-based cryptography is ever compromised.

The tradeoff: Bitcoin governance. Taproot took four years from BIP to activation. A PQ soft fork will face even more scrutiny because of the signature size impact on blockchain growth. Realistically, activation is 3 to 5 years away from BIP submission, and that assumes the community reaches consensus — which is never guaranteed.

Why it still matters to build the reference implementation now: The team that writes the BIP and ships the reference implementation defines the standard. Even if activation takes years, every other implementation (Bitcoin Core, btcd, Libbitcoin, bcoin) will reference that code. Being the author of the PQ standard for Bitcoin is worth more than the code itself.