* [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal @ 2026-01-22 7:01 Giulio Golinelli 2026-01-22 12:48 ` [bitcoindev] " waxwing/ AdamISZ 2026-01-22 14:35 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List 0 siblings, 2 replies; 13+ messages in thread From: Giulio Golinelli @ 2026-01-22 7:01 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2543 bytes --] 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 <https://github.com/thisisnotgcsar/bitcoin-falcon>. *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 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/16e01530-e9dd-481f-8c7f-ca9ccafcfcden%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 3153 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* [bitcoindev] Re: Falcon Post-Quantum Signature Scheme Proposal 2026-01-22 7:01 [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal Giulio Golinelli @ 2026-01-22 12:48 ` waxwing/ AdamISZ 2026-01-23 3:45 ` Giulio Golinelli 2026-01-22 14:35 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List 1 sibling, 1 reply; 13+ messages in thread From: waxwing/ AdamISZ @ 2026-01-22 12:48 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3646 bytes --] Thanks for the report! Forgive the rather ignorant question here, but: Given the obvious that we have a problem with size on-chain (and I'm aware you've focused here specifically on the most plausible scheme that has the least ridiculously large size, and yet it's still 20x larger), has there been comparison of the possibility of batched signing (not batched *verification*, but signing) in different PQ schemes, with a view to a CISA like approach to transactions in a future with much larger keys and sigs? A nice side effect might be a pure economic motivation for much better fungibility (coinjoin becoming much more desirable for the base layer, albeit I think it's in higher layers where we are/will be get(ting) most privacy). A cursory search tells me that Falcon specifically can't support any kind of batched signing, but I have no idea whether that's correct. Cheers, AdamISZ/waxwing On Thursday, January 22, 2026 at 4:09:34 AM UTC-3 Giulio Golinelli 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 > <https://github.com/thisisnotgcsar/bitcoin-falcon>. > > *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 -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-0933f41ff398n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 4658 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Re: Falcon Post-Quantum Signature Scheme Proposal 2026-01-22 12:48 ` [bitcoindev] " waxwing/ AdamISZ @ 2026-01-23 3:45 ` Giulio Golinelli 0 siblings, 0 replies; 13+ messages in thread From: Giulio Golinelli @ 2026-01-23 3:45 UTC (permalink / raw) To: waxwing/ AdamISZ; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 6398 bytes --] Hi Adam, thanks a lot for the thoughtful question — it’s definitely not ignorant at all, and it touches one of the core reasons Schnorr ended up being such a good fit for Bitcoin. What you’re referring to is technically called signature aggregation, which is distinct from batch verification. Signature aggregation relies on a linear homomorphic algebraic structure that is inherent to Schnorr signatures, and it’s precisely this property that enables constructions like MuSig. Unfortunately, this kind of structure is not something we get across the post-quantum signature landscape (whether standardized or exotic schemes). L2 ZK rollups can mitigate this by verifying many user signatures off- chain and proving the resulting state transition with a single succinct proof, effectively collapsing many verifications into one on L1. In a post-quantum setting, LaBRADOR ([https://eprint.iacr.org/2022/1341.pdf](https://eprint.iacr.org/2022/1341.pdf) ), a lattice-based SNARK could be adopted. Bitcoin-oriented ZK rollups along these lines, such as Citrea, already explore this approach. My current view is that L2 ZK constructions may be a key part of the toolbox to mitigate the absence of aggregation and efficient batching — at least until we discover a PQ signature scheme with Schnorr-like advantages. Considering it took roughly 30 years from RSA to reach Schnorr, we should expect that fully realizing such a post-quantum analogue will likely take several years of research and development. Very happy to hear your thoughts on this, and thanks again for raising the point. I’m still relatively new to Bitcoin, so if I’ve made any incorrect assumptions here, please feel free to correct me. Best regards, Giulio On Thu, 2026-01-22 at 04:48 -0800, waxwing/ AdamISZ wrote: > Thanks for the report! > > Forgive the rather ignorant question here, but: > > Given the obvious that we have a problem with size on-chain (and I'm > aware you've focused here specifically on the most plausible scheme > that has the least ridiculously large size, and yet it's still 20x > larger), has there been comparison of the possibility of batched > signing (not batched *verification*, but signing) in different PQ > schemes, with a view to a CISA like approach to transactions in a > future with much larger keys and sigs? A nice side effect might be a > pure economic motivation for much better fungibility (coinjoin > becoming much more desirable for the base layer, albeit I think it's > in higher layers where we are/will be get(ting) most privacy). > > A cursory search tells me that Falcon specifically can't support any > kind of batched signing, but I have no idea whether that's correct. > > Cheers, > AdamISZ/waxwing > > > On Thursday, January 22, 2026 at 4:09:34 AM UTC-3 Giulio Golinelli > 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 [1]. > > > > 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 > -- > You received this message because you are subscribed to a topic in > the Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/PsClmK4Em1E/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-0933f41ff398n%40googlegroups.com > [2]. [1] this fork https://github.com/thisisnotgcsar/bitcoin-falcon [2] https://groups.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-0933f41ff398n%40googlegroups.com https://groups.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-0933f41ff398n%40googlegroups.com?utm_medium=email&utm_source=footer -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e13546d438e0b871b8d6a4b449ce5c27b47cb765.camel%40gmail.com. [-- Attachment #2: Type: text/html, Size: 8792 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-22 7:01 [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal Giulio Golinelli 2026-01-22 12:48 ` [bitcoindev] " waxwing/ AdamISZ @ 2026-01-22 14:35 ` 'conduition' via Bitcoin Development Mailing List 2026-01-23 7:12 ` Giulio Golinelli 1 sibling, 1 reply; 13+ messages in thread From: 'conduition' via Bitcoin Development Mailing List @ 2026-01-22 14:35 UTC (permalink / raw) To: Giulio Golinelli; +Cc: Bitcoin Development Mailing List [-- Attachment #1.1.1: Type: text/plain, Size: 4468 bytes --] 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. https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles 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 > > -- > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/16e01530-e9dd-481f-8c7f-ca9ccafcfcden%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/qmJtMusWT649HfvfUWJJn8dIP7vcJ-xI4bLEXnb-1saPcgmC4as1sSSOpshVGrx2Aj-9X0McB97slaYO286jS7-4N_ROqXtbNDdCrbcEnX0%3D%40proton.me. [-- Attachment #1.1.2.1: Type: text/html, Size: 6888 bytes --] [-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --] [-- Type: application/pgp-keys, Size: 649 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 343 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-22 14:35 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List @ 2026-01-23 7:12 ` Giulio Golinelli 2026-01-23 15:36 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List 2026-01-27 16:39 ` 'conduition' via Bitcoin Development Mailing List 0 siblings, 2 replies; 13+ messages in thread From: Giulio Golinelli @ 2026-01-23 7:12 UTC (permalink / raw) To: conduition; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 6444 bytes --] > 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 [1]) 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 [2] 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 > [3]. 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. > > https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles > > 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 [2], > 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 > [3]. 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 [4]. > > > > 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 [1] author’s notes https://github.com/algorand/falcon/blob/main/falcon-det.pdf [2] SQIsign https://sqisign.org/ [3] Jonas Nick's SHRINCS proposal https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158 [4] this fork https://github.com/thisisnotgcsar/bitcoin-falcon -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com. [-- Attachment #2: Type: text/html, Size: 10477 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-23 7:12 ` Giulio Golinelli @ 2026-01-23 15:36 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List 2026-01-24 13:04 ` waxwing/ AdamISZ 2026-01-24 13:31 ` Giulio Golinelli 2026-01-27 16:39 ` 'conduition' via Bitcoin Development Mailing List 1 sibling, 2 replies; 13+ messages in thread From: 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-01-23 15:36 UTC (permalink / raw) To: Giulio Golinelli; +Cc: conduition, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 8585 bytes --] Hi everyone, I am happy that the discussion on the PQ topic is active. I wanted to add my view on the raised issues. For the fallback in SHRINCS, one option is to use SPHINCS+ as a fallback with a limited number of signatures. By setting an upper bound as large as 2^30 or 2^40, the signature size can be significantly reduced, and the scheme would only be invoked in exceptional circumstances. In most realistic scenarios, the fallback would consist of generating a single signature to move assets to a new address. As for the statefulness problems, I agree that this is an important drawback that we should keep in mind. The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK settings. But one could replace the hash functions with SNARK-friendly alternatives (for example, Poseidon) in the future, which will make it much, much more efficient. It is also a question: how much weight should we put on adopting an explicitly SNARK-friendly signature scheme? While such compatibility is clearly advantageous, it does not seem to me to be a decisive point on its own. What would you say? I am also unsure to what extent Falcon can be considered SNARK-friendly. Has there been any research in this direction, or are there benchmarks evaluating its performance in SNARK environments? Finally, regarding SQIsign: although the signature sizes are remarkable, I agree that we need more time for the scheme to mature before considering adoption. Best, Mike On Fri, Jan 23, 2026 at 3:03 PM Giulio Golinelli < golinelli.giulio13@gmail.com> 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). > > 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 > <https://github.com/algorand/falcon/blob/main/falcon-det.pdf>) 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 > <https://sqisign.org/> > > 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 > <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. > 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. > > > https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles > > 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 > <https://sqisign.org/>, 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 > <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. > 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 > <https://github.com/thisisnotgcsar/bitcoin-falcon>. > > *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 > > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com > <https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPcK4uSY_fz9jGb8QrL7j4giqq2pGZ6K%3DCuPOzjQdqoMZgYPAw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 12970 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-23 15:36 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-01-24 13:04 ` waxwing/ AdamISZ 2026-01-25 21:54 ` cassio gusson 2026-01-24 13:31 ` Giulio Golinelli 1 sibling, 1 reply; 13+ messages in thread From: waxwing/ AdamISZ @ 2026-01-24 13:04 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 10991 bytes --] Hi Mike, > It is also a question: how much weight should we put on adopting an explicitly SNARK-friendly signature scheme? While such compatibility is clearly advantageous, it does not seem to me to be a decisive point on its own. What would you say? Does it depend on what we really mean by SNARK, apart from the literal definition? What SNARK schemes are we thinking of that are post quantum? I presume I can say "all the pairings based SNARKs (and the DLOG based ones) are not quantum resistant". Are STARKs the only realistic option in this scenario? I am enormously ignorant about STARKs, but I do seem to recall that they have large proofs, so at least in theory that's a problem for such planning? Or maybe there's another PQ SNARK scheme that I'm just unaware of. I guess this is orthogonal to the point you're raising about arithmetic-circuit friendly hash functions like Poseidon, though. That part I find a bit brain-melting because: what mechanism is assumed to exist to translate a STARK or SNARK proof into an onchain effect? If there was say a STARK op-code then, job done. You'd just somehow have to have sufficiently small STARK proofs which is AIUI not trivial, even with nice hash functions. If not, we're back to the current hyper-sophisticated scenarios of things like Glock and BABE where you use garbled circuits, witness encryption, and also need something like the adaptor primitive of "swap signature for secret" which we currently get kind of "for free" in Schnorr with the linearity. I suppose there might be alternatives (e.g. HTLC instead of PTLC) that might be more clunky, but viable. And all of that is of course "fraud proof" style, with "slashing", and not anywhere near as clean a design as "just verify the STARK". How does one take the 10000ft view on this needed to make a design decision? Obviously I don't know, at all, just raising points here. I guess the most interesting one is: "is STARK realistically the only game in town here?". Cheers, AdamISZ/waxwing On Friday, January 23, 2026 at 1:34:36 PM UTC-3 Mikhail Kudinov wrote: > Hi everyone, > I am happy that the discussion on the PQ topic is active. I wanted to add > my view on the raised issues. > > For the fallback in SHRINCS, one option is to use SPHINCS+ as a fallback > with a limited number of signatures. By setting an upper bound as large as > 2^30 or 2^40, the signature size can be significantly reduced, and the > scheme would only be invoked in exceptional circumstances. In most > realistic scenarios, the fallback would consist of generating a single > signature to move assets to a new address. As for the statefulness > problems, I agree that this is an important drawback that we should keep in > mind. > > The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK > settings. But one could replace the hash functions with SNARK-friendly > alternatives (for example, Poseidon) in the future, which will make it > much, much more efficient. > > It is also a question: how much weight should we put on adopting an > explicitly SNARK-friendly signature scheme? While such compatibility is > clearly advantageous, it does not seem to me to be a decisive point on its > own. What would you say? > I am also unsure to what extent Falcon can be considered SNARK-friendly. > Has there been any research in this direction, or are there benchmarks > evaluating its performance in SNARK environments? > > Finally, regarding SQIsign: although the signature sizes are remarkable, I > agree that we need more time for the scheme to mature before considering > adoption. > > Best, > Mike > > On Fri, Jan 23, 2026 at 3:03 PM Giulio Golinelli <golinelli...@gmail.com> > 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). >> >> 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 >> <https://github.com/algorand/falcon/blob/main/falcon-det.pdf>) 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 >> <https://sqisign.org/> >> >> 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 >> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >> 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. >> >> >> https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles >> >> 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 >> <https://sqisign.org/>, 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 >> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >> 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...@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 >> <https://github.com/thisisnotgcsar/bitcoin-falcon>. >> >> *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 >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com >> <https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 17615 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-24 13:04 ` waxwing/ AdamISZ @ 2026-01-25 21:54 ` cassio gusson 2026-01-26 10:33 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List 0 siblings, 1 reply; 13+ messages in thread From: cassio gusson @ 2026-01-25 21:54 UTC (permalink / raw) To: waxwing/ AdamISZ; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 12085 bytes --] hey guys I don't know if this is important for the implementation being discussed, but I think the study that identified a flaw in quantum key distribution (QKD) is worthwhile. https://ieeexplore.ieee.org/document/11223709 Best regards Cássio Gusson Em sáb., 24 de jan. de 2026 às 17:12, waxwing/ AdamISZ <ekaggata@gmail.com> escreveu: > Hi Mike, > > > It is also a question: how much weight should we put on adopting an > explicitly SNARK-friendly signature scheme? While such compatibility is > clearly advantageous, it does not seem to me to be a decisive point on its > own. What would you say? > > Does it depend on what we really mean by SNARK, apart from the literal > definition? > What SNARK schemes are we thinking of that are post quantum? I presume I > can say "all the pairings based SNARKs (and the DLOG based ones) are not > quantum resistant". Are STARKs the only realistic option in this scenario? > I am enormously ignorant about STARKs, but I do seem to recall that they > have large proofs, so at least in theory that's a problem for such planning? > > Or maybe there's another PQ SNARK scheme that I'm just unaware of. > > I guess this is orthogonal to the point you're raising about > arithmetic-circuit friendly hash functions like Poseidon, though. That part > I find a bit brain-melting because: what mechanism is assumed to exist to > translate a STARK or SNARK proof into an onchain effect? If there was say a > STARK op-code then, job done. You'd just somehow have to have sufficiently > small STARK proofs which is AIUI not trivial, even with nice hash > functions. If not, we're back to the current hyper-sophisticated scenarios > of things like Glock and BABE where you use garbled circuits, witness > encryption, and also need something like the adaptor primitive of "swap > signature for secret" which we currently get kind of "for free" in Schnorr > with the linearity. I suppose there might be alternatives (e.g. HTLC > instead of PTLC) that might be more clunky, but viable. And all of that is > of course "fraud proof" style, with "slashing", and not anywhere near as > clean a design as "just verify the STARK". > > How does one take the 10000ft view on this needed to make a design > decision? Obviously I don't know, at all, just raising points here. I guess > the most interesting one is: "is STARK realistically the only game in town > here?". > > Cheers, > AdamISZ/waxwing > On Friday, January 23, 2026 at 1:34:36 PM UTC-3 Mikhail Kudinov wrote: > >> Hi everyone, >> I am happy that the discussion on the PQ topic is active. I wanted to add >> my view on the raised issues. >> >> For the fallback in SHRINCS, one option is to use SPHINCS+ as a fallback >> with a limited number of signatures. By setting an upper bound as large as >> 2^30 or 2^40, the signature size can be significantly reduced, and the >> scheme would only be invoked in exceptional circumstances. In most >> realistic scenarios, the fallback would consist of generating a single >> signature to move assets to a new address. As for the statefulness >> problems, I agree that this is an important drawback that we should keep in >> mind. >> >> The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK >> settings. But one could replace the hash functions with SNARK-friendly >> alternatives (for example, Poseidon) in the future, which will make it >> much, much more efficient. >> >> It is also a question: how much weight should we put on adopting an >> explicitly SNARK-friendly signature scheme? While such compatibility is >> clearly advantageous, it does not seem to me to be a decisive point on its >> own. What would you say? >> I am also unsure to what extent Falcon can be considered SNARK-friendly. >> Has there been any research in this direction, or are there benchmarks >> evaluating its performance in SNARK environments? >> >> Finally, regarding SQIsign: although the signature sizes are remarkable, >> I agree that we need more time for the scheme to mature before considering >> adoption. >> >> Best, >> Mike >> >> On Fri, Jan 23, 2026 at 3:03 PM Giulio Golinelli <golinelli...@gmail.com> >> 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). >>> >>> 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 >>> <https://github.com/algorand/falcon/blob/main/falcon-det.pdf>) 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 >>> <https://sqisign.org/> >>> >>> 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 >>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>> 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. >>> >>> >>> https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles >>> >>> 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 >>> <https://sqisign.org/>, 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 >>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>> 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...@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 >>> <https://github.com/thisisnotgcsar/bitcoin-falcon>. >>> >>> *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 >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to bitcoindev+...@googlegroups.com. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com >>> <https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- --- Abraços Cássio Gusson -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 17515 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-25 21:54 ` cassio gusson @ 2026-01-26 10:33 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List 2026-01-26 15:21 ` waxwing/ AdamISZ 0 siblings, 1 reply; 13+ messages in thread From: 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-01-26 10:33 UTC (permalink / raw) To: cassio gusson; +Cc: waxwing/ AdamISZ, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 13576 bytes --] The investigation of Lattice-Based approaches is on the table, so I think we will be able to make a thoughtful comparison at some point. I support the idea that SNARK/STARK-friendliness can not be a crucial point, as it is not currently supported, but can be an argument for tie-breaking cases. All pairing-based schemes are broken by a quantum computer, yes. STARKs are plausibly post-quantum. There are some schemes based on Lattices as well. The QKD problems are not important for our discussion; they do not affect PQ transition. Best, Mike On Sun, Jan 25, 2026 at 11:44 PM cassio gusson <cassio.gusson@gmail.com> wrote: > hey guys > > I don't know if this is important for the implementation being discussed, > but I think the study that identified a flaw in quantum key distribution > (QKD) is worthwhile. > > https://ieeexplore.ieee.org/document/11223709 > > Best regards > Cássio Gusson > > Em sáb., 24 de jan. de 2026 às 17:12, waxwing/ AdamISZ <ekaggata@gmail.com> > escreveu: > >> Hi Mike, >> >> > It is also a question: how much weight should we put on adopting an >> explicitly SNARK-friendly signature scheme? While such compatibility is >> clearly advantageous, it does not seem to me to be a decisive point on its >> own. What would you say? >> >> Does it depend on what we really mean by SNARK, apart from the literal >> definition? >> What SNARK schemes are we thinking of that are post quantum? I presume I >> can say "all the pairings based SNARKs (and the DLOG based ones) are not >> quantum resistant". Are STARKs the only realistic option in this scenario? >> I am enormously ignorant about STARKs, but I do seem to recall that they >> have large proofs, so at least in theory that's a problem for such planning? >> >> Or maybe there's another PQ SNARK scheme that I'm just unaware of. >> >> I guess this is orthogonal to the point you're raising about >> arithmetic-circuit friendly hash functions like Poseidon, though. That part >> I find a bit brain-melting because: what mechanism is assumed to exist to >> translate a STARK or SNARK proof into an onchain effect? If there was say a >> STARK op-code then, job done. You'd just somehow have to have sufficiently >> small STARK proofs which is AIUI not trivial, even with nice hash >> functions. If not, we're back to the current hyper-sophisticated scenarios >> of things like Glock and BABE where you use garbled circuits, witness >> encryption, and also need something like the adaptor primitive of "swap >> signature for secret" which we currently get kind of "for free" in Schnorr >> with the linearity. I suppose there might be alternatives (e.g. HTLC >> instead of PTLC) that might be more clunky, but viable. And all of that is >> of course "fraud proof" style, with "slashing", and not anywhere near as >> clean a design as "just verify the STARK". >> >> How does one take the 10000ft view on this needed to make a design >> decision? Obviously I don't know, at all, just raising points here. I guess >> the most interesting one is: "is STARK realistically the only game in town >> here?". >> >> Cheers, >> AdamISZ/waxwing >> On Friday, January 23, 2026 at 1:34:36 PM UTC-3 Mikhail Kudinov wrote: >> >>> Hi everyone, >>> I am happy that the discussion on the PQ topic is active. I wanted to >>> add my view on the raised issues. >>> >>> For the fallback in SHRINCS, one option is to use SPHINCS+ as a fallback >>> with a limited number of signatures. By setting an upper bound as large as >>> 2^30 or 2^40, the signature size can be significantly reduced, and the >>> scheme would only be invoked in exceptional circumstances. In most >>> realistic scenarios, the fallback would consist of generating a single >>> signature to move assets to a new address. As for the statefulness >>> problems, I agree that this is an important drawback that we should keep in >>> mind. >>> >>> The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK >>> settings. But one could replace the hash functions with SNARK-friendly >>> alternatives (for example, Poseidon) in the future, which will make it >>> much, much more efficient. >>> >>> It is also a question: how much weight should we put on adopting an >>> explicitly SNARK-friendly signature scheme? While such compatibility is >>> clearly advantageous, it does not seem to me to be a decisive point on its >>> own. What would you say? >>> I am also unsure to what extent Falcon can be considered SNARK-friendly. >>> Has there been any research in this direction, or are there benchmarks >>> evaluating its performance in SNARK environments? >>> >>> Finally, regarding SQIsign: although the signature sizes are remarkable, >>> I agree that we need more time for the scheme to mature before considering >>> adoption. >>> >>> Best, >>> Mike >>> >>> On Fri, Jan 23, 2026 at 3:03 PM Giulio Golinelli <golinelli...@gmail.com> >>> 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). >>>> >>>> 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 >>>> <https://github.com/algorand/falcon/blob/main/falcon-det.pdf>) 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 >>>> <https://sqisign.org/> >>>> >>>> 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 >>>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>>> 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. >>>> >>>> >>>> https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles >>>> >>>> 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 >>>> <https://sqisign.org/>, 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 >>>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>>> 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...@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 >>>> <https://github.com/thisisnotgcsar/bitcoin-falcon>. >>>> >>>> *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 >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to bitcoindev+...@googlegroups.com. >>>> >>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com >>>> <https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > -- > --- > Abraços > Cássio Gusson > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPcK4uSUP4Yzb3-bAkPGjSf8iUFA-_%3Dq%2BHSRTLd51GZw%2Bsj5Aw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 19196 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-26 10:33 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-01-26 15:21 ` waxwing/ AdamISZ 2026-01-27 16:07 ` 'conduition' via Bitcoin Development Mailing List 0 siblings, 1 reply; 13+ messages in thread From: waxwing/ AdamISZ @ 2026-01-26 15:21 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 15836 bytes --] > I support the idea that SNARK/STARK-friendliness can not be a crucial point, as it is not currently supported, but can be an argument for tie-breaking cases. It's kind of contextual, right: it's a naturally correct default position that "one shouldn't impose arbitrary requirements on new PQ schemes that are not in place for even the existing schnorr/ecdsa schemes, all the more so with respect to speculative concepts around offchain transacting systems that aren't proven or don't even exist in prototype form". But the "contextual" here is: does the proposed QC scheme have an enormous onchain footprint (or verification cost) without any offsetting quality that could ameliorate what that implies about transaction throughputs (or centralization pressures)? That's why I mentioned batched (I should have said aggregated) signing and CISA, even though it might seem like a bit of a side issue. In case we really are looking at 20x multipliers and there is *no* ameliorating factor then ... it feels hard to support a move in that direction, except of course, in extremis. A natural counterpoint might be: "we don't have some set-in-stone plan to develop and support only one PQ scheme, so if one is proposed and prototyped which has no scaling amelioration, it's OK, we're not outlawing a future better version". Another natural counterpoint might be "doing anything remotely viable is hard enough, so *demanding* some compatibility with STARK or some PQ SNARK is kind of ridiculous". Fair :) May I also ask whether support for adaptors is considered in scope (or indeed, do any of the plausible candidates have this property?)? I guess you'd consider it out of scope, though it'd be an interesting detail. AdamISZ/waxwing On Monday, January 26, 2026 at 9:37:56 AM UTC-3 Mikhail Kudinov wrote: > The investigation of Lattice-Based approaches is on the table, so I think > we will be able to make a thoughtful comparison at some point. I support > the idea that SNARK/STARK-friendliness can not be a crucial point, as it is > not currently supported, but can be an argument for tie-breaking cases. > > All pairing-based schemes are broken by a quantum computer, yes. STARKs > are plausibly post-quantum. There are some schemes based on Lattices as > well. > > The QKD problems are not important for our discussion; they do not affect > PQ transition. > > Best, > Mike > > On Sun, Jan 25, 2026 at 11:44 PM cassio gusson <cassio...@gmail.com> > wrote: > >> hey guys >> >> I don't know if this is important for the implementation being discussed, >> but I think the study that identified a flaw in quantum key distribution >> (QKD) is worthwhile. >> >> https://ieeexplore.ieee.org/document/11223709 >> >> Best regards >> Cássio Gusson >> >> Em sáb., 24 de jan. de 2026 às 17:12, waxwing/ AdamISZ <ekag...@gmail.com> >> escreveu: >> >>> Hi Mike, >>> >>> > It is also a question: how much weight should we put on adopting an >>> explicitly SNARK-friendly signature scheme? While such compatibility is >>> clearly advantageous, it does not seem to me to be a decisive point on its >>> own. What would you say? >>> >>> Does it depend on what we really mean by SNARK, apart from the literal >>> definition? >>> What SNARK schemes are we thinking of that are post quantum? I presume I >>> can say "all the pairings based SNARKs (and the DLOG based ones) are not >>> quantum resistant". Are STARKs the only realistic option in this scenario? >>> I am enormously ignorant about STARKs, but I do seem to recall that they >>> have large proofs, so at least in theory that's a problem for such planning? >>> >>> Or maybe there's another PQ SNARK scheme that I'm just unaware of. >>> >>> I guess this is orthogonal to the point you're raising about >>> arithmetic-circuit friendly hash functions like Poseidon, though. That part >>> I find a bit brain-melting because: what mechanism is assumed to exist to >>> translate a STARK or SNARK proof into an onchain effect? If there was say a >>> STARK op-code then, job done. You'd just somehow have to have sufficiently >>> small STARK proofs which is AIUI not trivial, even with nice hash >>> functions. If not, we're back to the current hyper-sophisticated scenarios >>> of things like Glock and BABE where you use garbled circuits, witness >>> encryption, and also need something like the adaptor primitive of "swap >>> signature for secret" which we currently get kind of "for free" in Schnorr >>> with the linearity. I suppose there might be alternatives (e.g. HTLC >>> instead of PTLC) that might be more clunky, but viable. And all of that is >>> of course "fraud proof" style, with "slashing", and not anywhere near as >>> clean a design as "just verify the STARK". >>> >>> How does one take the 10000ft view on this needed to make a design >>> decision? Obviously I don't know, at all, just raising points here. I guess >>> the most interesting one is: "is STARK realistically the only game in town >>> here?". >>> >>> Cheers, >>> AdamISZ/waxwing >>> On Friday, January 23, 2026 at 1:34:36 PM UTC-3 Mikhail Kudinov wrote: >>> >>>> Hi everyone, >>>> I am happy that the discussion on the PQ topic is active. I wanted to >>>> add my view on the raised issues. >>>> >>>> For the fallback in SHRINCS, one option is to use SPHINCS+ as a >>>> fallback with a limited number of signatures. By setting an upper bound as >>>> large as 2^30 or 2^40, the signature size can be significantly reduced, and >>>> the scheme would only be invoked in exceptional circumstances. In most >>>> realistic scenarios, the fallback would consist of generating a single >>>> signature to move assets to a new address. As for the statefulness >>>> problems, I agree that this is an important drawback that we should keep in >>>> mind. >>>> >>>> The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK >>>> settings. But one could replace the hash functions with SNARK-friendly >>>> alternatives (for example, Poseidon) in the future, which will make it >>>> much, much more efficient. >>>> >>>> It is also a question: how much weight should we put on adopting an >>>> explicitly SNARK-friendly signature scheme? While such compatibility is >>>> clearly advantageous, it does not seem to me to be a decisive point on its >>>> own. What would you say? >>>> I am also unsure to what extent Falcon can be considered >>>> SNARK-friendly. Has there been any research in this direction, or are there >>>> benchmarks evaluating its performance in SNARK environments? >>>> >>>> Finally, regarding SQIsign: although the signature sizes are >>>> remarkable, I agree that we need more time for the scheme to mature before >>>> considering adoption. >>>> >>>> Best, >>>> Mike >>>> >>>> On Fri, Jan 23, 2026 at 3:03 PM Giulio Golinelli < >>>> golinelli...@gmail.com> 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). >>>>> >>>>> 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 >>>>> <https://github.com/algorand/falcon/blob/main/falcon-det.pdf>) 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 >>>>> <https://sqisign.org/> >>>>> >>>>> 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 >>>>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>>>> 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. >>>>> >>>>> >>>>> https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles >>>>> >>>>> 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 >>>>> <https://sqisign.org/>, 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 >>>>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>>>> 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...@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 >>>>> <https://github.com/thisisnotgcsar/bitcoin-falcon>. >>>>> >>>>> *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 >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> >>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com >>>>> <https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com >>> <https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> -- >> --- >> Abraços >> Cássio Gusson >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com >> <https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/02326d1c-9cf8-4b4c-b5dc-cdb00f76d451n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 23990 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-26 15:21 ` waxwing/ AdamISZ @ 2026-01-27 16:07 ` 'conduition' via Bitcoin Development Mailing List 0 siblings, 0 replies; 13+ messages in thread From: 'conduition' via Bitcoin Development Mailing List @ 2026-01-27 16:07 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 20268 bytes --] Hi all, I don't think arithmetic circuit optimization for SNARKs should be a main course for the PQ transition. Maybe it could be a dessert if we have appetite for it later. I am confident that no ZK-SNARK will ever make it into consensus on Bitcoin unless it has transparent setup, and I doubt a ZK-SNARK will survive long term if it is not quantum-secure. AFAIK that limits our options to ZK-STARKs (correct me if you know of any other transparent PQ-secure ZK-SNARK). In my admittedly shallow foray into <https://conduition.io/bitcoin/zkpreimage/> ZK-STARKs, the biggest problem I found is the scaling floor of STARKs. Simple proofs over small circuits have very large communication complexity (hundreds of kilobytes) compared to their classical witnesses (a few bytes). However, as the circuit gate depth grows, communication complexity grows as O(n log n) (see page 12 of this paper <https://eprint.iacr.org/2018/046> for a pretty graph), which is *really awesome*. Even the biggest STARKs don't seem to exceed 1MB. This makes STARKS most suitable for very large computations which would either be impractical to recompute naively, or impractical to store classical witness data for. Common examples are zk-rollups, as Giulio pointed out, or chain validity proofs like ZeroSync <https://github.com/ZeroSync/ZeroSync>. The main point I want to stress is that for STARKs to be useful for PQ signature aggregation, we need to aggregate *a lot of signatures at once*. Ethan Heilman played with this idea <https://delvingbitcoin.org/t/post-quantum-signatures-and-scaling-bitcoin-with-starks/1584> . Or you could avoid uploading the STARK proof to the chain at all. See this recent paper by Nick, Eagen, and Linus <https://eprint.iacr.org/2025/068.pdf> called "Shielded CSV", which describes a (non-quantum secure) way to use recursive ZK proofs to make payments on Bitcoin with perfect privacy, without needing to post the full ZK proofs to the network. Only a payment's recipient needs to see the proof. Lots of good ideas to explore there for any who want to make a quantum-secure CSV protocol. As for uploading STARKs directly to the chain, to be worth our while in terms of blockspace savings we'd need to aggregate at least a few dozen PQ signatures per proof... hundreds of sigs if the PQ scheme is more succinct like Falcon. Because STARKs scale so well for the verifier, it doesn't really matter to the verifier how big the computation is - Proof sizes stay capped below the megabyte range, and verifier runtime remains very fast. The choice of computation *matters far more to the prover*, who will have to spend minutes or hours of heavy compute time proving it, depending on circuit size. Unless there exists some obvious demand to make these hypothetical PQ signature provers very fas,. I don't see any reason to use arithmetic circuit size as a high weight metric for our PQ signature scheme choices. Also, remember that optimizing for arithmetic circuit size and ZK prover efficiency sometimes means hobbling classical computational efficiency. The Poseidon hash function is about an order of magnitude slower than SHA2, for example <https://ethresear.ch/t/performance-of-rescue-and-poseidon-hash-functions/7161> . Mind you, STARKs is still a young field with active research. For example there's Circle STARKs <https://eprint.iacr.org/2024/278.pdf> which improve STARK proving time. I recently spoke with a grad student who is considering a research project on the application of ZK technologies to post-quantum signature schemes like SPHINCS. I know he lurks on this list, so maybe he'd have some more nuanced opinions to share. PS. I'm very curious to know how the arithmetized circuit sizes of different signing schemes compares, e.g. SPHINCS vs XMSS vs Dilithium vs EC Schnorr. If anyone has data on that please pipe in! regards, conduition On Monday, January 26, 2026 at 8:24:26 AM UTC-7 waxwing/ AdamISZ wrote: > > I support the idea that SNARK/STARK-friendliness can not be a crucial > point, as it is not currently supported, but can be an argument for > tie-breaking cases. > > It's kind of contextual, right: it's a naturally correct default position > that "one shouldn't impose arbitrary requirements on new PQ schemes that > are not in place for even the existing schnorr/ecdsa schemes, all the more > so with respect to speculative concepts around offchain transacting systems > that aren't proven or don't even exist in prototype form". But the > "contextual" here is: does the proposed QC scheme have an enormous onchain > footprint (or verification cost) without any offsetting quality that could > ameliorate what that implies about transaction throughputs (or > centralization pressures)? That's why I mentioned batched (I should have > said aggregated) signing and CISA, even though it might seem like a bit of > a side issue. In case we really are looking at 20x multipliers and there is > *no* ameliorating factor then ... it feels hard to support a move in that > direction, except of course, in extremis. > > A natural counterpoint might be: "we don't have some set-in-stone plan to > develop and support only one PQ scheme, so if one is proposed and > prototyped which has no scaling amelioration, it's OK, we're not outlawing > a future better version". > > Another natural counterpoint might be "doing anything remotely viable is > hard enough, so *demanding* some compatibility with STARK or some PQ SNARK > is kind of ridiculous". Fair :) > > May I also ask whether support for adaptors is considered in scope (or > indeed, do any of the plausible candidates have this property?)? I guess > you'd consider it out of scope, though it'd be an interesting detail. > > AdamISZ/waxwing > > On Monday, January 26, 2026 at 9:37:56 AM UTC-3 Mikhail Kudinov wrote: > >> The investigation of Lattice-Based approaches is on the table, so I think >> we will be able to make a thoughtful comparison at some point. I support >> the idea that SNARK/STARK-friendliness can not be a crucial point, as it is >> not currently supported, but can be an argument for tie-breaking cases. >> >> All pairing-based schemes are broken by a quantum computer, yes. STARKs >> are plausibly post-quantum. There are some schemes based on Lattices as >> well. >> >> The QKD problems are not important for our discussion; they do not affect >> PQ transition. >> >> Best, >> Mike >> >> On Sun, Jan 25, 2026 at 11:44 PM cassio gusson <cassio...@gmail.com> >> wrote: >> >>> hey guys >>> >>> I don't know if this is important for the implementation being >>> discussed, but I think the study that identified a flaw in quantum key >>> distribution (QKD) is worthwhile. >>> >>> https://ieeexplore.ieee.org/document/11223709 >>> >>> Best regards >>> Cássio Gusson >>> >>> Em sáb., 24 de jan. de 2026 às 17:12, waxwing/ AdamISZ < >>> ekag...@gmail.com> escreveu: >>> >>>> Hi Mike, >>>> >>>> > It is also a question: how much weight should we put on adopting an >>>> explicitly SNARK-friendly signature scheme? While such compatibility is >>>> clearly advantageous, it does not seem to me to be a decisive point on its >>>> own. What would you say? >>>> >>>> Does it depend on what we really mean by SNARK, apart from the literal >>>> definition? >>>> What SNARK schemes are we thinking of that are post quantum? I presume >>>> I can say "all the pairings based SNARKs (and the DLOG based ones) are not >>>> quantum resistant". Are STARKs the only realistic option in this scenario? >>>> I am enormously ignorant about STARKs, but I do seem to recall that they >>>> have large proofs, so at least in theory that's a problem for such planning? >>>> >>>> Or maybe there's another PQ SNARK scheme that I'm just unaware of. >>>> >>>> I guess this is orthogonal to the point you're raising about >>>> arithmetic-circuit friendly hash functions like Poseidon, though. That part >>>> I find a bit brain-melting because: what mechanism is assumed to exist to >>>> translate a STARK or SNARK proof into an onchain effect? If there was say a >>>> STARK op-code then, job done. You'd just somehow have to have sufficiently >>>> small STARK proofs which is AIUI not trivial, even with nice hash >>>> functions. If not, we're back to the current hyper-sophisticated scenarios >>>> of things like Glock and BABE where you use garbled circuits, witness >>>> encryption, and also need something like the adaptor primitive of "swap >>>> signature for secret" which we currently get kind of "for free" in Schnorr >>>> with the linearity. I suppose there might be alternatives (e.g. HTLC >>>> instead of PTLC) that might be more clunky, but viable. And all of that is >>>> of course "fraud proof" style, with "slashing", and not anywhere near as >>>> clean a design as "just verify the STARK". >>>> >>>> How does one take the 10000ft view on this needed to make a design >>>> decision? Obviously I don't know, at all, just raising points here. I guess >>>> the most interesting one is: "is STARK realistically the only game in town >>>> here?". >>>> >>>> Cheers, >>>> AdamISZ/waxwing >>>> On Friday, January 23, 2026 at 1:34:36 PM UTC-3 Mikhail Kudinov wrote: >>>> >>>>> Hi everyone, >>>>> I am happy that the discussion on the PQ topic is active. I wanted to >>>>> add my view on the raised issues. >>>>> >>>>> For the fallback in SHRINCS, one option is to use SPHINCS+ as a >>>>> fallback with a limited number of signatures. By setting an upper bound as >>>>> large as 2^30 or 2^40, the signature size can be significantly reduced, and >>>>> the scheme would only be invoked in exceptional circumstances. In most >>>>> realistic scenarios, the fallback would consist of generating a single >>>>> signature to move assets to a new address. As for the statefulness >>>>> problems, I agree that this is an important drawback that we should keep in >>>>> mind. >>>>> >>>>> The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK >>>>> settings. But one could replace the hash functions with SNARK-friendly >>>>> alternatives (for example, Poseidon) in the future, which will make it >>>>> much, much more efficient. >>>>> >>>>> It is also a question: how much weight should we put on adopting an >>>>> explicitly SNARK-friendly signature scheme? While such compatibility is >>>>> clearly advantageous, it does not seem to me to be a decisive point on its >>>>> own. What would you say? >>>>> I am also unsure to what extent Falcon can be considered >>>>> SNARK-friendly. Has there been any research in this direction, or are there >>>>> benchmarks evaluating its performance in SNARK environments? >>>>> >>>>> Finally, regarding SQIsign: although the signature sizes are >>>>> remarkable, I agree that we need more time for the scheme to mature before >>>>> considering adoption. >>>>> >>>>> Best, >>>>> Mike >>>>> >>>>> On Fri, Jan 23, 2026 at 3:03 PM Giulio Golinelli < >>>>> golinelli...@gmail.com> 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). >>>>>> >>>>>> 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 >>>>>> <https://github.com/algorand/falcon/blob/main/falcon-det.pdf>) 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 >>>>>> <https://sqisign.org/> >>>>>> >>>>>> 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 >>>>>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>>>>> 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. >>>>>> >>>>>> >>>>>> https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles >>>>>> >>>>>> 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 >>>>>> <https://sqisign.org/>, 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 >>>>>> <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. >>>>>> 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...@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 >>>>>> <https://github.com/thisisnotgcsar/bitcoin-falcon>. >>>>>> >>>>>> *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 >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to bitcoindev+...@googlegroups.com. >>>>>> >>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com >>>>>> <https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> >>> -- >>> --- >>> Abraços >>> Cássio Gusson >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to bitcoindev+...@googlegroups.com. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4b0eda09-32c0-4419-a691-edacad231865n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 28594 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-23 15:36 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List 2026-01-24 13:04 ` waxwing/ AdamISZ @ 2026-01-24 13:31 ` Giulio Golinelli 1 sibling, 0 replies; 13+ messages in thread From: Giulio Golinelli @ 2026-01-24 13:31 UTC (permalink / raw) To: Mikhail Kudinov; +Cc: conduition, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 8982 bytes --] Hi Mike, > how much weight should we put on adopting an explicitly SNARK- > friendly signature scheme? While such compatibility is clearly > advantageous, it does not seem to me to be a decisive point on its > own. What would you say? From a security perspective it's irrelevant. Best, Giulio On Fri, 2026-01-23 at 16:36 +0100, Mikhail Kudinov wrote: > Hi everyone, > I am happy that the discussion on the PQ topic is active. I wanted to > add my view on the raised issues. > > For the fallback in SHRINCS, one option is to use SPHINCS+ as a > fallback with a limited number of signatures. By setting an upper > bound as large as 2^30 or 2^40, the signature size can be > significantly reduced, and the scheme would only be invoked in > exceptional circumstances. In most realistic scenarios, the fallback > would consist of generating a single signature to move assets to a > new address. As for the statefulness problems, I agree that this is > an important drawback that we should keep in mind. > > The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK > settings. But one could replace the hash functions with SNARK- > friendly alternatives (for example, Poseidon) in the future, which > will make it much, much more efficient. > > It is also a question: how much weight should we put on adopting an > explicitly SNARK-friendly signature scheme? While such compatibility > is clearly advantageous, it does not seem to me to be a decisive > point on its own. What would you say? > I am also unsure to what extent Falcon can be considered SNARK- > friendly. Has there been any research in this direction, or are there > benchmarks evaluating its performance in SNARK environments? > > Finally, regarding SQIsign: although the signature sizes are > remarkable, I agree that we need more time for the scheme to mature > before considering adoption. > > Best, > Mike > > On Fri, Jan 23, 2026 at 3:03 PM Giulio Golinelli > <golinelli.giulio13@gmail.com> 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). > > 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 [1]) 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 [2] > > 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 [3]. 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. > > > > > > https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles > > > > > > 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 > > > [2], 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 [3]. 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 [4]. > > > > > > > > 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 > > [1] author’s notes https://github.com/algorand/falcon/blob/main/falcon-det.pdf [2] SQIsign https://sqisign.org/ [3] Jonas Nick's SHRINCS proposal https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158 [4] this fork https://github.com/thisisnotgcsar/bitcoin-falcon -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8fd0631e2db52a48d66fe74bf4ffa9dfe23f5dd5.camel%40gmail.com. [-- Attachment #2: Type: text/html, Size: 15028 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal 2026-01-23 7:12 ` Giulio Golinelli 2026-01-23 15:36 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List @ 2026-01-27 16:39 ` 'conduition' via Bitcoin Development Mailing List 1 sibling, 0 replies; 13+ messages in thread From: 'conduition' via Bitcoin Development Mailing List @ 2026-01-27 16:39 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 8035 bytes --] I would be happy to be proven wrong, and to learn that Falcon is actually very easy to implement. Of all the NIST PQC schemes, Falcon is the one I understand least, so I may be mistaken. But software emulation of floating point arithmetic doesn't sound easy, especially if getting it wrong means a potential forgery attack. Also, there is still discrete Gaussian sampling to contend with. > SPHINCS+ cannot be considered a valid fallback as it introduces large signature overhead (it's not meant for bitcoin-like use-cases). I disagree. I think it's crucial for us to have a conservative stateless signing scheme ready as a fallback to authenticate the UTXO set if a CRQC appears. Though the signatures are indeed large, that can be mitigated by smaller parameter sets as Mikhail mentioned, or if you're OK with losing NIST compatibility, using the SPHINCS+C variant and friends. > Any TPM-based state management would reduce performance and compatibility across architectures It doesn't have to be a TPM <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158/14>. My point is that if your wallet *can* manage state in some way, XMSS makes for really tiny, fast, and easy-to-implement signatures. Even if some platforms can't hack it, others would happily make the trade-off. It doesn't hurt that unbalanced XMSS disincentivizes address reuse as well. regards, conduition On Friday, January 23, 2026 at 7:03:46 AM UTC-7 Giulio Golinelli 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). > > 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 > <https://github.com/algorand/falcon/blob/main/falcon-det.pdf>) 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 > <https://sqisign.org/> > > 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 > <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. > 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. > > > https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles > > 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 > <https://sqisign.org/>, 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 > <https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158>. > 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...@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 > <https://github.com/thisisnotgcsar/bitcoin-falcon>. > > *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 > > > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3c9eb86f-13e0-4a18-b978-9fea89d4f6e8n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 13702 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2026-02-02 23:37 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-01-22 7:01 [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal Giulio Golinelli 2026-01-22 12:48 ` [bitcoindev] " waxwing/ AdamISZ 2026-01-23 3:45 ` Giulio Golinelli 2026-01-22 14:35 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List 2026-01-23 7:12 ` Giulio Golinelli 2026-01-23 15:36 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List 2026-01-24 13:04 ` waxwing/ AdamISZ 2026-01-25 21:54 ` cassio gusson 2026-01-26 10:33 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List 2026-01-26 15:21 ` waxwing/ AdamISZ 2026-01-27 16:07 ` 'conduition' via Bitcoin Development Mailing List 2026-01-24 13:31 ` Giulio Golinelli 2026-01-27 16:39 ` 'conduition' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox