Blockstream Research has published a full report on lattice-based signatures for Bitcoin and reached a clear bottom line: if Bitcoin had to pick a lattice-based post-quantum signature scheme today, the choice would be Falcon-1024.
The report, written by the Blockstream Team and translated by Saoirse and Foresight News, looks at a long-range problem for Bitcoin. Schnorr and ECDSA signatures are cheap today, but Shor showed in 1994 that sufficiently powerful quantum computers could break both. The timing of that threat remains debated, yet the report argues that a workable migration plan has to exist before the threat arrives.
Why lattice signatures are under review
Lattice cryptography has more than a century of research history behind it, and its cryptographic applications have been developed for nearly 30 years. In the post-quantum setting, lattice signatures are attractive because their public keys and signatures can be relatively compact, in some cases below 1.6 kilobytes in total, and because their algebraic structure may eventually support multisignatures, threshold signatures, and concise proofs.
The report focuses on three schemes: Dilithium, Falcon, and Hawk. It explains how they are designed, walks through their algorithms, and compares them across security, performance, and deployment concerns such as wallet key derivation. The central question is practical rather than academic: which of these schemes could actually be deployed on Bitcoin?
Four criteria matter for Bitcoin
Blockstream evaluates the candidates against four constraints specific to Bitcoin.
- On-chain cost: Public keys and signatures are recorded on-chain when outputs are spent, so every byte must be downloaded and stored by full nodes. Verification cost matters as well because every signature is checked across the network.
- Implementation complexity: A scheme has to be implemented safely. If it relies on floating-point arithmetic or delicate Gaussian sampling, errors or timing side channels can leak private keys.
- Deployment risk: Integration raises real-world issues beyond cryptographic design, including hash function choices at the consensus layer, reproducibility across platforms, and whether signing software fits within hardware wallet memory limits.
- Development potential: Most Bitcoin wallets use BIP-32 hierarchical deterministic derivation, where one master public key can derive many child public keys without exposing the private key. Standardized post-quantum signatures do not natively support this, so the report examines the cost of adding that ability.
Blockstream argues for at least NIST level 3 security
Before comparing sizes, the report asks what security level Bitcoin should target. NIST defines levels 1 through 5. Higher levels bring stronger security, but they also increase key and signature sizes.
Blockstream argues that Bitcoin should adopt at least level 3 security. The reason is simple: Bitcoin outputs can remain unspent for decades. If advances in cryptanalysis reduce the effective strength of a scheme over time, funds may end up protected by keys that no longer have the margin people expected when they were created.
The report notes that lattice assumptions have already faced nearly 30 years of public cryptanalysis, longer than the body of research that existed when Bitcoin moved onto elliptic-curve cryptography. Even so, the algebraic structure of lattices leaves room for future breakthroughs, so the report argues against placing a decades-long security bet on minimal margins.
It points to similar choices elsewhere. Apple’s iMessage PQ3 protocol skips level 1 lattice parameters and uses levels 3 and 5 throughout. Cloudflare, in its post-quantum TLS deployment, uses ML-KEM-768, a level 3 parameter set, saying that even if level 1 appears safe today, a margin is needed for decades of future cryptanalysis. Bitcoin, the report says, has to think on an even longer horizon.
That margin has a cost. As one example, moving Dilithium from level 2 to level 3 adds about 1.5 kilobytes in total size. Hawk’s later setback is used in the report as evidence that conservative parameter choices are more than a theoretical preference.
Dilithium: simple design, but expensive on-chain
Dilithium has been standardized by NIST as ML-DSA in FIPS 204. It adapts the commit-challenge-response structure familiar from Schnorr signatures to module-lattice arithmetic.
Its biggest strength is simplicity. Dilithium uses only integer operations: ring arithmetic, matrix-vector multiplication, hashing, and rounding. It does not require floating-point arithmetic or discrete Gaussian sampling, which makes constant-time, side-channel-resistant implementations easier to build. It is also the most widely deployed of the candidates, with integrations in OpenSSL, BoringSSL, AWS-LC, and Apple CryptoKit.
The tradeoff is size. At level 3 security, ML-DSA-65 has a 1,952-byte public key and a 3,309-byte signature, for a total of 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 makes Dilithium the largest of the three candidates at comparable security strength.
For Bitcoin, the most notable point in Dilithium’s favor is that it is the only one of the three schemes that comes close to enabling BIP-32-style key derivation. The report discusses a rerandomizable key construction called DilithiumRK, where child keys can be generated from parent keys using only public information. It also analyzes three variants, including DilithiumRKS, proposed by the authors, where the derivation logic stays entirely inside wallet software and the chain only needs a standard verifier for ordinary ML-DSA signatures.
Still, the report does not consider any of those variants ready for deployment. Two require verifier changes. DilithiumRKS lacks a complete unforgeability proof. All of them depend on a single shared matrix across the network; while that remains formally secure under the Module-LWE assumption, it ties the security of all keys to the same global instance. Blockstream’s conclusion is that Dilithium-based public key derivation is still at the proof-of-concept stage.
Falcon: compact, fast to verify, and the report’s preferred candidate
Falcon was selected by NIST under the name FN-DSA, and among the three it is the most compact. At level 1, Falcon-512 has a combined public key and signature size of 1,563 bytes. At level 5, Falcon-1024 comes in at 3,073 bytes. The report highlights a striking comparison: Falcon-1024, despite its higher security margin, is still smaller than level 3 Dilithium.
Falcon works differently from Dilithium. It is built on an NTRU-lattice hash-and-sign construction. The signer’s private key is a short basis of the lattice. A message is hashed to a point in space, and the signer uses the short basis to find a lattice vector close to that point. The point and that nearby vector together form the signature. Verification checks only that the vector belongs to the lattice and lies close enough.
The difficulty is making sure that this process does not leak information about the basis. Earlier schemes such as GGH and NTRUSign selected nearby lattice points directly, and each signature leaked some geometric information. Falcon uses the GPV framework, sampling nearby vectors from a Gaussian distribution so the output can be proved independent of the basis. That fixes the leakage problem in theory, but it makes the sampler much harder to implement safely.
For Blockstream, the sampler is Falcon’s main engineering weakness. It operates in the complex Fourier domain and needs floating-point arithmetic. Different processors, compilers, and optimization settings can produce different floating-point outputs. The report treats this as more than a compatibility issue. GPV security requires that for a given digest, the signer must not emit two different short vectors. If the scheme is made deterministic, platform-specific rounding differences can violate that requirement.
Blockstream does not see that as a fatal flaw. The report says deterministic Falcon can replace hardware floating point with integer emulation and produce identical signatures across platforms. The cost is significant: signing becomes about 15 times slower, and key generation becomes about 2 times slower.
That cost is acceptable in Bitcoin’s setting, the report says, because verification is unaffected. Falcon verification uses only integer arithmetic, produces deterministic results, and is the fastest among the candidates. Bitcoin signatures are created once by a wallet when spending, but they are verified by the entire network. In that asymmetry, a 15x slowdown for the signer is a low-frequency cost; fast, reproducible verification is the more important property.
Two caveats remain. First, Falcon has no level 3 parameter set, only level 1 and level 5. On security margin grounds, the report recommends Falcon-1024. Second, signing uses substantial memory. The sampler for the 1024-parameter set depends on a precomputed tree that takes about 90 kilobytes. Hardware wallets can rebuild that tree branch by branch and cut memory use to 16 kilobytes, but signing time then doubles. The report describes this as a real deployment cost, though still a manageable one.
Hawk: strong size numbers, then a late collapse
Hawk aimed to combine the best features of the other two approaches. Hawk-512 has a 555-byte signature, smaller than Falcon, and its signing path uses only integer arithmetic with a minimum memory footprint of 6 kilobytes. It was also the only lattice-based candidate to survive into the third round of NIST’s additional signatures competition, which is why the report devoted substantial space to it.
The problem lay in its assumptions. Hawk does not rely on NTRU or SIS, two problems with decades of cryptanalytic attention. Instead, it depends on the lattice isomorphism problem and the one-more-SVP assumption, both of which have shorter research histories.
Just before the report was finalized, Anthropic researchers Straznickas and Weis found a structural flaw in Hawk’s lattice construction. The flaw meant that key recovery required solving an SVP instance in only half the dimension assumed by the designers, sharply reducing the key-recovery security of the candidate parameter sets. The researchers completed a full end-to-end key recovery attack against the cryptanalytic challenge parameter HAWK-256.
The report notes that the formal proposal’s HAWK-512 and HAWK-1024 parameters still could not be broken in practice under the same attack. Even so, the Hawk team acknowledged the result and withdrew the scheme from the NIST process. According to the report, the team said that fixing the issue by doubling parameters would wipe out Hawk’s original size advantage.
Blockstream kept the Hawk section because the attack targets algebraic properties of a specific number field rather than invalidating the entire design direction. Whether a redesign can avoid the issue remains unresolved. For the authors, Hawk serves as a concrete lesson in why conservative security margins matter: even a scheme with good size, good speed, and multiple rounds of standardization behind it can lose a large part of its expected security from a single paper.
Deployment barriers remain
The report says all schemes in its comparison table, including SPHINCS+, are stateless signatures, meaning the signer does not need to keep track of past signatures. Stateful hash-based signatures such as XMSS can reduce signature size further, but they require state management and belong to a different tradeoff space.
As for lattice signatures on Bitcoin, several obstacles still stand out.
Falcon still lacks a usable key derivation method
This is one of the report’s most important unresolved issues. The only public BIP-32-style Falcon derivation method rerandomizes the private basis, which sharply increases the signature norm bound and inflates on-chain signatures to about 23.7 kilobytes. The parameter set in that proposal also fails to meet its own security condition; fixing that would make the size even worse. The report says there is currently no viable implementation of Falcon public key derivation.
The FN-DSA standard is not final
Although NIST selected Falcon, the FN-DSA draft has not yet been officially released. Blockstream recommends waiting until the standard is finalized, because that is when audited implementations, test vectors, and hardware support are more likely to arrive. Wider deployment would lower the risk and complexity of integrating Falcon at Bitcoin’s consensus layer.
Falcon-WS is promising, but not standard
The report also discusses Falcon-WS, a variant that relaxes internal parameters and compensates with rejection sampling. It reduces total size to 1,114 bytes at level 1 and 2,387 bytes at level 5, both below standard Falcon. Blockstream says the direction is worth studying, but it will not be part of the official standard and still needs more cryptanalysis. Existing work has already found a flaw in the strong unforgeability proof of a related variant, though ordinary unforgeability is unaffected.
Other directions and hybrid use
The report also looks beyond those three schemes. It mentions the Fiat-Shamir family, starting with BLISS in 2013 and extending to work presented by Gärtner at CRYPTO 2025. On paper, those newer constructions can match Falcon’s size while relying on mature assumptions.
But the same old implementation problem remains. BLISS was broken through a side channel because Gaussian sampling was not constant-time. Later schemes have not fully removed that risk, and the newest results suggest the protection problem around sampling is even harder. Until that changes, the report says these constructions are attractive in theory but unsuitable for deployment.
It also argues that lattice signatures and hash-based signatures can complement each other. In SHRINCS, for example, the stateless recovery path currently uses SPHINCS+ signatures that run to several kilobytes. Replacing those with Falcon or Falcon-WS would reduce size and speed up verification, cutting costs on a low-frequency recovery path while leaving everyday usage unchanged.
Bottom line
Blockstream’s ordering of the candidates is straightforward. Hawk has effectively dropped out after the Anthropic attack. Dilithium is the easiest to implement and the only one with a meaningful research base for key derivation, but its on-chain footprint is heavy. Falcon offers the best balance of compact size, fast verification, and more established security assumptions, and its biggest weakness on the signing side already has an engineering workaround.
That is why the report says Falcon-1024 would be the lattice-based scheme to choose if a decision had to be made now.
For the near term, however, Blockstream keeps the same broader position it took in its hash-based signature report: the conservative path for Bitcoin is still hash-based signatures. Their assumptions are the most mature and the risk is lower, making them better suited as a transition option. Once FN-DSA is finalized and supported by stable specifications, audited code, and hardware wallets, Falcon may offer a meaningful improvement over pure hash-based signatures. A hybrid deployment, where the two families complement each other, remains another option.