From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Falcon Post-Quantum Signature Scheme Proposal
Date: Thu, 22 Jan 2026 04:48:42 -0800 (PST) [thread overview]
Message-ID: <e7977710-22ca-477c-b8cd-0933f41ff398n@googlegroups.com> (raw)
In-Reply-To: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com>
[-- 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 --]
next prev parent reply other threads:[~2026-01-22 12:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 7:01 [bitcoindev] " Giulio Golinelli
2026-01-22 12:48 ` waxwing/ AdamISZ [this message]
2026-01-23 3:45 ` [bitcoindev] " 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
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=e7977710-22ca-477c-b8cd-0933f41ff398n@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.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