Falcon, Dilithium, and the Fall of Hawk: Evaluating Lattice-Based Signatures for Bitcoin

Blockstream Research has published a full report on lattice-based signatures for Bitcoin. This post summarizes what we examined, what we found, and what we recommend. The report itself is available on ePrint.

Digital signatures are the core mechanism in Bitcoin that authorizes transactions, and the Schnorr and ECDSA signatures doing that job today are remarkably cheap. Shor showed in 1994 that a sufficiently large quantum computer breaks them. When such a machine will exist remains an active topic of discussion, but a credible deployment plan for post-quantum signatures is needed well before the answer matters.

Lattice-based signature schemes are among the strongest candidates to replace them. Lattices have been studied for over a century, their cryptographic applications for nearly three decades, and among the post-quantum families they promise combined signature and public key sizes starting below 1.6 kB, plus an algebraic structure that may eventually support multisignatures, threshold signing, and succinct proofs.

Our report studies the three schemes: Dilithium, Falcon, and Hawk. For each, we present the intuition behind the design, give a complete description of the algorithms, and analyze security, performance, and deployment aspects such as wallet key derivation, assuming no prior exposure to lattice cryptography.

This post condenses the findings: which of the three, if any, could actually go on-chain?

What We're Grading On

Bitcoin places its own restrictions on the choice of a signature scheme. Four criteria drive our evaluation:

On-chain cost. One of the most important metrics is the combined size of the public key and the signature, because both are recorded on-chain when an output is spent, and every byte is downloaded and stored by every full node. Verification cost matters for the same reason: each signature is verified by every node, so slow verification burdens the whole network.

Implementation complexity. An important question is how hard it is to implement the scheme securely. A design that needs floating-point arithmetic or delicate Gaussian sampling is a design that can leak its secret key through an implementation mistake or a side channel such as timing analysis. We want to aim for a smooth migration, and implementation complexity is a serious factor.

Deployment pitfalls. We should also consider the frictions a real Bitcoin integration would face: the consensus-critical choice of hash function (the candidates use SHAKE, Bitcoin uses SHA-256), reproducibility of signing across platforms, and whether the signer fits in the RAM budget of a hardware wallet.

Potential. Most Bitcoin wallets are hierarchical and deterministic (BIP 32): from a single master public key, a wallet derives an unbounded supply of child public keys without ever touching the secret key. None of the standardized post-quantum schemes supports this out of the box, so we examine what it would cost to add. We also look at modifications of the schemes, which are not standardized but might bring more benefits.

Which Security Level?

Before comparing sizes, we have to fix the target security level, and this choice is less obvious than it sounds. NIST defines security categories 1 through 5; higher categories provide stronger security, which in turn requires larger keys and signatures.

We argue that Bitcoin should aim for at least category 3. Outputs may remain unspent for decades, and if cryptanalytic progress pushes a scheme below its intended level, coins may be locked under weakened keys and stay vulnerable indefinitely. Lattice assumptions are not new (they have been under public cryptanalysis for close to three decades, longer than elliptic curves had accumulated when Bitcoin adopted them), but their rich algebraic structure leaves more surface for future attacks than we would like to bet the far future on.

Major deployers have reached the same conclusion. Apple omits Category 1 lattice parameters entirely from its iMessage PQ3 protocol, using Category 3 and 5 parameters throughout. Cloudflare deploys ML-KEM-768 (Category 3) in its post-quantum TLS rollout, noting that while Category 1 looks fine today, they prefer a margin against decades of future cryptanalysis. Bitcoin's horizon is longer than either.

The margin has its own price. For example, moving Dilithium from Category 2 to Category 3 adds about 1.5 kB to the combined size. Our report compares the parameter sets at all available security categories, so readers can assess the trade-offs themselves. Recent events, as we will see with Hawk, suggest the caution is not theoretical.

The Candidates

Dilithium: The Straightforward One

Dilithium (standardized by NIST as ML-DSA in FIPS 204) follows the same commitment–challenge–response template as Schnorr, translated into module-lattice arithmetic.

Its core feature is simplicity. Dilithium's operations are entirely integer-based: ring arithmetic, matrix-vector products, hashing, and rounding. There is no floating point and no discrete Gaussian sampling, which makes a secure, constant-time implementation much easier to get right. It is also the most widely adopted candidate, already shipping in OpenSSL, BoringSSL, AWS-LC, and Apple CryptoKit.

