From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 26 Jan 2026 07:24:34 -0800 Received: from mail-oo1-f61.google.com ([209.85.161.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vkOS8-0008JD-6E for bitcoindev@gnusha.org; Mon, 26 Jan 2026 07:24:33 -0800 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-662c90deacbsf11207716eaf.0 for ; Mon, 26 Jan 2026 07:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1769441066; x=1770045866; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=O3PX86YO6CokO5r01zQN1TkDXeJoTTzpTYRGQv98VaQ=; b=qZ2D4QlFQLpkgf866AoPk9BQsarDF7ECAMy4JJdBgMy2nwsEzIXE4CcJYbYH0bJyCf pTrgOgw0WdFRttwcK+F37+Ct6YK2fm4pLPo4PEBO0OVAl0YpEKXYeesDEy5Lyss0KPdh pPkOuezm/48VigjUnwUo6Qc8GRlDVsCFS7Ewm27Fb6qXCtUM38qM6qWHz1G51b/29c5A ychAIx1+w5aBuxANKPZSOFJ6/U60SzgrtLqrWN12zYukMnlCdgL8euvZsJE3zVYutngG xyc13XYigS7raILTjtY61hsJiY5aUXFGeZI1JhqZ5oRczxNdYVxb3QB8S3BV90VEsisU yHnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769441066; x=1770045866; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=O3PX86YO6CokO5r01zQN1TkDXeJoTTzpTYRGQv98VaQ=; b=QgAj67HkjI6525W3QWFUauewh6UEG1W3fiHHfNO1kYiLJDtkDCKPX+6X5ObbUEUNty XbRZhTGrU+LLIqiD6A0HwZazES643fAwoIrGiIBSliYmTeALP883CYGVOA0wgeOmVtpb mDoqUffRI4ulGYbM+dJmt68iRLXZaV1OJoNk6wE3OQfvcY+ncDRZ7fiMFPKnFwuQNUJu hTJvqYzgSSKPZNBTMmhFYiJVmdhLo3FRuFk02nrfeSVHY4Qj8W5mjZSHwxtli7ebeVAd BdHb0Ye+hD/rgu3HA6HFr/43S/1hcdLMEJsjXCUwDSqn/69/571iVPDZoygUE+rsaXur BxWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769441066; x=1770045866; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=O3PX86YO6CokO5r01zQN1TkDXeJoTTzpTYRGQv98VaQ=; b=nJW8s1y+5Y2pHc0ElLimHN6ogaXndX6oKrQ6SL9GyUboFaUPJBQEk6X8xhJD2eqp1Q QZTOITL970IHJBHStAd/wytU0FotPhwvJeDqBcYOKpy0Isb247ygWRsvSx53hZvhfMEO 7rC7F+GGzXx9tDVAomwphuSVd5m/lzeVwJD+CGvD8zdhKIxKkWPe7UajeJa9EHmpdMii XPZ4GRKqTUkcMp9sDSUAuUwoa9MSgTWak20vNh7zTOPD4iwHfZMkk03RujgLUacd1di3 M8hPPOU7WmnJpUz9IHKU6JS3QbZWfMFAmMWpGqaGJR+a0Q6meqgotn8f9Y8qtjat4STS YvJQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUkPzy9C9biGyfAf/pQOokLGSgyBPfUlciUYlMG43FXHHh1CqtEcCLWA/o1Q8vQNsC1Iur7cGIcut+y@gnusha.org X-Gm-Message-State: AOJu0YyiL49XYFjMsP05mRyN+246Y16EzPgvl32j3uJgTP3FYyrQy6LO etJ9FyfmYEm7QhD1aYCLdGvRstuiQvpz4nXViNTuAM3llcXetP6pEC11 X-Received: by 2002:a05:6820:4cc5:b0:65b:3d3a:c1da with SMTP id 006d021491bc7-662e02de84bmr2115659eaf.22.1769441065805; Mon, 26 Jan 2026 07:24:25 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+ED29tpczuGqkITKSMWcP+Qsr5lNFlnzvt3CZ0jf9BOtQ==" Received: by 2002:a4a:db4e:0:b0:661:837:4a39 with SMTP id 006d021491bc7-662c1d81255ls1445587eaf.1.-pod-prod-09-us; Mon, 26 Jan 2026 07:24:21 -0800 (PST) X-Received: by 2002:a05:6808:1506:b0:45e:ed21:7abe with SMTP id 5614622812f47-45eed217b11mr768245b6e.19.1769441061585; Mon, 26 Jan 2026 07:24:21 -0800 (PST) Received: by 2002:a05:690c:56c5:20b0:794:2788:2ae4 with SMTP id 00721157ae682-7943c31864dms7b3; Mon, 26 Jan 2026 07:21:49 -0800 (PST) X-Received: by 2002:a05:690c:386:b0:78f:bede:57bb with SMTP id 00721157ae682-7945a885778mr41735397b3.29.1769440908701; Mon, 26 Jan 2026 07:21:48 -0800 (PST) Date: Mon, 26 Jan 2026 07:21:48 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <02326d1c-9cf8-4b4c-b5dc-cdb00f76d451n@googlegroups.com> In-Reply-To: References: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com> <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> <46faf0c0-d60d-49a4-83c5-8fe03f11c89dn@googlegroups.com> Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_201280_789665324.1769440908258" X-Original-Sender: ekaggata@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_201280_789665324.1769440908258 Content-Type: multipart/alternative; boundary="----=_Part_201281_1553090814.1769440908258" ------=_Part_201281_1553090814.1769440908258 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I support the idea that SNARK/STARK-friendliness can not be a crucial=20 point, as it is not currently supported, but can be an argument for=20 tie-breaking cases. It's kind of contextual, right: it's a naturally correct default position= =20 that "one shouldn't impose arbitrary requirements on new PQ schemes that=20 are not in place for even the existing schnorr/ecdsa schemes, all the more= =20 so with respect to speculative concepts around offchain transacting systems= =20 that aren't proven or don't even exist in prototype form". But the=20 "contextual" here is: does the proposed QC scheme have an enormous onchain= =20 footprint (or verification cost) without any offsetting quality that could= =20 ameliorate what that implies about transaction throughputs (or=20 centralization pressures)? That's why I mentioned batched (I should have=20 said aggregated) signing and CISA, even though it might seem like a bit of= =20 a side issue. In case we really are looking at 20x multipliers and there is= =20 *no* ameliorating factor then ... it feels hard to support a move in that= =20 direction, except of course, in extremis. A natural counterpoint might be: "we don't have some set-in-stone plan to= =20 develop and support only one PQ scheme, so if one is proposed and=20 prototyped which has no scaling amelioration, it's OK, we're not outlawing= =20 a future better version". Another natural counterpoint might be "doing anything remotely viable is=20 hard enough, so *demanding* some compatibility with STARK or some PQ SNARK= =20 is kind of ridiculous". Fair :) May I also ask whether support for adaptors is considered in scope (or=20 indeed, do any of the plausible candidates have this property?)? I guess=20 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=E2=80=AFAM UTC-3 Mikhail Kudinov wro= te: > The investigation of Lattice-Based approaches is on the table, so I think= =20 > we will be able to make a thoughtful comparison at some point. I support= =20 > the idea that SNARK/STARK-friendliness can not be a crucial point, as it = is=20 > not currently supported, but can be an argument for tie-breaking cases. = =20 > > All pairing-based schemes are broken by a quantum computer, yes. STARKs= =20 > are plausibly post-quantum. There are some schemes based on Lattices as= =20 > well.=20 > > The QKD problems are not important for our discussion; they do not affect= =20 > PQ transition. > > Best, > Mike=20 > > On Sun, Jan 25, 2026 at 11:44=E2=80=AFPM cassio gusson =20 > wrote: > >> hey guys >> >> I don't know if this is important for the implementation being discussed= ,=20 >> but I think the study that identified a flaw in quantum key distribution= =20 >> (QKD) is worthwhile. >> >> https://ieeexplore.ieee.org/document/11223709 >> >> Best regards >> C=C3=A1ssio Gusson >> >> Em s=C3=A1b., 24 de jan. de 2026 =C3=A0s 17:12, waxwing/ AdamISZ =20 >> escreveu: >> >>> Hi Mike, >>> >>> > It is also a question: how much weight should we put on adopting an= =20 >>> explicitly SNARK-friendly signature scheme? While such compatibility is= =20 >>> clearly advantageous, it does not seem to me to be a decisive point on = its=20 >>> own. What would you say? >>> >>> Does it depend on what we really mean by SNARK, apart from the literal= =20 >>> definition? >>> What SNARK schemes are we thinking of that are post quantum? I presume = I=20 >>> can say "all the pairings based SNARKs (and the DLOG based ones) are no= t=20 >>> quantum resistant". Are STARKs the only realistic option in this scenar= io?=20 >>> I am enormously ignorant about STARKs, but I do seem to recall that the= y=20 >>> have large proofs, so at least in theory that's a problem for such plan= ning? >>> >>> 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=20 >>> arithmetic-circuit friendly hash functions like Poseidon, though. That = part=20 >>> I find a bit brain-melting because: what mechanism is assumed to exist = to=20 >>> translate a STARK or SNARK proof into an onchain effect? If there was s= ay a=20 >>> STARK op-code then, job done. You'd just somehow have to have sufficien= tly=20 >>> small STARK proofs which is AIUI not trivial, even with nice hash=20 >>> functions. If not, we're back to the current hyper-sophisticated scenar= ios=20 >>> of things like Glock and BABE where you use garbled circuits, witness= =20 >>> encryption, and also need something like the adaptor primitive of "swap= =20 >>> signature for secret" which we currently get kind of "for free" in Schn= orr=20 >>> with the linearity. I suppose there might be alternatives (e.g. HTLC=20 >>> instead of PTLC) that might be more clunky, but viable. And all of that= is=20 >>> of course "fraud proof" style, with "slashing", and not anywhere near a= s=20 >>> clean a design as "just verify the STARK". >>> >>> How does one take the 10000ft view on this needed to make a design=20 >>> decision? Obviously I don't know, at all, just raising points here. I g= uess=20 >>> the most interesting one is: "is STARK realistically the only game in t= own=20 >>> here?". >>> >>> Cheers, >>> AdamISZ/waxwing >>> On Friday, January 23, 2026 at 1:34:36=E2=80=AFPM UTC-3 Mikhail Kudinov= wrote: >>> >>>> Hi everyone, >>>> I am happy that the discussion on the PQ topic is active. I wanted to= =20 >>>> add my view on the raised issues.=20 >>>> >>>> For the fallback in SHRINCS, one option is to use SPHINCS+ as a=20 >>>> fallback with a limited number of signatures. By setting an upper boun= d as=20 >>>> large as 2^30 or 2^40, the signature size can be significantly reduced= , and=20 >>>> the scheme would only be invoked in exceptional circumstances. In most= =20 >>>> realistic scenarios, the fallback would consist of generating a single= =20 >>>> signature to move assets to a new address. As for the statefulness=20 >>>> problems, I agree that this is an important drawback that we should ke= ep in=20 >>>> mind. >>>> >>>> The SHA-based SPHINCS+ is indeed not particularly efficient in SNARK= =20 >>>> settings. But one could replace the hash functions with SNARK-friendly= =20 >>>> alternatives (for example, Poseidon) in the future, which will make it= =20 >>>> much, much more efficient. >>>> >>>> It is also a question: how much weight should we put on adopting an=20 >>>> explicitly SNARK-friendly signature scheme? While such compatibility i= s=20 >>>> clearly advantageous, it does not seem to me to be a decisive point on= its=20 >>>> own. What would you say? >>>> I am also unsure to what extent Falcon can be considered=20 >>>> SNARK-friendly. Has there been any research in this direction, or are = there=20 >>>> benchmarks evaluating its performance in SNARK environments? >>>> >>>> Finally, regarding SQIsign: although the signature sizes are=20 >>>> remarkable, I agree that we need more time for the scheme to mature be= fore=20 >>>> considering adoption. >>>> >>>> Best, >>>> Mike >>>> >>>> On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giulio Golinelli < >>>> golinelli...@gmail.com> wrote: >>>> >>>>> Falcon (FN-DSA) relies on discrete gaussian sampling using=20 >>>>> constant-time floating point arithmetic for signers, which is very ha= rd to=20 >>>>> implement quickly and in constant time (securely). >>>>> >>>>> This is true for the first Falcon version published (randomized mode= =20 >>>>> of operation). This implementation uses the author-recommended=20 >>>>> deterministic Falcon mode (see author=E2=80=99s notes=20 >>>>> ) which= =20 >>>>> uses software floating-point emulation . This eliminates side-channel= risks=20 >>>>> associated with non-constant-time hardware FPUs. It is also SNARK-fri= endly=20 >>>>> and overcomes portability limitation. While this sacrifices the perfo= rmance=20 >>>>> optimizations of true FPUs, signing speed is not critical in Bitcoin,= where=20 >>>>> verification dominates node activity. >>>>> >>>>> If small signatures are your goal, then I'd look into SQIsign=20 >>>>> >>>>> >>>>> This would be good like many other PQ exotic schemes but all of these= =20 >>>>> are far from being standardized soon. >>>>> >>>>> If you want a PQC scheme that's ready *today* and also provides small= =20 >>>>> signatures, I'll point you to XMSS, and Jonas Nick's SHRINCS proposal= =20 >>>>> .=20 >>>>> You can configure an unbalanced XMSS tree to get 272 byte signatures,= =20 >>>>> potentially smaller if you crank up the parameters. The catch is a=20 >>>>> dependence on statefulness.=20 >>>>> >>>>> SPHINCS+ cannot be considered a valid fallback as it introduces large= =20 >>>>> signature overhead (it's not meant for bitcoin-like use-cases). Any= =20 >>>>> TPM-based state management would reduce performance and compatibility= =20 >>>>> across architectures. The hash-based nature of SHRINCS is highly=20 >>>>> SNARK-unfriendly, making them incompatible with emerging L2 ZK rollup= =20 >>>>> constructions. Moreover in high-throughput L2 environments, state=20 >>>>> management, limits on the number of signatures and performance degrad= ation=20 >>>>> 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=20 >>>>> constant-time floating point arithmetic for signers, which is very ha= rd to=20 >>>>> implement quickly and in constant time (securely). Despite being=20 >>>>> significantly harder to implement than ML-DSA, it only provides a mil= d=20 >>>>> (factor of two or so) improvement in signature + pubkey size. This is= why=20 >>>>> we're probably not including FN-DSA in our PQ signature opcode BIP=20 >>>>> following BIP360. >>>>> >>>>> >>>>> https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-poin= ts-falcons-achilles >>>>> >>>>> While I wouldn't rule out Falcon permanently, I personally feel more= =20 >>>>> research is needed to explore Falcon, its weaknesses, and how flexibl= y it=20 >>>>> can be adapted to schemes like CISA, BIP32, and multisignatures. Let = it=20 >>>>> bake a little longer. >>>>> >>>>> If small signatures are your goal, then I'd look into SQIsign=20 >>>>> , which uses isogeny-based cryptography to=20 >>>>> produce very small sigs (148b) and pubkeys (65b) using some convolute= d=20 >>>>> mathematical tricks. However, much like Falcon, it is still immature = and=20 >>>>> needs more researchers to optimize its verification, explore its stre= ngths,=20 >>>>> and attack its weaknesses.=20 >>>>> >>>>> If you want a PQC scheme that's ready *today* and also provides small= =20 >>>>> signatures, I'll point you to XMSS, and Jonas Nick's SHRINCS proposal= =20 >>>>> .=20 >>>>> You can configure an unbalanced XMSS tree to get 272 byte signatures,= =20 >>>>> potentially smaller if you crank up the parameters. The catch is a=20 >>>>> dependence on statefulness.=20 >>>>> >>>>> 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= =20 >>>>> integrates the Falcon post-quantum signature scheme (Falcon-512) into= =20 >>>>> Bitcoin Core, implemented as a soft-fork within the classic P2WPKH mo= de.=20 >>>>> This work aims to provide a practical reference for possible future F= alcon=20 >>>>> adoption, especially as it approaches FIPS standardization. >>>>> You can find details at this fork=20 >>>>> . >>>>> >>>>> *Why Falcon?* >>>>> Falcon is a lattice-based, post-quantum digital signature scheme=20 >>>>> designed to be secure against quantum attacks. Unlike other PQC candi= dates=20 >>>>> such as SPHINCS+ and ML-DSA, Falcon offers significantly smaller sign= ature=20 >>>>> and public key sizes, as well as efficient signing and verification t= imes.=20 >>>>> It is implemented in pure C and does not require external dependencie= s. >>>>> >>>>> *Benchmarking & Results* >>>>> Aspect Falcon ECDSA >>>>> Public Key Size (B) 897 33 >>>>> Signature Size (B) 655 71 >>>>> Verification Time (=CE=BCs) 57 120 >>>>> >>>>> Verification time is more critical than signature creation time in=20 >>>>> Bitcoin, since signature creation is performed by clients (wallets), = while=20 >>>>> nodes focus on verification. >>>>> >>>>> *Integration* >>>>> >>>>> - Falcon was included into the codebase from the original GitHub= =20 >>>>> repository. >>>>> - The build system (CMakeLists.txt) was updated to support Falcon. >>>>> - Falcon verification has been soft-fork enabled via a new script= =20 >>>>> verification flag. >>>>> >>>>> *Next Steps & Reference* >>>>> This project serves as a practical demonstration of Falcon=E2=80=99s = promising=20 >>>>> performance, highlighting its advantages over currently selected=20 >>>>> post-quantum signature algorithms such as SPHINCS+ and ML-DSA, which = face=20 >>>>> significant time and space limitations. As Falcon approaches FIPS=20 >>>>> standardization, this work aims to provide a reference for future ado= ption=20 >>>>> and integration in Bitcoin. >>>>> >>>>> Let me know what you think and if this could be of interest for which= =20 >>>>> case I can complement the project by integrating Falcon into all the = other=20 >>>>> spending paths. I also look forward to development/integration correc= tions. >>>>> >>>>> Best regards, >>>>> Giulio >>>>> >>>>> >>>>> --=20 >>>>> You received this message because you are subscribed to the Google=20 >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d=20 >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> >>>> To view this discussion visit=20 >>>>> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2= fded500a234f68a6.camel%40gmail.com=20 >>>>> >>>>> . >>>>> >>>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8f= e03f11c89dn%40googlegroups.com=20 >>> >>> . >>> >> >> >> --=20 >> >> --=20 >> --- >> Abra=C3=A7os >> C=C3=A1ssio Gusson >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4Ec= xhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com=20 >> >> . >> > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 02326d1c-9cf8-4b4c-b5dc-cdb00f76d451n%40googlegroups.com. ------=_Part_201281_1553090814.1769440908258 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0I support the idea that SNARK/STARK-friendliness can not be = a crucial=20 point, as it is not currently supported, but can be an argument=C2=A0for=20 tie-breaking cases.

It's kind of contextual, rig= ht: it's a naturally correct default position that "one shouldn't impose ar= bitrary requirements on new PQ schemes that are not in place for even the e= xisting schnorr/ecdsa schemes, all the more so with respect to speculative = concepts around offchain transacting systems that aren't proven or don't ev= en exist in prototype form". But the "contextual" here is: does the propose= d QC scheme have an enormous onchain footprint (or verification cost) witho= ut any offsetting quality that could ameliorate what that implies about tra= nsaction throughputs (or centralization pressures)? That's why I mentioned = batched (I should have said aggregated) signing and CISA, even though it mi= ght seem like a bit of a side issue. In case we really are looking at 20x m= ultipliers 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-i= n-stone plan to develop and support only one PQ scheme, so if one is propos= ed and prototyped which has no scaling amelioration, it's OK, we're not out= lawing 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 ridicu= lous". Fair :)

May I also ask whether support fo= r adaptors is considered in scope (or indeed, do any of the plausible candi= dates 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=E2=80=AFAM UTC-3 Mikhail Kudinov wr= ote:
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 su= pport the idea that SNARK/STARK-friendliness can not be a crucial point, as= it is not currently supported, but can be an argument=C2=A0for tie-breakin= g cases.=C2=A0=C2=A0

All pairing-based schemes are broken by a quant= um computer, yes. STARKs are plausibly post-quantum. There are some schemes= based on Lattices as well.=C2=A0

The QKD problems are not important= for our discussion; they do not affect PQ transition.

Best,
Mike= =C2=A0

On Sun, Jan 25, 2026 at 11:44=E2=80= =AFPM cassio gusson <cassio..= .@gmail.com> wrote:
hey guys
I don't know if this is important for the implementation being discus= sed, but I think the study that identified a flaw in quantum key distributi= on (QKD) is worthwhile.

https://ieeexplore.ieee.org/document/11223709
Best regards
C=C3=A1ssio Gusson

Em s=C3=A1b., 24 de jan. de 2026 =C3= =A0s 17:12, waxwing/ AdamISZ <ekag...@gmail.com> escreveu:
Hi Mike,

> It is also= a question: how much weight should we put on adopting an=20 explicitly SNARK-friendly signature scheme? While such compatibility is=20 clearly advantageous, it does not seem to me to be=C2=A0a decisive point on= =20 its own. What would you say?

Does it depend on wha= t we really mean by SNARK, apart from the literal definition?
Wha= t SNARK schemes are we thinking of that are post quantum? I presume I can s= ay "all the pairings based SNARKs (and the DLOG based ones) are not qu= antum resistant". Are STARKs the only realistic option in this scenari= o? 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 pla= nning?

Or maybe there's another PQ SNARK schem= e that I'm just unaware of.

I guess this is or= thogonal 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 p= roof into an onchain effect? If there was say a STARK op-code then, job don= e. You'd just somehow have to have sufficiently small STARK proofs whic= h is AIUI not trivial, even with nice hash functions. If not, we're bac= k to the current hyper-sophisticated scenarios of things like Glock and BAB= E where you use garbled circuits, witness encryption, and also need somethi= ng like the adaptor primitive of "swap signature for secret" whic= h we currently get kind of "for free" in Schnorr with the lineari= ty. 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 clea= n a design as "just verify the STARK".

H= ow 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 Fri= day, January 23, 2026 at 1:34:36=E2=80=AFPM UTC-3 Mikhail Kudinov wrote:
<= div dir=3D"ltr">Hi everyone,
I am happy that the discussion on the PQ to= pic is active. I wanted to add my view on the raised issues.=C2=A0

F= or the=C2=A0fallback in SHRINCS, one option is to use SPHINCS+ as a fallbac= k with a limited number of signatures. By setting an upper bound as large a= s 2^30 or 2^40, the signature size can be significantly reduced, and the sc= heme would only be invoked in exceptional circumstances. In most realistic = scenarios, the fallback would consist of generating a single signature to m= ove 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=C2=A0more e= fficient.

It is also a question: how much weight should we put on ad= opting an explicitly SNARK-friendly signature scheme? While such compatibil= ity is clearly advantageous, it does not seem to me to be=C2=A0a decisive p= oint on its own. What would you say?
I am also unsure to what extent Fal= con can be considered SNARK-friendly. Has there been any research in this d= irection, or are there benchmarks evaluating its performance in SNARK envir= onments?

Finally, regarding SQIsign: although the signature sizes ar= e remarkable, I agree that we need more time for the scheme to mature befor= e considering adoption.

Best,
Mike

On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giuli= o Golinelli <golinelli...@gmail.com> wrote:
Falcon (FN= -DSA) relies on discrete gaussian sampling using constant-time floating poi= nt arithmetic for signers, which is very hard to implement quickly and in c= onstant time (securely).
This is true for the first Falcon version published= (randomized mode of operation). This implementation uses the author-recomm= ended deterministic Falcon mode (see=C2=A0author=E2=80= =99s notes)=C2=A0which uses software floating-point emulation . This el= iminates side-channel risks associated with non-constant-time hardware FPUs= . It is also SNARK-friendly and overcomes portability limitation. While thi= s sacrifices the performance optimizations of true FPUs, signing speed is n= ot critical in Bitcoin, where verification dominates node activity.<= /div>

If small signatures are your goal, then I'd look into= =C2=A0SQIsign
This would be go= od like many other PQ exotic schemes but all of these are far from being st= andardized soon.

If you want a PQC scheme that's rea= dy=C2=A0today=C2=A0and also provides small signatures, = I'll point you to XMSS, and=C2=A0Jonas Nick's SHRI= NCS 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.=C2=A0
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 perfo= rmance and compatibility across architectures. The hash-based nature of SHR= INCS 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:
Fal= con (FN-DSA) relies on discrete gaussian sampling using constant-time float= ing point arithmetic for signers, which is very hard to implement quickly a= nd in constant time (securely). Despite being significantly harder to imple= ment 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 F= N-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 pers= onally feel more research is needed to explore Falcon, its weaknesses, and = how flexibly it can be adapted to schemes like CISA, BIP32, and multisignat= ures. Let it bake a little longer.

If small si= gnatures are your goal, then I'd look into SQIsign, which uses isogeny-based cryptography to produce very s= mall sigs (148b) and pubkeys (65b) using some convoluted mathematical trick= s. However, much like Falcon, it is still immature and needs more researche= rs to optimize its verification, explore its strengths, and attack its weak= nesses.=C2=A0

If you want a PQC scheme that'= s ready today=C2=A0and also provides small signatures, I'll poin= t you to XMSS, and Jonas Nick's SHRINCS proposal. You can configu= re an unbalanced XMSS tree to get 272 byte signatures, potentially smaller = if you crank up the parameters. The catch is a dependence on statefulness.= =C2=A0

regards,
conduition
On Wednesday, January 2= 1st, 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 Bitc= oin Core, implemented as a soft-fork within the classic P2WPKH mode. This w= ork aims to provide a practical reference for possible future Falcon adopti= on, especially as it approaches FIPS standardization.
You can find detai= ls at this fork.

Why Falcon?
Falcon is a lattice-based, post-quantum digital si= gnature scheme designed to be secure against quantum attacks. Unlike other = PQC candidates such as SPHINCS+ and ML-DSA, Falcon offers significantly sma= ller signature and public key sizes, as well as efficient signing and verif= ication times. It is implemented in pure C and does not require external de= pendencies.

Benchmarking & Results
Aspect = Falcon ECDSA
Public Key Size (B) 897 33
Signature Size (B) 655 71
Verification Time (=CE=BCs) 57 120
<= br>Verification time is more critical than signature creation time in Bitco= in, since signature creation is performed by clients (wallets), while nodes= focus on verification.

Integration
  • Falcon was included into the codebase from the original GitHub repos= itory.
  • The build= system (CMakeLists.txt) was updated to support Falcon.
  • Falcon verification has been soft-f= ork enabled via a new script verification flag.
= Next Steps & Reference
This project serves as a practical demonstration of Falcon=E2=80=99s = promising performance, highlighting its advantages over currently selected = post-quantum signature algorithms such as SPHINCS+ and ML-DSA, which face s= ignificant time and space limitations. As Falcon approaches FIPS standardiz= ation, this work aims to provide a reference for future adoption and integr= ation 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/inte= gration corrections.

Best regards,
Giulio


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
<= /blockquote>

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89= dn%40googlegroups.com.


--

--
---
Abra=C3=A7os
C=C3=A1ssio Gusson

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEQm= O3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/02326d1c-9cf8-4b4c-b5dc-cdb00f76d451n%40googlegroups.com.
------=_Part_201281_1553090814.1769440908258-- ------=_Part_201280_789665324.1769440908258--