NIST Post-Quantum Standards: What They Mean for Bitcoin
NIST finalized post-quantum cryptographic standards. Here's how they apply to Bitcoin's signature and hashing schemes.
In August 2024, the National Institute of Standards and Technology (NIST) finalized the first three post-quantum cryptographic standards, ending an eight-year selection process that began in 2016. The standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) provide concrete replacements for classical cryptographic primitives that a sufficiently powerful quantum computer could break. For Bitcoin, these standards set the parameters for a migration that the protocol will eventually need to make.
Bitcoin currently relies on secp256k1 for both ECDSA and Schnorr signatures. Both schemes depend on the hardness of the elliptic curve discrete logarithm problem, which Shor's algorithm can solve efficiently on a quantum computer. Understanding which NIST standards could serve as replacements, and what tradeoffs they introduce, is essential for anyone building on Bitcoin today.
The Three Finalized Standards
NIST's post-quantum standards address two categories of cryptographic primitives: key encapsulation (replacing key exchange) and digital signatures (replacing ECDSA and Schnorr). Bitcoin's primary concern is signatures, but all three standards are worth understanding in context.
ML-KEM: Key Encapsulation (FIPS 203)
ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), derived from the CRYSTALS-Kyber submission, replaces classical key exchange protocols like ECDH. It provides IND-CCA2 secure key encapsulation based on the hardness of the Module Learning With Errors (MLWE) problem. While ML-KEM is critical for TLS, VPNs, and messaging protocols, it has limited direct relevance to Bitcoin's on-chain operations: Bitcoin transactions use signatures rather than key exchange. However, any off-chain communication layer that Bitcoin protocols use, including Noise Protocol handshakes in Lightning and Spark, would benefit from post-quantum key exchange.
ML-DSA: Lattice-Based Signatures (FIPS 204)
ML-DSA (Module Lattice-Based Digital Signature Algorithm) is NIST's general-purpose post-quantum signature standard, derived from CRYSTALS-Dilithium. Its security rests on the hardness of lattice problems, specifically Module-LWE and Module-SIS. ML-DSA offers three parameter sets: ML-DSA-44 (NIST security level 2, comparable to AES-128), ML-DSA-65 (level 3, comparable to AES-192), and ML-DSA-87 (level 5, comparable to AES-256).
The key characteristic of ML-DSA for Bitcoin is its balance: moderately sized signatures (2,420 to 4,627 bytes), fast verification, and well-studied security assumptions. Verification takes roughly 0.08 to 0.19 milliseconds depending on security level and implementation, which is competitive with classical signature schemes in absolute terms, though orders of magnitude larger in on-chain footprint.
SLH-DSA: Hash-Based Signatures (FIPS 205)
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+, takes a fundamentally different approach. Instead of relying on lattice assumptions, its security depends solely on the properties of hash functions (SHA-2 or SHAKE). This is a significant advantage: hash function security is among the most conservative and well-understood assumptions in cryptography. If lattice problems turn out to be easier than expected, SLH-DSA remains secure.
The tradeoff is size. SLH-DSA signatures range from 7,856 bytes to 49,856 bytes across its twelve parameter sets. FIPS 205 defines both “s” (small) and “f” (fast) variants at each security level: the “s” variants produce smaller signatures but are much slower to generate, while the “f” variants sign faster at the cost of larger output. Public keys, however, are remarkably compact: just 32 to 64 bytes depending on security level.
The fourth standard: NIST is also standardizing FN-DSA (derived from Falcon) as FIPS 206, expected to be finalized in late 2026 or early 2027. FN-DSA offers the smallest signatures among post-quantum schemes (666 bytes at level 1, 1,280 bytes at level 5) but requires floating-point Gaussian sampling during signing, which creates implementation complexity and side-channel risks. In March 2025, NIST also selected HQC as a backup code-based key encapsulation mechanism.
PQC Signature Comparison for Bitcoin
To evaluate these standards for Bitcoin, the relevant metrics are signature size (directly impacts transaction weight and block space consumption), public key size (affects address formats and UTXO set bloat), and verification speed (determines how quickly nodes can validate blocks). The following table compares the NIST standards against Bitcoin's current signature schemes.
| Scheme | Security Level | Public Key | Signature | Verification | Assumption |
|---|---|---|---|---|---|
| ECDSA (secp256k1) | ~128-bit classical | 33 bytes | ~72 bytes | ~0.05 ms | ECDLP |
| Schnorr (BIP-340) | ~128-bit classical | 32 bytes | 64 bytes | ~0.05 ms | ECDLP |
| ML-DSA-44 | Level 2 (AES-128) | 1,312 bytes | 2,420 bytes | ~0.08 ms | Module-LWE/SIS |
| ML-DSA-65 | Level 3 (AES-192) | 1,952 bytes | 3,309 bytes | ~0.12 ms | Module-LWE/SIS |
| ML-DSA-87 | Level 5 (AES-256) | 2,592 bytes | 4,627 bytes | ~0.19 ms | Module-LWE/SIS |
| SLH-DSA-128s | Level 1 (AES-128) | 32 bytes | 7,856 bytes | ~3.6 ms | Hash functions |
| SLH-DSA-128f | Level 1 (AES-128) | 32 bytes | 17,088 bytes | ~0.8 ms | Hash functions |
| FN-DSA-512 (draft) | Level 1 | 897 bytes | 666 bytes | ~0.1 ms | NTRU lattice |
| FN-DSA-1024 (draft) | Level 5 | 1,793 bytes | 1,280 bytes | ~0.2 ms | NTRU lattice |
The numbers tell a clear story. Even the most compact post-quantum signature (FN-DSA-512 at 666 bytes) is roughly 10 times larger than a Schnorr signature. ML-DSA-44, the most practical finalized standard, produces signatures that are nearly 38 times larger. SLH-DSA signatures exceed 100 times the current size. For a network where block space is a scarce resource and every byte is permanently stored by full nodes, these size increases represent a fundamental constraint.
Lattice-Based vs Hash-Based: The Bitcoin Tradeoff
The choice between ML-DSA (lattice-based) and SLH-DSA (hash-based) for Bitcoin involves a tradeoff between signature compactness and cryptographic conservatism. Each approach has distinct strengths when evaluated against Bitcoin's specific requirements.
The Case for ML-DSA
ML-DSA is the pragmatic choice. Its signatures are 3 to 6 times smaller than SLH-DSA at comparable security levels, and its verification speed is competitive with classical schemes. For a UTXO-based system like Bitcoin, where every transaction input carries a signature that every validating node must verify, fast verification is not optional. A block containing 2,000 transactions with ML-DSA-44 signatures would add roughly 4.7 MB of signature data. The same block with SLH-DSA-128s signatures would require approximately 15.3 MB.
ML-DSA also supports efficient batch verification. Multiple signatures can be verified together faster than verifying each individually, which is critical for block validation performance. The lattice structure allows algebraic optimizations during verification that hash-based schemes cannot exploit.
The Case for SLH-DSA
SLH-DSA's appeal is its minimal trust assumptions. Lattice-based cryptography, while extensively studied, relies on computational assumptions (MLWE, SIS) that are newer than the assumptions underlying hash functions. If a mathematical breakthrough weakened lattice problems, any protocol built on ML-DSA would need another migration. SLH-DSA avoids this risk entirely: its security reduces to the collision resistance and preimage resistance of standard hash functions like SHA-256, the same hash function Bitcoin already uses for proof of work.
SLH-DSA also has tiny public keys (32 bytes), which matters for the UTXO set. Public key hashes stored in outputs would remain compact. The size penalty appears only when spending, in the form of large witness data. For cold storage UTXOs that are rarely spent, this might be an acceptable tradeoff.
Why not both? A hybrid approach using classical signatures alongside post-quantum signatures offers defense in depth: the transaction is secure as long as either scheme remains unbroken. The cost is additive size. A hybrid Schnorr + ML-DSA-44 signature would be roughly 2,484 bytes, compared to 64 bytes for Schnorr alone. Several Bitcoin proposals, including elements of BIP-360, contemplate hybrid constructions as a transitional measure.
Impact on the UTXO Model
Bitcoin's UTXO model creates unique constraints for post-quantum migration. Unlike account-based systems where a single key update covers all future transactions, each Bitcoin UTXO is locked by a specific script and public key commitment. A post-quantum migration must address both new outputs (straightforward: define a new address type) and existing outputs (complex: coins locked to classical keys remain vulnerable until spent).
New Address Formats
BIP-360, merged into the official BIP repository in February 2026, proposes a new output type (originally called P2QRH, later renamed P2MR) that can commit to post-quantum public keys. The proposal defines the address structure that future soft forks could plug specific PQC signature schemes into. It does not, on its own, add quantum-resistant signatures to Bitcoin: it builds the framework for them.
BIP-360 uses SegWit version 2 with a bc1z prefix. Legacy nodes treat these outputs as anyone-can-spend, preserving backward compatibility as a soft fork. The proposal is merged but not activated, and the choice of which post-quantum signature algorithm to support remains an open question.
The Migration Problem
Defining new address types is the easy part. The harder problem is what happens to coins sitting in legacy addresses with exposed public keys. A Glassnode analysis estimates roughly 6 million BTC (approximately 30% of total supply) currently sits in addresses where the public key has been revealed through prior spending. These coins are directly vulnerable to a quantum adversary.
Users with exposed keys would need to move coins to post-quantum addresses before a sufficiently powerful quantum computer exists. A voluntary migration depends on millions of individual users taking action, and inevitably some coins, including those in lost wallets and Satoshi's estimated holdings, will never move. Whether the network should implement a forced migration mechanism, effectively freezing unmoved coins after a deadline, remains one of the most contentious questions in the post-quantum Bitcoin debate.
Block Space Economics
Post-quantum signatures change the economics of block space fundamentally. With Bitcoin's current 4 MB weight limit, larger signatures reduce the number of transactions that fit in a block. The following table models the impact on single-input, single-output transactions.
| Signature Scheme | Approx. Tx Size | Txs per Block (est.) | Reduction vs. Current |
|---|---|---|---|
| Schnorr (BIP-340) | ~140 bytes | ~7,100 | Baseline |
| ML-DSA-44 | ~3,800 bytes | ~1,050 | ~85% |
| ML-DSA-65 | ~5,400 bytes | ~740 | ~90% |
| FN-DSA-512 (draft) | ~1,600 bytes | ~2,500 | ~65% |
| SLH-DSA-128s | ~7,900 bytes | ~500 | ~93% |
| SLH-DSA-128f | ~17,200 bytes | ~230 | ~97% |
Even ML-DSA-44, the most space-efficient finalized standard, would reduce throughput by roughly 85%. This makes the block size debate newly relevant. A post-quantum Bitcoin may need to revisit the witness discount, apply aggressive signature aggregation, or increase block weight limits to maintain current throughput. Each option carries its own set of tradeoffs around decentralization and node requirements.
Signature Aggregation as Mitigation
Signature aggregation could help offset the size increase. Cross-input signature aggregation combines multiple signatures within a transaction into a single proof, reducing the per-input overhead. For ML-DSA, this is algebraically feasible due to the linear structure of lattice-based schemes, though the aggregated signature would still be substantially larger than aggregated Schnorr signatures. Half-aggregation techniques could reduce total signature data by roughly 50% in multi-input transactions.
Implications for Spark and Threshold Signing
Spark relies on FROST threshold signatures for its cooperative signing model. FROST's design exploits the linearity of Schnorr signatures: each signer produces a partial signature from their key share, and partial signatures are combined using Lagrange coefficients. This linear aggregation template does not carry over to post-quantum schemes without significant modification.
Lattice-Based Threshold Signing
Recent academic work has produced FROST-like constructions for lattice settings. The most direct analogue is Hermine (ePrint 2026/419), a lattice-based threshold signature scheme that offers the full feature set of FROST under standard lattice assumptions. Its key contribution is an everywhere-short secret sharing scheme that resolves the rejection sampling obstacle inherent in lattice signing. Hermine produces approximately 11 KB threshold signatures and targets groups of up to 64 signers.
A Delving Bitcoin discussion on post-quantum key aggregation and threshold signatures concluded that there is nothing inherently blocking lattice-based replacements for BIP-32 HD key derivation, silent payments, MuSig-style aggregation, or FROST. The challenge is practical: lattice threshold signatures are larger, require more communication rounds, and have not yet been standardized or deployed at scale.
Impact on Spark's Architecture
For Spark specifically, the choice of post-quantum standard affects two critical performance dimensions: signature size in cooperative transfers and the number of communication rounds required during signing. Current FROST-based Spark transfers produce compact Schnorr signatures (64 bytes). A migration to lattice-based threshold signing would increase signature data by roughly 170x (using Hermine's 11 KB output), which affects both on-chain exit transaction costs and off-chain transfer bandwidth.
The signing round performance is equally important. FROST's two-round protocol (with nonce preprocessing) is a key enabler of Spark's instant transfers. Lattice-based threshold schemes currently require additional rounds for rejection sampling coordination, though Hermine demonstrates that FROST-style nonce preprocessing can be adapted to the lattice setting. Ongoing research aims to match FROST's round efficiency while maintaining post-quantum security.
NIST threshold standardization: NIST has an active Threshold Cryptography project that is evaluating both classical and post-quantum threshold schemes. A standardized lattice-based threshold signature would significantly de-risk post-quantum migration for protocols like Spark that depend on distributed signing.
Timeline and Urgency
NIST's own guidance calls for ECC-256 (the curve family that includes secp256k1) to be deprecated by 2030 and disallowed after 2035. The timeline for a cryptographically relevant quantum computer (CRQC) remains debated. A March 2026 Google Quantum AI paper reportedly reduced the estimated qubit requirement to under 500,000 physical qubits, down from roughly 20 million in earlier estimates. Current machines have on the order of 1,000 to 1,500 qubits.
The more immediate threat is the harvest-now-decrypt-later scenario. Exposed public keys on the Bitcoin blockchain are permanent. An adversary could record them today and derive private keys once quantum hardware matures. This makes the migration timeline more urgent than the CRQC timeline alone would suggest: by the time quantum computers arrive, it will be too late to protect already-exposed keys.
What Developers Should Do Now
The NIST standards provide a concrete foundation for planning. Developers building on Bitcoin and Bitcoin Layer 2 protocols should consider the following near-term actions:
- Adopt cryptographic agility in protocol design: abstract signature verification so that swapping the underlying scheme requires minimal code changes
- Encourage users to use addresses that do not expose public keys until spending (pay-to-public-key-hash and Taproot key-path spends protect the public key until the UTXO is spent)
- Track BIP-360 and related proposals for post-quantum address formats
- Experiment with ML-DSA and SLH-DSA in test environments: libraries like liboqs and OpenSSL 3.5 now include production-ready implementations
- For threshold signing systems like Spark, monitor the development of lattice-based FROST analogues and NIST's threshold cryptography project
For developers building Bitcoin applications today, the Spark SDK provides a Layer 2 framework where future cryptographic upgrades can be deployed without requiring changes to Bitcoin L1. Spark's cooperative signing model means that post-quantum signature schemes can be integrated at the operator level, giving wallets a migration path that does not depend on Bitcoin consensus changes. For more on how the quantum threat applies to Bitcoin, see our companion research article.
Open Questions
Several critical questions remain unanswered as the Bitcoin community evaluates the NIST standards:
- Which signature algorithm should Bitcoin adopt? ML-DSA offers the best size-to-security ratio among finalized standards. FN-DSA (once finalized) would be more space-efficient but introduces implementation complexity. SLH-DSA provides the most conservative security assumptions at the highest space cost.
- Should Bitcoin use a hybrid scheme (classical + PQC) during the transition period, accepting the size overhead for defense in depth?
- How should the block weight limit adapt? Larger signatures reduce throughput unless limits are raised, but raising limits increases node resource requirements and risks centralization.
- What happens to unmoved legacy coins? A forced migration protects more coins but requires unprecedented consensus changes and raises philosophical questions about Bitcoin's property guarantees.
- Can post-quantum signature aggregation techniques mature fast enough to offset the throughput reduction?
The NIST post-quantum standards mark a milestone: the cryptographic primitives that will replace elliptic curve schemes are no longer theoretical. They have parameter sets, reference implementations, and concrete performance characteristics. For Bitcoin, the question has shifted from “what will post-quantum cryptography look like?” to “how do we deploy it within the constraints of a decentralized, UTXO-based system?” The answer will shape Bitcoin's security model for decades.
This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.