The price is size. At Category 3 (ML-DSA-65), the public key is 1,952 bytes and the signature 3,309 bytes (5,261 bytes combined), roughly 55 times Bitcoin's combined public key and signature size and the largest of the three candidates at every level.

Dilithium's most interesting feature for Bitcoin is that it is the only candidate with a near-practical approach to BIP 32-style key derivation. The rerandomizable-key construction DilithiumRK turns a parent key into a child key using public information only. The report analyzes three variants, including DilithiumRKS, a variant we propose in which the derivation logic lives entirely in wallet software and the chain sees plain ML-DSA signatures under the stock verifier. None of the three is ready to deploy: two require a verifier that deviates from the standard, our DilithiumRKS still lacks a completed unforgeability proof, and all rest on a network-wide shared matrix, a convention that is formally sound under Module-LWE but concentrates the security of every key on a single instance. We argue that at this stage public-key derivation solutions based on Dilithium are a proof of concept rather than a deployable option.

Falcon: The Compact One

Falcon, selected by NIST for standardization as FN-DSA, is the most compact of the three. At Category 1, Falcon-512 needs 1,563 bytes for public key and signature combined; at Category 5, Falcon-1024 needs 3,073 bytes. Falcon-1024, with a large security margin, is still smaller than Dilithium at Category 3.

Falcon takes a different route than Dilithium: hash-and-sign over NTRU lattices. The signer's secret is a short basis of a lattice; the message hashes to a point in space, and the signer uses the short basis to find a lattice vector close to that point. The pair (point, nearby vector) is the signature; verification only checks that the vector lies on the lattice and is close enough. The delicate part is finding that vector without leaking the basis: earlier schemes (GGH, NTRUSign) simply rounded to a nearby lattice point, and every signature leaked a little of its geometry. Falcon instead follows the GPV framework and samples the nearby vector from a Gaussian distribution whose output is provably independent of the basis, closing the leak at the price of a much more delicate sampler.

That sampler is Falcon's weak point in practice. It works in the Fourier domain over the complex numbers, which means floating-point arithmetic. Floating-point results can differ between processors, compilers, and even optimization flags. This is not just a portability nuisance but also a security problem: the GPV proof requires that a signer never release two different short vectors for the same digest, and platform-dependent rounding can violate exactly that once signing is derandomized. There is a solution: a deterministic Falcon implementation replaces hardware floating point with integer emulation, producing bit-identical signatures on every platform. Signing slows down by roughly 15×, and key generation by 2×.

Importantly, verification is untouched, because Falcon verification uses no floating point at all. Falcon's verification is integer-only, deterministic, and the fastest of all the candidates. This asymmetry is favorable for Bitcoin: an output is signed once, by one wallet, at spending time, while its signature is verified by every full node. A 15× penalty on the infrequent signing, in exchange for making it reproducible and integer-only, is in our view the right trade-off. We therefore regard the floating-point requirement as a manageable engineering concern rather than a blocker.

Two caveats. Due to structural requirements, Falcon does not have a Category 3 parameter set. The choice is only between Category 1 and Category 5. By the security-margin argument, we recommend Falcon-1024. The second caveat is that signing requires a significant amount of memory: the sampler is driven by a precomputed tree that occupies roughly 90 kB of RAM at the 1024 level. A hardware wallet can instead rebuild the tree branch-by-branch within about 16 kB, at the cost of roughly doubling signing time. Slower signing on a small device is a real cost, but arguably manageable.

Hawk: The Failed One

Hawk aimed to combine the advantages of the other two candidates: signatures even smaller than Falcon's (555 bytes at the 512 level), with a simple, integer-only signer that needs as little as 6 kB of RAM. It was the only lattice candidate remaining in the third round of NIST's additional-signatures competition, and a large part of our report is devoted to it.

The trade-off lay in its assumptions. Instead of NTRU and SIS (problems with decades of cryptanalysis behind them), Hawk's security rests on the Lattice Isomorphism Problem and the one-more-SVP assumption, both comparatively young.

