From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 24 Jan 2026 12:12:46 -0800 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vjjzx-0000x3-DW for bitcoindev@gnusha.org; Sat, 24 Jan 2026 12:12:46 -0800 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-662c4cee18fsf7086525eaf.0 for ; Sat, 24 Jan 2026 12:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1769285559; x=1769890359; 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=HPUSZRqY3Ibb3g2c09Jq1vPgBSTH2iNGHD0bWsWCP+w=; b=YzEhYRDgAPpHbsOUT2hMGFlSwxfMlM6pElT1IvPn+4msffCfrbi71fK9YSOmvDFeeH 7cnK0OGlIWKxnkAosXyQ78H13fohHwXH7jtEJEmL0QKzeMJeMK9tQDw+lQJqZwqybnnn ++6pWIAbSG6cXbL9QWpBeSbaquTYTtaBPu2LKD1tczg6JUGThVuV3UFl9rdXpd0LrSe6 daXmfot1Q1m8IewcZ4GyTobaKM5tTi/Qm6AolUFzNlO4UjuwTCfSJvxnBKaCG3XETwOn esxhlXtURdqXmRuC9NvsgQ1MCJMyjtGEmF+Mfsz9Fhh7+eNzGZYsZ3YilMPvwCPX7QDd 76Kw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769285559; x=1769890359; 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=HPUSZRqY3Ibb3g2c09Jq1vPgBSTH2iNGHD0bWsWCP+w=; b=adoLWyuGRH1a9be8qiLPufHyvP5QGebUpFijj1t856dlvGIylPbDi2hIifVUWuGMxq TREQyKa5j1P7oXLTnu6EXq/UNnG60mcv1PA8vGEXwePJRB89T31rf41OzvEBguZj3pgd S+pHKJmmhdtZOuXj/hiRKmhRiXJ9vAqV0QTUVEA2dep/Za806J0lc2EIWkxUzmuvJCqP jOO2fhuxOLkM/8/CJTTqNo2a4vF3tbiV+p6EAElbBOLRaBMxMKtssSBbhTu2SJZ8W2HM 71AYNjK0tgqVdITZCr0GUIxTAG2U6CGDngxUwAtuV3ZTWYUYRKhxa8zwZpTF+mAv8d2/ kCHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769285559; x=1769890359; 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=HPUSZRqY3Ibb3g2c09Jq1vPgBSTH2iNGHD0bWsWCP+w=; b=r1zKV9LBP09mK3SODQTK2o3F0BHcGzYhCEmnOcHtyUOdFW5RPw0kZBWFH/pcvzu4Po GBASIx7w7c/+a0SpBSMS82BBmKlTxlkkWz4uBJGVKfPnq7zWnJWYlwHgwbe9IM7Krayo K6P/o02uMQKhc130NTyVTXmRHg0YTcrCqutJ8HnjSHTt9Wf2FuMn4vdDcaKCiqJkF+Zw i1WGGvpAX1ptfZAh3DRgTRkJdcCI0KzCT2WH6435GyUSDgiMTXBLPwFLEyCJkDrZhRqK o2h1r94nvyOm7LxmvUI3NmykLRK9o2RR1jXVkFjuS14/vmo08fxMNROUTTMuzKdr4zCk SkVw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVuHDu8N6IhQR/GThaSIK6Qsn+VZJF3+1VrOjUc1f7ktR92Xmx2AJ47ajdORTbhQDc5ePmHX/In+/DE@gnusha.org X-Gm-Message-State: AOJu0Yzir4j1/sdmcMi8iWl645fKxgj+hKsZrcdJw60pBLXry7pW+Wn7 c2pbUvDovlaVFYERdA+ZwW1nOqFK7jLSTrVd9+sqSTpCYXC+LWhmNTQD X-Received: by 2002:a05:6820:810c:b0:65f:69f7:d0f2 with SMTP id 006d021491bc7-662cabd8649mr2955630eaf.77.1769285558743; Sat, 24 Jan 2026 12:12:38 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+H/OGZRY/7Gj+QBXXTg5auTrgrS+ZDjFpYR68qG3XNs6A==" Received: by 2002:a05:6820:488c:b0:65f:cda0:ed7a with SMTP id 006d021491bc7-662b6efab12ls481258eaf.1.-pod-prod-00-us-canary; Sat, 24 Jan 2026 12:12:32 -0800 (PST) X-Received: by 2002:a05:6808:1589:b0:45c:71fa:9d65 with SMTP id 5614622812f47-45eb2338e39mr3885381b6e.27.1769285552548; Sat, 24 Jan 2026 12:12:32 -0800 (PST) Received: by 2002:a05:690c:e044:10b0:794:37f9:8276 with SMTP id 00721157ae682-7943c3ea260ms7b3; Sat, 24 Jan 2026 05:04:29 -0800 (PST) X-Received: by 2002:a05:690c:4c05:b0:78f:cd29:51b9 with SMTP id 00721157ae682-79439edcdb4mr58083827b3.10.1769259868228; Sat, 24 Jan 2026 05:04:28 -0800 (PST) Date: Sat, 24 Jan 2026 05:04:27 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <46faf0c0-d60d-49a4-83c5-8fe03f11c89dn@googlegroups.com> In-Reply-To: References: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com> <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_124504_586409237.1769259867603" 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_124504_586409237.1769259867603 Content-Type: multipart/alternative; boundary="----=_Part_124505_269314230.1769259867603" ------=_Part_124505_269314230.1769259867603 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 not=20 quantum resistant". Are STARKs the only realistic option in this scenario?= =20 I am enormously ignorant about STARKs, but I do seem to recall that they=20 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=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 say a= =20 STARK op-code then, job done. You'd just somehow have to have sufficiently= =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 scenarios= =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 Schnorr= =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 as=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 guess= =20 the most interesting one is: "is STARK realistically the only game in town= =20 here?". Cheers, AdamISZ/waxwing On Friday, January 23, 2026 at 1:34:36=E2=80=AFPM UTC-3 Mikhail Kudinov wro= te: > Hi everyone, > I am happy that the discussion on the PQ topic is active. I wanted to add= =20 > my view on the raised issues.=20 > > For the fallback in SHRINCS, one option is to use SPHINCS+ as a fallback= =20 > with a limited number of signatures. By setting an upper bound as large a= s=20 > 2^30 or 2^40, the signature size can be significantly reduced, and the=20 > 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 keep = 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 is= =20 > clearly advantageous, it does not seem to me to be a decisive point on it= s=20 > own. What would you say? > I am also unsure to what extent Falcon can be considered SNARK-friendly.= =20 > Has there been any research in this direction, or are there benchmarks=20 > evaluating its performance in SNARK environments? > > Finally, regarding SQIsign: although the signature sizes are remarkable, = I=20 > agree that we need more time for the scheme to mature before considering= =20 > adoption. > > Best, > Mike > > On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giulio Golinelli =20 > wrote: > >> Falcon (FN-DSA) relies on discrete gaussian sampling using constant-time= =20 >> floating point arithmetic for signers, which is very hard to implement= =20 >> quickly and in constant time (securely). >> >> This is true for the first Falcon version published (randomized mode of= =20 >> operation). This implementation uses the author-recommended deterministi= c=20 >> Falcon mode (see author=E2=80=99s notes=20 >> ) which=20 >> uses software floating-point emulation . This eliminates side-channel ri= sks=20 >> associated with non-constant-time hardware FPUs. It is also SNARK-friend= ly=20 >> and overcomes portability limitation. While this sacrifices the performa= nce=20 >> optimizations of true FPUs, signing speed is not critical in Bitcoin, wh= ere=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 ar= e=20 >> 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 degradati= on=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 constant-time= =20 >> floating point arithmetic for signers, which is very hard to implement= =20 >> quickly and in constant time (securely). Despite being significantly har= der=20 >> to implement than ML-DSA, it only provides a mild (factor of two or so)= =20 >> improvement in signature + pubkey size. This is why we're probably not= =20 >> 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=20 >> research is needed to explore Falcon, its weaknesses, and how flexibly i= t=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 produce= =20 >> very small sigs (148b) and pubkeys (65b) using some convoluted mathemati= cal=20 >> tricks. However, much like Falcon, it is still immature and needs more= =20 >> researchers to optimize its verification, explore its strengths, and att= ack=20 >> 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 mode.= =20 >> This work aims to provide a practical reference for possible future Falc= on=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 designe= d=20 >> to be secure against quantum attacks. Unlike other PQC candidates such a= s=20 >> SPHINCS+ and ML-DSA, Falcon offers significantly smaller signature and= =20 >> public key sizes, as well as efficient signing and verification times. I= t=20 >> 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 (=CE=BCs) 57 120 >> >> Verification time is more critical than signature creation time in=20 >> Bitcoin, since signature creation is performed by clients (wallets), whi= le=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 pro= mising=20 >> performance, highlighting its advantages over currently selected=20 >> post-quantum signature algorithms such as SPHINCS+ and ML-DSA, which fac= e=20 >> significant time and space limitations. As Falcon approaches FIPS=20 >> standardization, this work aims to provide a reference for future adopti= on=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 oth= er=20 >> spending paths. I also look forward to development/integration correctio= ns. >> >> Best regards, >> Giulio >> >> >> --=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/2e4abb5a847ab9d78857aee2fde= d500a234f68a6.camel%40gmail.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/= 46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com. ------=_Part_124505_269314230.1769259867603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike,

