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 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 > 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 >>> 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 >>>> ) which >>>> uses software floating-point emulation . This eliminates side-channel risks >>>> associated with non-constant-time hardware FPUs. It is also SNARK-friendly >>>> and overcomes portability limitation. While this sacrifices the performance >>>> optimizations of true FPUs, signing speed is not critical in Bitcoin, where >>>> verification dominates node activity. >>>> >>>> If small signatures are your goal, then I'd look into SQIsign >>>> >>>> >>>> This would be good like many other PQ exotic schemes but all of these >>>> are far from being standardized soon. >>>> >>>> If you want a PQC scheme that's ready *today* and also provides small >>>> signatures, I'll point you to XMSS, and Jonas Nick's SHRINCS proposal >>>> . >>>> You can configure an unbalanced XMSS tree to get 272 byte signatures, >>>> potentially smaller if you crank up the parameters. The catch is a >>>> dependence on statefulness. >>>> >>>> SPHINCS+ cannot be considered a valid fallback as it introduces large >>>> signature overhead (it's not meant for bitcoin-like use-cases). Any >>>> TPM-based state management would reduce performance and compatibility >>>> across architectures. The hash-based nature of SHRINCS is highly >>>> SNARK-unfriendly, making them incompatible with emerging L2 ZK rollup >>>> constructions. Moreover in high-throughput L2 environments, state >>>> management, limits on the number of signatures and performance degradation >>>> proportional to published signatures are critical bottlenecks. >>>> >>>> On Thu, 2026-01-22 at 14:35 +0000, conduition wrote: >>>> >>>> Falcon (FN-DSA) relies on discrete gaussian sampling using >>>> constant-time floating point arithmetic for signers, which is very hard to >>>> implement quickly and in constant time (securely). Despite being >>>> significantly harder to implement than ML-DSA, it only provides a mild >>>> (factor of two or so) improvement in signature + pubkey size. This is why >>>> we're probably not including FN-DSA in our PQ signature opcode BIP >>>> following BIP360. >>>> >>>> >>>> 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...@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+...@googlegroups.com. >>>> >>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.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/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com >> >> . >> > > > -- > > -- > --- > 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 > > . > -- 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.