Shortly before we finalized the report, Straznickas and Weis of Anthropic found a structural weakness in Hawk's lattice construction: key recovery in fact relied on solving SVP in a lattice of only about half the dimension the designers assumed. This cut tens of bits from the estimated key-recovery cost of the proposed parameter sets, and the authors demonstrated a full end-to-end key recovery against HAWK-256, the scheme's challenge parameter set intended for cryptanalysis (the proposed HAWK-512 and HAWK-1024 sets remain out of practical reach even after the attack). The Hawk team confirmed the attack and withdrew the scheme from NIST's process, noting that patching it by doubling parameters would erase the compactness that made Hawk attractive.

We retained the Hawk chapter in the report because the attack exploits a specific algebraic feature of the chosen number field rather than the design paradigm itself. Whether a redesign can avoid it is an open question. Hawk is also now the clearest available illustration of why we argue for conservative assumptions and a security margin. A scheme can be compact, fast, and three rounds deep into a standardization process, and still lose a significant portion of its estimated security to a single paper.

Scheme Sizes

All schemes in this table, SPHINCS+ included, are stateless: the signer keeps no record of past signatures. Stateful hash-based schemes such as XMSS achieve smaller signatures at the cost of managing that state; see the hash-based report for that comparison.

What Keeps This from Being a Done Deal

No key derivation for Falcon. The single published construction for BIP 32-style derivation on Falcon rerandomizes the secret basis, which inflates the signature-norm bound by a huge factor, blowing the on-chain signature up to roughly 23.7 kB. Worse, its proposed parameters fall short of the scheme's own security condition, and repairing them drives sizes further up. There is currently no workable public-key derivation for Falcon; we consider this one of the most interesting open problems the report identifies.

The Falcon standard is not final. NIST selected Falcon, but the FN-DSA draft has not yet been published. Standardization is what brings audited implementations, test vectors, and hardware support. The wide adoption makes a consensus-critical integration easier and safer. We argue that it makes sense to wait for the Falcon standard to be published: until then, Falcon is a moving target.

Falcon-WS. A recent variant relaxes one internal parameter and compensates with rejection sampling, bringing the combined size down to 1,114 bytes at Category 1 and 2,387 bytes at Category 5. This is noticeably below plain Falcon. We view it as a genuinely promising direction, with the standard caveat for young schemes: it will likely not be in the standard, and it needs more cryptanalysis. A gap has already been found in the strong-unforgeability proof of a follow-up work (plain unforgeability is unaffected).

Could a better scheme still appear? The most promising known direction beyond the schemes above is the Fiat-Shamir line that began with BLISS in 2013, whose newest member (a CRYPTO 2025 scheme by Gärtner, covered in our report) reaches sizes competitive with Falcon under well-studied assumptions. What has kept this line out of practice is implementation security: BLISS was broken through side channels in its non-constant-time Gaussian sampling, and no later scheme in the line resolves this. The newest one warns that its sampling may be even harder to protect. Until that changes, we see these schemes as attractive on paper rather than deployable.

Lattices and hashes are complementary. A lattice scheme can also serve as one component of a hybrid scheme. In SHRINCS, the stateless recovery path is currently a SPHINCS+ signature of several kilobytes; for example a Falcon (or Falcon-WS) signature in that slot is far smaller and faster to verify, making the infrequent fallback much cheaper while leaving the everyday path untouched.

Our Conclusion

Among the lattice candidates, the ranking is unambiguous. Hawk is withdrawn after the Anthropic attack. Dilithium is the easiest to implement and the only one with a key-derivation story, but its sizes are hard to justify for Bitcoin. Falcon offers the best combination of compactness, verification speed, and mature assumptions, and its main drawback (floating-point signing) has a known, practical mitigation. If we had to select a lattice-based signature scheme for Bitcoin today, we would choose Falcon-1024.

For today, our views are unchanged from the hash-based report: the conservative near-term option remains a hash-based scheme, which relies on the most mature assumptions and carries minimal risk. This may well be a transitional phase for Bitcoin. Once FN-DSA is finalized, bringing a fixed specification, audited libraries, and hardware support, Falcon could improve on purely hash-based signatures substantially, and a hybrid deployment lets the two families complement each other.

The full report, including complete algorithm descriptions, security analyses, parameter derivations, and the wallet-derivation constructions, with no prior exposure to lattice cryptography assumed, is available on ePrint. Questions and feedback are welcome, and we hope the report provides a useful starting point for further work on the open problems identified above.

Follow Blockstream Research on X and subscribe to our newsletter for future posts in this series.