> It is also a question: how mu= ch 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 w= hat we really mean by SNARK, apart from the literal definition?
W= hat 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 quant= um 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 la= rge proofs, so at least in theory that's a problem for such planning?
=

Or maybe there's another PQ SNARK scheme that I'm jus= t 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 mechan= ism 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 someho= w have to have sufficiently small STARK proofs which is AIUI not trivial, e= ven with nice hash functions. If not, we're back to the current hyper-sophi= sticated scenarios of things like Glock and BABE where you use garbled circ= uits, witness encryption, and also need something like the adaptor primitiv= e 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 tha= t is of course "fraud proof" style, with "slashing", and not anywhere near = as clean a design as "just verify the STARK".

Ho= w 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=E2=80=AFPM UTC-3 Mikhail Kudinov wrote:
Hi everyone,
I am happy that the discussion on the PQ topic is act= ive. I wanted to add my view on the raised issues.=C2=A0

For the=C2= =A0fallback 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 woul= d only be invoked in exceptional circumstances. In most realistic scenarios= , the fallback would consist of generating a single signature to move asset= s 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 SPH= INCS+ 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 efficient.=

It is also a question: how much weight should we put on adopting an= explicitly SNARK-friendly signature scheme? While such compatibility is cl= early advantageous, it does not seem to me to be=C2=A0a decisive point on i= ts own. What would you say?
I am also unsure to what extent Falcon can b= e considered SNARK-friendly. Has there been any research in this direction,= or are there benchmarks evaluating its performance in SNARK environments?<= br>
Finally, regarding SQIsign: although the signature sizes are remarka= ble, I agree that we need more time for the scheme to mature before conside= ring adoption.

