Blockstream Research has released a full report on lattice-based signatures for Bitcoin, comparing three post-quantum candidates — Dilithium, Falcon and Hawk — and laying out where each one stands on security, performance, deployment risk and wallet integration. The report was written by the Blockstream Team and the MarsBit article credits Saoirse of Foresight News for the Chinese translation.
At the center of the review is Bitcoin’s signature model. Schnorr and ECDSA are cheap today, but Shor showed in 1994 that a sufficiently powerful quantum computer could break both. The timing of that threat is still debated, yet the report argues that Bitcoin needs a workable post-quantum deployment path before such machines become practical.
Why lattice signatures are under review
Blockstream presents lattice signatures as one of the leading replacement options for Bitcoin’s current authorization scheme. Lattice cryptography has more than a century of research history, and its cryptographic use has developed over nearly 30 years. In a post-quantum setting, the report says lattice signatures can bring key-and-signature totals below 1.6 kilobytes in the best cases, while their algebraic structure may later support multisignatures, threshold signatures and succinct proofs.
The study is written for readers who may not already know lattice cryptography. It explains the design logic behind the three schemes, walks through the algorithms and then evaluates them through a Bitcoin-specific lens, including security, efficiency, real-world deployment and key derivation for wallets.
Four criteria Blockstream uses for Bitcoin
The report says Bitcoin has constraints that narrow the field. Its evaluation revolves around four core standards.
On-chain cost
One of the most important variables is the combined size of the public key and signature. When an output is spent, both go on-chain, and full nodes must download and store every byte. Verification cost also matters because every signature must be checked across the network; slower verification raises the burden on nodes.
Implementation complexity
Safe implementation is not a side issue in this review. If a design relies on floating-point arithmetic or delicate Gaussian sampling, mistakes or timing-analysis side-channel attacks can leak secret material. Blockstream treats implementation complexity as a major part of any smooth migration path.
Deployment risk
Integration into Bitcoin also runs into practical hurdles: consensus-level hash choices, reproducibility of signatures across platforms and memory limits on hardware wallets. The report notes that many candidate schemes use SHAKE, while Bitcoin uses SHA-256, a mismatch that would add deployment friction.
Long-term potential
Most Bitcoin wallets use the BIP-32 hierarchical deterministic model, where a single master public key can derive an unlimited number of child public keys without exposing the private key. Blockstream says no standardized post-quantum signature scheme natively supports that feature, so the report studies the cost of adding it and also looks at non-standard variants that might offer more flexibility.
Why the report argues for at least security level 3
Before comparing sizes, Blockstream tackles target security levels. NIST divides them into levels 1 through 5, with higher levels bringing stronger security and larger keys and signatures.
The report argues that Bitcoin should adopt at least level 3. A Bitcoin output may remain unspent for decades. If later cryptanalysis lowers the effective strength of a scheme, those funds could sit behind weakened keys for a very long time. Blockstream says lattice assumptions have gone through close to 30 years of public cryptanalysis, a longer buildup than the research base behind elliptic curves when Bitcoin adopted them. Even so, the algebraic structure of lattices still leaves room for future attacks, so the report rejects the idea of leaning on lower safety margins for a system with such a long security horizon.
It points to other products that have made the same choice. Apple’s iMessage PQ3 drops level-1 lattice parameters and uses levels 3 and 5 throughout. Cloudflare uses ML-KEM-768, a level-3 parameter set, in its post-quantum TLS deployment and has said that even if level 1 looks secure now, room should be left for decades of future cryptanalysis. Bitcoin’s security window is longer still, the report says.
That choice is costly. As one example, Dilithium grows by about 1.5 kilobytes in total size when moving from level 2 to level 3. The report compares parameter sets across all security levels and says Hawk’s later failure shows that conservative margins are not an abstract concern.
Dilithium: the simplest to implement, but the bulkiest on-chain
Dilithium has been standardized by NIST as ML-DSA in FIPS 204. Blockstream describes it as a transplant of Schnorr’s commit-challenge-response structure into module-lattice arithmetic.
Its main strength is simplicity. All operations are integer-based: ring arithmetic, matrix-vector multiplication, hashing and rounding. There is no floating-point math and no discrete Gaussian sampling. That makes it easier to write secure constant-time implementations. It is also the most widely deployed of the three candidates in software terms, already integrated into OpenSSL, BoringSSL, AWS-LC and Apple CryptoKit.
The cost is size. At level 3, ML-DSA-65 has a 1,952-byte public key and a 3,309-byte signature, for a combined 5,261 bytes. The report says that is about 55 times the total size of Bitcoin’s native public/private key plus signature footprint, and the largest package among the three candidates at comparable security.
For Bitcoin, Dilithium’s biggest attraction may be elsewhere. Blockstream says it is the only one of the three that comes close to BIP-32-style key derivation. A rerandomizable construction called DilithiumRK can derive child keys from parent keys using only public information. The report studies three variants, including a proposal from the authors called DilithiumRKS, where derivation stays entirely inside wallet software and the chain only needs a standard verifier for ordinary ML-DSA signatures.
Still, none of those variants is ready for deployment. Two require verifier changes. DilithiumRKS itself still lacks a full unforgeability proof. All of them rely on a matrix shared by the whole network; while formally secure under the Module-LWE assumption, that setup ties the safety of every key to a single instance. Blockstream’s verdict is that Dilithium-based public-key derivation remains proof-of-concept work for now.
Falcon: compact and fast to verify, but harder to sign safely
Falcon, selected by NIST under the name FN-DSA, is the most compact of the three in the report. At security level 1, Falcon-512 combines to 1,563 bytes for public key plus signature. At level 5, Falcon-1024 comes to 3,073 bytes. Blockstream notes that Falcon-1024, despite the higher security margin, is still smaller than level-3 Dilithium.
Its design is very different from Dilithium. Falcon uses an NTRU-lattice hash-and-sign approach. The signer’s private key is a short basis of a lattice; the message is hashed to a point in space; the signer then uses the short basis to find a nearby lattice vector. The point and that nearby vector together make up the signature. Verification checks that the vector belongs to the lattice and is close enough.
The hard part is doing that without leaking information about the basis. Earlier schemes such as GGH and NTRUSign chose nearby lattice points directly, and each signature leaked some geometric information. Falcon uses the GPV framework, sampling nearby vectors from a Gaussian distribution so that the sampled output is provably independent of the basis. That removes the leakage risk in theory, but makes the sampler much harder to implement.
The sampler is Falcon’s engineering weak point. It operates in the complex Fourier domain and needs floating-point arithmetic. Different processors, compilers and optimization settings can produce different floating-point outputs. Blockstream says that is not merely a compatibility issue. GPV’s security proof requires that a signer never output two different short vectors for the same digest; once the signature process is made deterministic, platform-specific floating-point rounding can violate that condition.
The report says there is a workable fix. Deterministic Falcon can replace hardware floating-point with integer simulation, making signatures identical across platforms. The tradeoff is a roughly 15x drop in signing speed and about a 2x slowdown in key generation.
Blockstream still sees that as acceptable for Bitcoin because verification is unaffected. Falcon verification is entirely integer-based, deterministic and the fastest among the candidates. That asymmetry matters: a wallet signs only when it spends, but every node must verify every signature. Paying a 15x cost on infrequent signing in exchange for deterministic cross-platform behavior and integer-only verification is, in the report’s view, a reasonable bargain. In other words, the floating-point issue is an engineering obstacle, not a fatal flaw.
The report flags two additional caveats. First, Falcon has no level-3 parameter set because of its structure, so the choice is level 1 or level 5 only. On security-margin grounds, Blockstream recommends Falcon-1024. Second, signing uses substantial memory. The 1024-parameter sampler depends on a precomputed tree that uses about 90 kilobytes of memory. A hardware wallet can rebuild that tree branch by branch and cut memory use to 16 kilobytes, but signing time then doubles. That is a real device-side cost, the report says, though still tolerable.
Hawk: the candidate that fell out of the race
Hawk originally tried to combine the advantages of the other two. Blockstream writes that Hawk-512 had a signature of only 555 bytes, smaller than Falcon, while using integer-only signing and as little as 6 kilobytes of memory. It was also the only lattice-based candidate left in round three of NIST’s additional signature competition, which is why the report had devoted substantial space to it.
Its tradeoff was in the assumptions. Hawk did not rely on the long-studied NTRU or SIS problems. Instead, it depended on the lattice isomorphism problem and the one-more-SVP assumption, both of which have a shorter research history.
Just before the report was finalized, Straznickas and Weis of Anthropic found a structural flaw in Hawk’s lattice construction. The dimension of the SVP problem actually needed for key recovery was only half of what the designers had assumed, sharply reducing the estimated security bits of the candidate parameter sets. The researchers completed a full end-to-end key recovery attack against HAWK-256, the cryptanalytic challenge parameter. Even so, the formal proposal’s HAWK-512 and HAWK-1024 were still not practically broken.
The Hawk team acknowledged the attack and withdrew the scheme from the NIST process. According to the report, the team said that if the flaw were patched by doubling parameters, Hawk would lose the size advantage that had made it appealing in the first place.
Blockstream kept Hawk in the report anyway because the attack targets algebraic properties of a specific number field rather than disproving the entire design family. Whether a redesign could avoid the flaw is still unclear. The episode, however, is used as direct evidence for the report’s conservative stance on security margins: a scheme can look efficient, fast and far along in standardization, and a single paper can still slash its estimated security level.
How the report frames the comparison set
The schemes in the comparison table, including SPHINCS+, are all stateless signatures, meaning the signer does not have to track prior signatures. By contrast, stateful hash-based signatures such as XMSS can make signatures smaller, but they require state management. The report points readers to a separate study for a fuller hash-based comparison.
What still blocks deployment
Falcon lacks a practical key-derivation method
Blockstream says the only public BIP-32-style Falcon derivation method rerandomizes the private-key basis, which drastically inflates the signature norm bound and pushes on-chain signatures to about 23.7 kilobytes. On top of that, the parameter choice in that construction does not meet its own security condition; fixing the issue would make the size even larger. The report calls the absence of a viable Falcon public-key derivation method one of the most valuable open problems in the field.
FN-DSA is not final yet
NIST has selected Falcon, but the FN-DSA draft has not been formally released. Blockstream argues that only after standardization is complete will audited implementations, test vectors and hardware support become widely available, all of which would lower the risk and difficulty of bringing Falcon into Bitcoin consensus. Its recommendation is to wait for the formal FN-DSA release; until then, Falcon remains a moving target.
Falcon-WS is smaller, but still exploratory
The report also looks at a Falcon-WS variant. By relaxing internal parameters and compensating with rejection sampling, it cuts total size to 1,114 bytes at level 1 and 2,387 bytes at level 5, smaller than baseline Falcon. Blockstream says that direction is worth studying, but it is outside the official standard path and needs more cryptanalysis. Existing research has already found a flaw in the strong unforgeability proof for a derived variant, though ordinary unforgeability is unaffected.
Other newer schemes are not deployment-ready either
The review asks whether something better may emerge. Outside the three main candidates, it points to the Fiat-Shamir family, beginning with BLISS in 2013. A more recent result presented by Gärtner at CRYPTO 2025 is said to rest on mature assumptions and to reach Falcon-like paper sizes.
But Blockstream says this family has long run into the same obstacle: implementation safety. BLISS was broken through a side-channel attack because its Gaussian sampling was not constant time. Later schemes have not fully removed that hazard, and the newest result indicates that defending the sampling step may be even harder. Until those problems are solved, the report sees them as theoretically attractive rather than deployable for Bitcoin.
Lattice signatures and hash-based signatures may complement each other
The report does not cast lattice signatures and hash-based signatures as a strict either-or choice. It says lattice signatures can be used inside hybrid constructions. In SHRINCS, for example, the stateless recovery path currently uses SPHINCS+ signatures measured in several kilobytes. Replacing that component with Falcon or Falcon-WS would shrink size and speed up verification, reducing the cost of a low-frequency recovery path while leaving the everyday path unchanged.
Bottom line: Falcon-1024 if a lattice choice had to be made now
Blockstream’s ranking is explicit. Hawk is out after the Anthropic attack. Dilithium has the lowest implementation complexity and is the only candidate with a meaningful base of key-derivation research, but its on-chain size is unattractive for Bitcoin. Falcon offers the best balance of compactness, fast verification and mature security assumptions, and its biggest weakness — floating-point work in signing — already has an engineering workaround.
The report’s conclusion is direct: if Bitcoin had to pick a lattice-based signature scheme today, Blockstream would choose Falcon-1024.
That is not the same as saying Bitcoin should switch immediately. For the present, Blockstream says its view remains aligned with its earlier hash-based-signature report: the conservative short-term route is still hash-based signatures because their security assumptions are the most mature and their overall risk is the lowest, making them better suited as a transition option. Once FN-DSA is finalized and stable specifications, audited codebases and hardware-wallet support are in place, Falcon could offer a meaningful improvement over purely hash-based signatures. A hybrid deployment model is also on the table, with the two families filling different roles.