From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 28 Jan 2026 12:49:37 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vlCTo-0004vP-ON for bitcoindev@gnusha.org; Wed, 28 Jan 2026 12:49:37 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-4088136faccsf718803fac.2 for ; Wed, 28 Jan 2026 12:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1769633370; x=1770238170; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to: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=IFUzgEJP96ld2QC867p7di8ot/ER8XszyVwEbqYafEY=; b=MvaVoFOadgBg3GaDAmcDAN0lFh+SSLCZ3mVzG/sJlU6ojodSihur/0BfgiqsC5ZIzF qpfPd+Rkne+oEES6lzWDZmOMEwTKP0Er0q3Qd4inC3dtEPgCO3H5uRzr0SaUXh+EA3Mj 4X44UJjhKnK6+OEpimsl5anBm1Miqf4e55xIDdEzhg/Fi21k+CNMy/BKc/Fl6fWXtaRi HyfXQaKIdtflLaYRghbJN9S/zoo7YA/F9t87LjNaUlXAuPgJjiCcE2+Q5z/3NNxqnbkG tFOsygvwgsh7h1Wd3llTsU4q65rjv3oB/DOm7Tnj3oLltljm8z3tjmRY/BhiicgyDbn5 RD+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769633370; x=1770238170; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IFUzgEJP96ld2QC867p7di8ot/ER8XszyVwEbqYafEY=; b=B2Sj2/1vmN1PIRiZuZeM2Y2G7eZusruhWyQgSEk7fcKmbpflmOImJG8XsXG83AWCrj 5Xhy1momUh5RP9h8dgGwHhxOd0xKLc0BSkVzziCAAWKKcKSRIPOyqt3v694mt9j+mUPy qk6W2gjSQu7R7UCATMYAY4yORQA/lhTzcgVlxR2gayG+OM47MBk3leqxyZ0Forunie7X BMVY9IjxgUihm7Ios+o74+4Fbz/qP2PfNy6l6n1tTY+dR3T/T4FsvVAm/VlR5uIqiQYz rkMMwe3+9921x+KPOCxN18jZzXe558mhgadWcvmLdjsYYnmBbXJnESx42fVecofvs2Pa kDKg== X-Forwarded-Encrypted: i=1; AJvYcCWEwEkJdtZiRetarzvtrVfcmElK29jII3ukB8uA+Wi9TzYkS7pCfN36CGXpR4gfGNjlUJQHBVhJ/6Ww@gnusha.org X-Gm-Message-State: AOJu0YzA5gXpng2sv4UVmvApZ8UYTo4j5LHdrvHZmOP2Vbs5vnZWqd7V d2j97JFJtnsQPjUUyd7wbgUqO0hHKgIdL8s2e1nriZhYhf4UHxlt/god X-Received: by 2002:a05:6820:151e:b0:65e:d467:147c with SMTP id 006d021491bc7-662f20f8cd8mr3377721eaf.71.1769633370258; Wed, 28 Jan 2026 12:49:30 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Ei2+bIjJYxbk+puacu2bHMfVR6a6iiFyedvcT61bz0qg==" Received: by 2002:a05:6820:22aa:b0:65b:2551:35e7 with SMTP id 006d021491bc7-66307d06e6cls37817eaf.1.-pod-prod-07-us; Wed, 28 Jan 2026 12:49:25 -0800 (PST) X-Received: by 2002:a05:6808:a588:10b0:45f:4d8:38a4 with SMTP id 5614622812f47-45f04d8802amr2482026b6e.41.1769633365543; Wed, 28 Jan 2026 12:49:25 -0800 (PST) Received: by 2002:a05:690c:9218:10b0:790:b655:de0c with SMTP id 00721157ae682-7943c3c42b7ms7b3; Tue, 27 Jan 2026 08:39:08 -0800 (PST) X-Received: by 2002:a05:690c:6612:b0:794:5b17:7acd with SMTP id 00721157ae682-7947ab2f346mr18782547b3.21.1769531948066; Tue, 27 Jan 2026 08:39:08 -0800 (PST) Date: Tue, 27 Jan 2026 08:39:07 -0800 (PST) From: "'conduition' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <3c9eb86f-13e0-4a18-b978-9fea89d4f6e8n@googlegroups.com> In-Reply-To: <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> 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_3476_2045595046.1769531947616" X-Original-Sender: conduition@proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) ------=_Part_3476_2045595046.1769531947616 Content-Type: multipart/alternative; boundary="----=_Part_3477_445590573.1769531947616" ------=_Part_3477_445590573.1769531947616 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would be happy to be proven wrong, and to learn that Falcon is actually= =20 very easy to implement. Of all the NIST PQC schemes, Falcon is the one I=20 understand least, so I may be mistaken. But software emulation of floating= =20 point arithmetic doesn't sound easy, especially if getting it wrong means a= =20 potential forgery attack. Also, there is still discrete Gaussian sampling= =20 to contend with. > SPHINCS+ cannot be considered a valid fallback as it introduces large=20 signature overhead (it's not meant for bitcoin-like use-cases). I disagree. I think it's crucial for us to have a conservative stateless=20 signing scheme ready as a fallback to authenticate the UTXO set if a CRQC= =20 appears. Though the signatures are indeed large, that can be mitigated by= =20 smaller parameter sets as Mikhail mentioned, or if you're OK with losing=20 NIST compatibility, using the SPHINCS+C variant and friends.=20 > Any TPM-based state management would reduce performance and compatibility= =20 across architectures It doesn't have to be a TPM=20 .=20 My point is that if your wallet *can* manage state in some way, XMSS makes= =20 for really tiny, fast, and easy-to-implement signatures. Even if some=20 platforms can't hack it, others would happily make the trade-off. It=20 doesn't hurt that unbalanced XMSS disincentivizes address reuse as well. regards, conduition On Friday, January 23, 2026 at 7:03:46=E2=80=AFAM UTC-7 Giulio Golinelli wr= ote: > 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 deterministic= =20 > Falcon mode (see author=E2=80=99s notes=20 > ) which uses= =20 > software floating-point emulation . This eliminates side-channel risks=20 > associated with non-constant-time hardware FPUs. It is also SNARK-friendl= y=20 > and overcomes portability limitation. While this sacrifices the performan= ce=20 > optimizations of true FPUs, signing speed is not critical in Bitcoin, whe= re=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 are= =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 degradatio= n=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 hard= er=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-f= alcons-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 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 produce= =20 > very small sigs (148b) and pubkeys (65b) using some convoluted mathematic= al=20 > tricks. However, much like Falcon, it is still immature and needs more=20 > researchers to optimize its verification, explore its strengths, and atta= ck=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 Falco= n=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 designed= =20 > to be secure against quantum attacks. Unlike other PQC candidates such as= =20 > SPHINCS+ and ML-DSA, Falcon offers significantly smaller signature and=20 > public key sizes, as well as efficient signing and verification times. It= =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), whil= e=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 prom= ising=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 adoptio= n=20 > and integration in Bitcoin. > > Let me know what you think and if this could be of interest for which cas= e=20 > I can complement the project by integrating Falcon into all the other=20 > spending paths. I also look forward to development/integration correction= s. > > Best regards, > Giulio > > > --=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/= 3c9eb86f-13e0-4a18-b978-9fea89d4f6e8n%40googlegroups.com. ------=_Part_3477_445590573.1769531947616 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would be happy to be proven wrong, and to learn that Falcon is actually v= ery easy to implement. Of all the NIST PQC schemes, Falcon is the one I und= erstand least, so I may be mistaken. But software emulation of floating poi= nt arithmetic doesn't sound easy, especially if getting it wrong means a po= tential forgery attack. Also, there is still discrete Gaussian sampling to = contend with.

