From: Giulio Golinelli <golinelli.giulio13@gmail.com>
To: Mikhail Kudinov <mkudinov@blockstream.com>
Cc: conduition <conduition@proton.me>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal
Date: Sat, 24 Jan 2026 21:31:59 +0800 [thread overview]
Message-ID: <8fd0631e2db52a48d66fe74bf4ffa9dfe23f5dd5.camel@gmail.com> (raw)
In-Reply-To: <CAPcK4uSY_fz9jGb8QrL7j4giqq2pGZ6K=CuPOzjQdqoMZgYPAw@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2026-02-02 23:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 7:01 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 [this message]
2026-01-27 16:39 ` 'conduition' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8fd0631e2db52a48d66fe74bf4ffa9dfe23f5dd5.camel@gmail.com \
--to=golinelli.giulio13@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=mkudinov@blockstream.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox