Falcon (FN-DSA) relies on discrete gaussian sampling using constant-time floating point arithmetic for signers, which is very hard to implement quickly and in constant time (securely).
This is true for the first Falcon version published (randomized mode of operation). This implementation uses the author-recommended deterministic Falcon mode (see author’s notes) which uses software floating-point emulation . This eliminates side-channel risks associated with non-constant-time hardware FPUs. It is also SNARK-friendly and overcomes portability limitation. While this sacrifices the performance optimizations of true FPUs, signing speed is not critical in Bitcoin, where verification dominates node activity.
If small signatures are your goal, then I'd look into SQIsign
This would be good like many other PQ exotic schemes but all of these are far from being standardized soon.
If you want a PQC scheme that's ready today and also provides small signatures, I'll point you to XMSS, and Jonas Nick's SHRINCS proposal. You can configure an unbalanced XMSS tree to get 272 byte signatures, potentially smaller if you crank up the parameters. The catch is a dependence on statefulness.
SPHINCS+ cannot be considered a valid fallback as it introduces large signature overhead (it's not meant for bitcoin-like use-cases). Any TPM-based state management would reduce performance and compatibility across architectures. The hash-based nature of SHRINCS is highly SNARK-unfriendly, making them incompatible with emerging L2 ZK rollup constructions. Moreover in high-throughput L2 environments, state management, limits on the number of signatures and performance degradation proportional to published signatures are critical bottlenecks.
On Thu, 2026-01-22 at 14:35 +0000, conduition wrote:
Falcon (FN-DSA) relies on discrete gaussian sampling using constant-time floating point arithmetic for signers, which is very hard to implement quickly and in constant time (securely). Despite being significantly harder to implement than ML-DSA, it only provides a mild (factor of two or so) improvement in signature + pubkey size. This is why we're probably not including FN-DSA in our PQ signature opcode BIP following BIP360.
While I wouldn't rule out Falcon permanently, I personally feel more research is needed to explore Falcon, its weaknesses, and how flexibly it can be adapted to schemes like CISA, BIP32, and multisignatures. Let it bake a little longer.
If small signatures are your goal, then I'd look into SQIsign, which uses isogeny-based cryptography to produce very small sigs (148b) and pubkeys (65b) using some convoluted mathematical tricks. However, much like Falcon, it is still immature and needs more researchers to optimize its verification, explore its strengths, and attack its weaknesses.
If you want a PQC scheme that's ready today and also provides small signatures, I'll point you to XMSS, and Jonas Nick's SHRINCS proposal. You can configure an unbalanced XMSS tree to get 272 byte signatures, potentially smaller if you crank up the parameters. The catch is a dependence on statefulness.
regards,
conduition
On Wednesday, January 21st, 2026 at 11:09 PM, Giulio Golinelli <golinelli.giulio13@gmail.com> wrote:
Hi everyone,
I am to share a technical demonstration and benchmarking project that integrates the Falcon post-quantum signature scheme (Falcon-512) into Bitcoin Core, implemented as a soft-fork within the classic P2WPKH mode. This work aims to provide a practical reference for possible future Falcon adoption, especially as it approaches FIPS standardization.
You can find details at this fork.
Why Falcon?
Falcon is a lattice-based, post-quantum digital signature scheme designed to be secure against quantum attacks. Unlike other PQC candidates such as SPHINCS+ and ML-DSA, Falcon offers significantly smaller signature and public key sizes, as well as efficient signing and verification times. It is implemented in pure C and does not require external dependencies.
Benchmarking & Results
Aspect Falcon ECDSA
Public Key Size (B) 897 33
Signature Size (B) 655 71
Verification Time (μs) 57 120
Verification time is more critical than signature creation time in Bitcoin, since signature creation is performed by clients (wallets), while nodes focus on verification.
Integration
- Falcon was included into the codebase from the original GitHub repository.
- The build system (CMakeLists.txt) was updated to support Falcon.
- Falcon verification has been soft-fork enabled via a new script verification flag.
Next Steps & Reference
This project serves as a practical demonstration of Falcon’s promising performance, highlighting its advantages over currently selected post-quantum signature algorithms such as SPHINCS+ and ML-DSA, which face significant time and space limitations. As Falcon approaches FIPS standardization, this work aims to provide a reference for future adoption and integration in Bitcoin.
Let me know what you think and if this could be of interest for which case I can complement the project by integrating Falcon into all the other spending paths. I also look forward to development/integration corrections.
Best regards,
Giulio