Best,
Mike

On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giulio Golinell= i <golinelli...@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 qui= ckly and in constant time (securely).
This is true for the first Falcon vers= ion published (randomized mode of operation). This implementation uses the = author-recommended deterministic Falcon mode (see=C2=A0author=E2=80=99s notes)=C2=A0which uses software floating-point emula= tion . This eliminates side-channel risks associated with non-constant-time= hardware FPUs. It is also SNARK-friendly and overcomes portability limitat= ion. While this sacrifices the performance optimizations of true FPUs, sign= ing speed is not critical in Bitcoin, where verification dominates node act= ivity.

If small signatures are your goal, then I'd l= ook into=C2=A0SQIsign
Th= is 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=C2=A0today=C2=A0and also provides smal= l signatures, I'll point you to XMSS, and=C2=A0Jonas Nic= k'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.=C2=A0
SPHINCS+ cannot be consid= ered a valid fallback as it introduces large signature overhead (it's n= ot meant for bitcoin-like use-cases). Any TPM-based state management would = reduce performance and compatibility across architectures. The hash-based n= ature of SHRINCS is highly SNARK-unfriendly, making them incompatible with = emerging L2 ZK rollup constructions. Moreover in high-throughput L2 environ= ments, 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 consta= nt-time floating point arithmetic for signers, which is very hard to implem= ent quickly and in constant time (securely). Despite being significantly ha= rder 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 no= t including FN-DSA in our PQ signature opcode BIP following BIP360.<= /div>


While I wouldn't rule out Falcon perm= anently, I personally feel more research is needed to explore Falcon, its w= eaknesses, and how flexibly it can be adapted to schemes like CISA, BIP32, = and multisignatures. Let it bake a little longer.

SQIsign, which uses isogeny-based cryptography to p= roduce very small sigs (148b) and pubkeys (65b) using some convoluted mathe= matical tricks. However, much like Falcon, it is still immature and needs m= ore researchers to optimize its verification, explore its strengths, and at= tack its weaknesses.=C2=A0

If you want a PQC sch= eme that's ready today=C2=A0and also provides small signatures, = I'll point you to XMSS, and Jonas Nick's SHRINCS proposal. Yo= u can configure an unbalanced XMSS tree to get 272 byte signatures, potenti= ally smaller if you crank up the parameters. The catch is a dependence on s= tatefulness.=C2=A0

regards,
conduitio= n
On Wednesda= y, January 21st, 2026 at 11:09 PM, Giulio Golinelli <golinelli...@gmail.com> wrote:

Hi everyone,

I am to share a technical demonstrat= ion and benchmarking project that integrates the Falcon post-quantum signat= ure scheme (Falcon-512) into Bitcoin Core, implemented as a soft-fork withi= n the classic P2WPKH mode. This work aims to provide a practical reference = for possible future Falcon adoption, especially as it approaches FIPS stand= ardization.
You can find details at this fork.
=

Why Falcon?<= /b>
Falcon is a latti= ce-based, post-quantum digital signature scheme designed to be secure again= st quantum attacks. Unlike other PQC candidates such as SPHINCS+ and ML-DSA= , Falcon offers significantly smaller signature and public key sizes, as we= ll as efficient signing and verification times. It is implemented in pure C= and does not require external dependencies.

Benchmarking & R= esults
Aspect Falcon ECDSA
Public Ke= y Size (B) 897 33
Si= gnature Size (B) 655 71
Verification Time (=CE=BCs)= 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.
<= font face=3D"Arial, Helvetica, sans-serif">
Integration
  • Falcon was included into the codeba= se from the original GitHub repository.
  • The build system (CMakeLists.txt) was updated to su= pport Falcon.
  • Fa= lcon verification has been soft-fork enabled via a new script verification = flag.
--
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.

--
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/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegroups.com.
------=_Part_124505_269314230.1769259867603-- ------=_Part_124504_586409237.1769259867603--