> SPHINCS+ cannot be considered a val= id fallback as it introduces large signature overhead (it's not meant for b= itcoin-like use-cases).

I disagree. I think it's= crucial for us to have a conservative stateless signing scheme ready as a = fallback to authenticate the UTXO set if a CRQC appears. Though the signatu= res are indeed large, that can be mitigated by smaller parameter sets as Mi= khail mentioned, or if you're OK with losing NIST compatibility, using the = SPHINCS+C variant and friends.=C2=A0

>=C2=A0<= span style=3D"font-family: Arial, Helvetica, sans-serif;">Any TPM-based sta= te management would reduce performance and compatibility across architectur= es

It doesn't have to be a TPM. My point is that if your wallet c= an manage state in some way, XMSS makes for really tiny, fast, and easy= -to-implement signatures. Even if some platforms can't hack it, others woul= d happily make the trade-off. It doesn't hurt that unbalanced XMSS disincen= tivizes address reuse as well.

regards,
conduition
On Friday, January 23, 2026 at 7:03:46=E2=80=AFAM UTC-7 Giulio Gol= inelli wrote:
Falcon (FN-DSA) relies on discrete gaussian sampling using constant-t= ime floating point arithmetic for signers, which is very hard to implement = quickly and in constant time (securely).
This is true for the fir= st Falcon version published (randomized mode of operation). This implementa= tion uses the author-recommended deterministic Falcon mode (see=C2=A0author=E2=80=99s notes)=C2=A0which uses software floating= -point emulation . This eliminates side-channel risks associated with non-c= onstant-time hardware FPUs. It is also SNARK-friendly and overcomes portabi= lity limitation. While this sacrifices the performance optimizations of tru= e FPUs, signing speed is not critical in Bitcoin, where verification domina= tes node activity.

If small signatures are your goal, then I= 'd look into=C2=A0SQI= sign
This would be good like many other PQ exotic schemes but= all of these are far from being standardized soon.
=

If you wa= nt a PQC scheme that's ready=C2=A0today=C2=A0and al= so provides small signatures, I'll point you to XMSS, and=C2=A0Jonas Nick's SHRINCS proposal. You can configure an unbalanc= ed XMSS tree to get 272 byte signatures, potentially smaller if you crank u= p the parameters. The catch is a dependence on statefulness.=C2=A0

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 i= s very hard to implement quickly and in constant time (securely). Despite b= eing 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 foll= owing BIP360.


While I wouldn'= ;t rule out Falcon permanently, I personally feel more research is needed t= o explore Falcon, its weaknesses, and how flexibly it can be adapted to sch= emes like CISA, BIP32, and multisignatures. Let it bake a little longer.

If small signatures are your goal, then I'd lo= ok into SQIsign, which uses isogeny-= based cryptography to produce very small sigs (148b) and pubkeys (65b) usin= g some convoluted mathematical tricks. However, much like Falcon, it is sti= ll immature and needs more researchers to optimize its verification, explor= e its strengths, and attack its weaknesses.=C2=A0

Jonas Nick's S= HRINCS proposal. You can configure an unbalanced XMSS tree to get 272 b= yte signatures, potentially smaller if you crank up the parameters. The cat= ch is a dependence on statefulness.=C2=A0

regard= s,
conduition
On Wednesday, January 21st, 2026 at 11:09 PM, Giulio Golinelli = <golinelli...@gmail.com&g= t; wrote:

Hi everyone,

I am to share a technical dem= onstration and benchmarking project that integrates the Falcon post-quantum= signature scheme (Falcon-512) into Bitcoin Core, implemented as a soft-for= k within the classic P2WPKH mode. This work aims to provide a practical ref= erence for possible future Falcon adoption, especially as it approaches FIP= S standardization.
You can find details at this fork.

Falcon is = a lattice-based, post-quantum digital signature scheme designed to be secur= e 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
Pu= blic Key Size (B) 897 3= 3
Signature Size (B) 655 71
Verification Time (= =CE=BCs) 57 120

Verification time is more criti= cal than signature creation time in Bitcoin, since signature creation is pe= rformed by clients (wallets), while nodes focus on verification.

Integration
    =
  • Falcon was included into th= e codebase from the original GitHub repository.
  • The build system (CMakeLists.txt) was upd= ated to support Falcon.
  • Falcon verification has been soft-fork enabled via a new script ver= ification flag.
Next Steps & Reference
This project serves as a p= ractical demonstration of Falcon=E2=80=99s promising performance, highlight= ing its advantages over currently selected post-quantum signature algorithm= s such as SPHINCS+ and ML-DSA, which face significant time and space limita= tions. 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 c= omplement the project by integrating Falcon into all the other spending pat= hs. I also look forward to development/integration 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/3c9eb86f-13e0-4a18-b978-9fea89d4f6e8n%40googlegroups.com.
------=_Part_3477_445590573.1769531947616-- ------=_Part_3476_2045595046.1769531947616--