A categorized index of active developer work, proposals, and discussion on Bitcoin's post-quantum migration. This is a living document; contributions welcome.
Last updated: 2026-04-07
- New Output Types and Migration Proposals
- Signature Schemes
- ZK Proofs for Migration and Recovery
- HD Wallets, Key Derivation, and Advanced Features
- Script-Level Approaches
- General Discussion and Threat Analysis
- Academic Papers
- Author: Hunter Beast (cryptoquick)
- Where: Delving Bitcoin
- Summary: Defines a new SegWit output type that commits to a hash of a post-quantum public key, keeping the PQ key off-chain until spend time. Ongoing revisions address signature algorithm selection, witness structure, and interaction with Taproot and existing output types.
- Author: Jameson Lopp
- Where: bitcoin-dev
- Summary: Three-phase migration plan: (A) disallow sends to legacy script types, (B) flag-day invalidation of ECDSA/Schnorr spends ~5 years after activation, (C) optional future fork allowing ZK proof recovery of legacy UTXOs via BIP-39 seed phrase. Builds on P2QRH as the target PQ output type.
- Author: Matt Corallo (with credit to not_nothingmuch)
- Where: bitcoin-dev
- Summary: Proposes an opt-in migration path that leverages Taproot's existing structure. Wallets would include an OP_SPHINCS (or equivalent PQ signature opcode) script-path branch in their Taproot outputs today, at negligible on-chain cost. When QCs become a reality, key-path spends are disabled via soft fork, forcing spends through the PQ script path. Wallets that already committed to this branch are automatically protected; those that didn't would need to migrate. The post argues this is the minimal-footprint approach: no on-chain bloat until the QC threat materializes, with explicit opt-in or opt-out for BIP-86 wallets that use a NUMS point instead of a real script tree. This is the "rough migration path that allows opt-in over time" framing.
- Author: Hunter Beast (cryptoquick)
- Where: Delving Bitcoin
- Summary: Argues for building algorithm agility into Bitcoin's PQ migration, allowing multiple signature algorithms to coexist so the system can adapt if any single PQ scheme is broken by future advances.
- Author: conduition
- Where: Delving Bitcoin
- Summary: Stateful hash-based signature scheme achieving 324-byte PQ signatures by combining Winternitz OTS with careful state management. Compatible with BIP-39 seed phrase backups through deterministic state progression.
- Author: conduition
- Where: Delving Bitcoin
- Summary: Extends SHRINCS to support multiple signing devices (hardware wallet + phone) sharing a single stateful key without risking state reuse. Partitions the OTS key space across devices and coordinates state.
- Author: (multiple contributors)
- Where: bitcoin-dev
- Summary: General discussion of hash-based signature schemes (SPHINCS+, XMSS, LMS) and their applicability to Bitcoin, covering size/speed tradeoffs, statefulness concerns, and integration paths.
- Author: (multiple contributors)
- Where: bitcoin-dev
- Summary: Discussion of performance optimizations for SLH-DSA (the NIST standardized version of SPHINCS+), focusing on reducing signature size and verification time for Bitcoin use cases.
- Author: ajtowns
- Where: Delving Bitcoin
- Summary: Compares WOTS implementations in Bitcoin Script vs Chia LISP, showing LISP can implement WOTS far more compactly, illustrating the constraints Bitcoin Script faces for hash-based PQ signatures.
- Author: (multiple contributors)
- Where: bitcoin-dev
- Summary: Discussion of Falcon (a NIST-standardized lattice-based signature scheme) for Bitcoin, covering compact signature sizes (~666 bytes) but noting implementation complexity and side-channel concerns.
- Author: (multiple contributors)
- Where: bitcoin-dev
- Summary: Proposes a hybrid approach where HD wallets commit to both classical and SPHINCS+ keys, with the PQ key serving as a fallback if the classical key is compromised by quantum advances.
- Author: Seck, Roux-Langlois
- Where: cic.iacr.org/p/2/3/3, discussed by @roasbeef
- Summary: Analyzes replacing ECDSA with ML-DSA (Dilithium/FIPS 204) in Bitcoin. Introduces DilithiumRK, a variant with rerandomizable keys that preserves BIP-32 HD derivation compatibility. Unlike hash-based signatures, lattice schemes have the algebraic structure needed for key derivation, but the standard Dilithium public key compression breaks homomorphic properties. DilithiumRK works around this by removing the compression and including an error term hint in signatures. Tradeoffs: sigs+pubkeys ~3.5% larger, signing 2.7x slower, verification 1.75x slower, but BIP-32 compatibility is preserved.
- Author: conduition
- Where: Delving Bitcoin
- Summary: Examines isogeny-based PQ crypto (CSIDH descendants) as a candidate that preserves group structure needed for HD derivation, key tweaking, and silent payments. Uniquely offers a near drop-in replacement for ECC-based constructions, though concrete security levels are debated.
- Author: (multiple contributors)
- Where: bitcoin-dev
- Summary: Proposes a new opcode for cross-input signature aggregation adapted for post-quantum signature schemes, addressing the size overhead of PQ signatures by amortizing verification across transaction inputs.
- Author: conduition
- Where: Delving Bitcoin
- Summary: Proposes using ZK proofs (STARKs or similar PQ-secure proof systems) to let owners of P2PKH outputs prove knowledge of the secret key without revealing the public key on-chain, enabling migration to PQ-safe outputs even when the pubkey has been previously exposed.
- Author: conduition
- Where: Delving Bitcoin
- Summary: Explores STARKs both as a PQ-secure signature verification mechanism and as a scaling tool. STARK proofs can aggregate many signature verifications into a single compact proof, simultaneously solving PQ signature size bloat and improving throughput.
- Author: Laolu (roasbeef)
- Where: GitHub, go-zkvm
- Summary: Working implementation of a STARK proof that a Taproot output key was derived from a BIP-32 seed via BIP-86, without revealing the seed. Solves the open problem from the "Signature Lifting" paper (seed lifting without master secret exposure). Proves in ~55s on Apple Silicon, ~1.8 MB proof size. Specifically addresses the gap left by keyspend-disable proposals: BIP-86 wallets that have no script tree can still prove ownership via ZK proof of the upstream HD derivation.
- Author: Sattath, Wyborski
- Where: ePrint 2023/362
- Summary: Introduces signature lifting: using post-quantum OWFs already present in key derivation (HMAC-SHA512 in BIP-32) to lift pre-quantum signatures to PQ security. Their Picnic-based construction requires revealing the master secret; they leave ZK seed lifting as an open problem.
- Author: conduition
- Where: Delving Bitcoin
- Summary: Surveys which PQ signature/KEM schemes can support the higher-level wallet features Bitcoin relies on: HD key derivation, silent payments, MuSig-style key aggregation, and threshold signing. Most lattice- and hash-based PQ schemes lack the algebraic structure needed, making migration significantly harder than a signature drop-in.
- Author: Hunter Beast (cryptoquick)
- Where: Delving Bitcoin
- Summary: Argues that OP_CAT (if re-enabled) provides a near-term path to quantum resistance by enabling Lamport/Winternitz OTS verification in Script without new opcodes. A pragmatic interim defense while BIP-360 is developed.
- Author: (multiple contributors)
- Where: bitcoin-dev
- Summary: Demonstrates that OP_CAT combined with existing opcodes is sufficient to verify Winternitz one-time signatures on-chain, offering a hash-based PQ signature path using only soft-fork-level changes.
- Author: ajtowns
- Where: Delving Bitcoin
- Summary: Broad threat analysis: which protocol parts are vulnerable (ECDSA/Schnorr keys, not hashes), realistic quantum timelines, distinction between harvest-now-decrypt-later vs active signing attacks, and whether urgency justifies near-term consensus changes.
- Author: Tim Ruffing, et al.
- Where: bitcoin-dev, ePrint 2025/1307
- Summary: Proves that the Taproot commitment scheme (C = P + H(P||m)*G) remains binding under classical assumptions even when the DLP is broken, because the tapscript merkle root H(m) is still collision-resistant. This means disabling the keyspend path and forcing script-path spends is a viable PQ migration strategy for outputs that commit to a script tree.
| Paper | Authors | Year | Key Contribution |
|---|---|---|---|
| Protecting Quantum Procrastinators with Signature Lifting | Sattath, Wyborski | 2023 | Seed lifting via Picnic; open problem: ZK seed lifting |
| Post-Quantum Security of Bitcoin's Taproot | Ruffing | 2025 | Taproot commitment is PQ-binding for script-path |
| Towards PQ Bitcoin using Dilithium Signature | Seck, Roux-Langlois | 2024 | DilithiumRK with rerandomizable keys for BIP-32 |
| The Exact Security of BIP32 Wallets | Das et al. | 2021 | Rigorous security model for HD wallet derivation |
| Committing to Quantum Resistance | Stewart et al. | 2018 | Early Bitcoin commit-reveal defense against quantum theft |
| Making Classical Signatures Post-Quantum for Single Use | Marco, Talayhan, Vaudenay | 2023 | Generic single-use public-ledger transformation |
The work broadly falls into three tracks:
Track 1: New PQ Output Types. BIP-360 (P2QRH) defines a new output type where funds are sent to a hash of a PQ public key. Lopp's migration proposal adds a phased timeline for forcing adoption. Corallo's "trivial QC" scheme provides a minimal-footprint opt-in path: wallets embed a PQ script-path branch in their Taproot outputs today, at negligible cost, and that branch becomes the spending path if keyspend is ever disabled. This handles new coins.
Track 2: Signature Scheme Selection. Active research on which PQ signature scheme(s) Bitcoin should adopt. Hash-based (SPHINCS+, SHRINCS), lattice-based (Falcon, Dilithium/ML-DSA), and isogeny-based (CSIDH) each have different tradeoffs around size, speed, statefulness, and whether they preserve HD derivation and key aggregation. conduition's survey shows most schemes fail to support the full feature set Bitcoin wallets need.
Track 3: Legacy UTXO Recovery. For coins already on-chain in quantum-vulnerable outputs, migration requires proving ownership without classical signatures. The keyspend-disable + script-path approach (Ruffing) handles Taproot outputs with script trees. ZK proofs of BIP-32 seed knowledge (bip32-pq-zkp, conduition's P2PKH provers) handle outputs where the owner still has the HD seed but has no script tree (BIP-86 wallets). The signature lifting paper provides the theoretical foundation.
Together, these three tracks form a complete migration path: new outputs go to PQ addresses (Track 1), signed with PQ schemes (Track 2), while legacy outputs are recovered via script-path spends or ZK seed proofs (Track 3).