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 > [email protected]. > 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e13546d438e0b871b8d6a4b449ce5c27b47cb765.camel%40gmail.com.
