From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 23 Jan 2026 06:03:50 -0800 Received: from mail-oi1-f192.google.com ([209.85.167.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vjHlN-0003c4-CW for bitcoindev@gnusha.org; Fri, 23 Jan 2026 06:03:50 -0800 Received: by mail-oi1-f192.google.com with SMTP id 5614622812f47-45c99708c1dsf3305328b6e.3 for ; Fri, 23 Jan 2026 06:03:48 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1769177023; cv=pass; d=google.com; s=arc-20240605; b=UfdtqsWNQ6oJn8vn7sFJpbMQBO9BD4pDJaSWs03mEDI+z1vURBfMZJU7+x48QuKwNc gMz46Ujq5S0RxaSmYV9go91jkuJXCx0vLzygaZlxwpplWLszl8RgFFU4tDEa3PD/YGwI z3W+hPDUOKpMizGhvhRyZJN5/GNzcedLkSgYdOn+RdWJAG8FU2lO8tNcQj6opJqkw/Tu JJdM2cE32kRcXyLhBJieLIyCYCqoHxngUsltXrHRMITGWBJ8JpdGdwLuJVab0R+25Jg8 KwO/1/p5H62wn+b5WeCLwPXOjmdQcyaqFjq1d8m0+sdua9E5F22GX0EkM9ZXKJ+D3A7O xM+g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:sender :dkim-signature:dkim-signature; bh=Q8qYKbgzRXZencrNJkV9klXpJ4S/ZE4/kIZlv0QCOx0=; fh=TjCrWcYUWZ/EXkaLAFzqAft/bJiICfqU/s7Bx9ryWgg=; b=SCfBvm0fiPfkGRLqvhSBQuWx0nMd1akqYT8LiRyflC06p3mPnp+SpzjnD0+hxK0tt1 9t+1+vf74rm+fjHnvfh9CrT6HavhAUiz2iNPF00iFrlmBWI68jPseUD6JGc+GYRhxItz 8K/jF2qKWseb7QYmQFHjCrljxaSJfXoxH4JAsyLwHMILQUPN7APkdDawSWqa4hwQ/bN4 o/WKWOAz+Rj871dyM4qE7ueRnZaVqA59JnnUObE1XsOGD+zpshwxrsBwgdEJebCP4oKq oay4Hrm5D6RpCTIGdgyV1R6DTSltr0GabsT9XtunBXcIfiTirKYTo5dk+7mOFV3S79K9 UH4A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=jWjU8Nbf; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=golinelli.giulio13@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1769177023; x=1769781823; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:user-agent:references:in-reply-to :date:cc:to:from:subject:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=Q8qYKbgzRXZencrNJkV9klXpJ4S/ZE4/kIZlv0QCOx0=; b=wY0ZQaX+39MTLz/XUn9qtfv/Zgm4IAVb9lhtnhb6F5MKJMozLPi3v01syaJJS/knYj xq07p4NRsEHYcsEssckZ7EpF6lehE9Q3d5L8+vlZSEoyii1ZkXAU3xUeJanxRijK4IdQ d5lEFtH5Y9oy2qRY7NWSBHyKMGoSYyKfhMifaTtkP0XT1+e8bxqkE4Xzt3zCGbF5ndSL d2S3pMm6nVrF6cDjuat8I8So+y58MT/lb5+iX3ptdchMOG13t8SIC0KbTqwC6y3jcFvV 8fpqexpr814uBzKaM1fYXSD5BcVtMpXpuaCikXFhY9wvvqWrX7dr1g8rSe4OioYg2/WR JZYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769177023; x=1769781823; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:user-agent:references:in-reply-to :date:cc:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=Q8qYKbgzRXZencrNJkV9klXpJ4S/ZE4/kIZlv0QCOx0=; b=QepmezUqbFnREZhpGqMPC4/9D/923QXK3meu7zqsb6dpYZqiZf3qvMNj1mhHd0lPak h9q1LXwFbGEoa7eg96HSPJbXlYC7nmrJyI+XxeIi0WyJH/mkmp1V1h5HA4XxVttMpn9A lJ5tOPMAOdlu2tovhC85ghiKFr96tS7sOKTiPgfZ1H41sd1dCVgohxRjmtXvh7stqpZl GPMw21QOrKPiKJ6txxXbtSKYzEtPwqxGZ0TfHXkK+ci2BQ6GgHNfVF2uCUri/HQf2tyF FbZ/igNS/cpQ5Fpnt8kpQd1gmxmSpGbUx+usAkJTyACaOOKaPH6GcubU1yOsgTpW6UWy GIRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769177023; x=1769781823; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:user-agent:references:in-reply-to :date:cc:to:from:subject:message-id:x-gm-gg:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=Q8qYKbgzRXZencrNJkV9klXpJ4S/ZE4/kIZlv0QCOx0=; b=icMasZvKUTSvTDKP10VkTf/8EPYHdeSP/vE1EFIVP0BNSgv5nstnEE/PcBGMC7PDD8 VlXDCvwLkrb20oDL/Hfk02pHxVThAsv5sFKcqYOwRBshxL77ztHq6KZNQUyq2GTBovDx FprAzahIGnhz2Y7I4IJNlMolTsy1b8MUF7oAWoGd35P9McdluD1+4QRvDuxn/z9Cbq4E CKzi81+Caft8aJPBl81A410wxb2KD5nNY0HgJ18VwZf0RCAhsK2l4xxBaxJrerz1ajiK AK3DWZEgLYarLDVbKeBwAl6hcy9vqG0LeZiaN8q13G3CtbuCOmizr7NEyHFf8aejhk+s ohBA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWPvxn0zIizATM8B8VifJUQCAYHHude/m0tzDkbnJE4MSpaviQgvajzmHEf8oQWIHZNkyHBcQl4YguE@gnusha.org X-Gm-Message-State: AOJu0YxT8Bg/uJEbjPxcujtvWzK9PmLovyIWQ5CvLAjW5vwA6CTAk1Ek z3xLRqyYKhCM/L9TR/q9sF6rNtr/EQalWJHWjJ9ajKkOEMzOfhk5gSNy X-Received: by 2002:a05:6808:1189:b0:45a:8cdc:784a with SMTP id 5614622812f47-45eb1d361aemr1463246b6e.62.1769177022423; Fri, 23 Jan 2026 06:03:42 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+F8vipvK77UAPsrXz4o/UNpesAgAR5TQuuhqhfGU0BzBw==" Received: by 2002:a05:6870:8197:b0:3ec:5074:681b with SMTP id 586e51a60fabf-4088263e9bfls840453fac.2.-pod-prod-06-us; Fri, 23 Jan 2026 06:03:38 -0800 (PST) X-Received: by 2002:a05:6808:1991:b0:45c:8afc:2dc9 with SMTP id 5614622812f47-45eb1d2281bmr1350616b6e.54.1769177018421; Fri, 23 Jan 2026 06:03:38 -0800 (PST) Received: by 2002:a05:620a:494b:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8c6e3fa5191ms85a; Thu, 22 Jan 2026 19:45:08 -0800 (PST) X-Received: by 2002:a05:6122:628f:b0:566:34e3:2476 with SMTP id 71dfb90a1353d-5663ea777b2mr589050e0c.3.1769139907774; Thu, 22 Jan 2026 19:45:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769139907; cv=none; d=google.com; s=arc-20240605; b=EyCHpPFMa667jpI6Ai0PpQcjirAV2sIfV0yF6BGWOstKpuV66pBEwx1kO5BW7pytAc 7RE/PJ+5OxCrXWP2+00zrJt2JdvcVzRofaYHnCYySvzZUCKvG1DmrDBucimaPFZ9OVVt +fxBBrziTgIKpD+6mGh29zhcJ+4NxKWjyJvNpPYj3UolMosyw87sMzy40yB6SkUXTCZ/ 3E1FLFAHQJ7JeIZQ7SLhmtQD9HYHcd4OzEKy/rjUzQFqlFN5kRucIU75T5fFXyyUVnv4 FFZ981JB6nMbySA63ZSapKJuCR9siklCqrQ9+do+/s7oMVsQaK76ROjXaoyQv0DzF1eg gFlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:user-agent:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=Dt6ynjnrMDhCRxKLBL5y5ZOzjJEGqq6ax5+sVTb6qJ4=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=DxSH+VGkPbKXdedaKNlJ4ABb7dNqXAqq3o4w8G2laZuJIGWmHSXNuo7+dBmq8x/p1K 8vm21w9UhvPcXpjHhuZ4mnl8wCn8J2UW/O6kpseRQ7nuTcWbJdSOS6AR2lTP5hm3jg3U VRuGniTyHzcjzs+7fae5lZ7ckiwhL0sGXrGbcwu+pedmCWG+sbVJf/URCL8tsaXF0Mv3 D2wWUMM9PeJ7XTGNCBPreupiQRp6pPd7WpI9w2ye+LRis5/2+cXq4hBT0xmR36QcO2wn i9/RFO3n9C+9IsQudqCnedZxPjkxTjpUxrHHbwh9YenOYVGpZgq7AM45rINiU7BypdlV ks/A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=jWjU8Nbf; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=golinelli.giulio13@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com. [2607:f8b0:4864:20::1033]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-5663fb57767si46968e0c.6.2026.01.22.19.45.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 19:45:07 -0800 (PST) Received-SPF: pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) client-ip=2607:f8b0:4864:20::1033; Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-3530715386cso1747864a91.2 for ; Thu, 22 Jan 2026 19:45:07 -0800 (PST) X-Gm-Gg: AZuq6aJVsabbPNwrtSVE39yNTIEvUVNylX9/WYboObng8EUiFVoOlOGg0NxEaaoAA3r fw3sHrwdsYHBN6kzpTnhNa+mS2mc5HpJ14iu17a0SwJNxnsS8jUmK95bS6DFUsbHtzfBANz+VOT K9NruwUwz1jM3WhvrjcIxfUA8jA44nE9jD7CeHtmJbamWMTappE+52Qy6g7o9H55Nit7k1sSuMk llnHefV/tQNr6575lyB0tIhkffeB6yp2QzNL0zyHZ3zR6BPxqkjVODfOfeP6g6t+orCNFcj5jrT qSXnC3AwnTbwXvMHMrKgdpm3gVNMUZHAww5XGUJyQB1o+iBg3jVHNHf3dCXKwFrSxZoXgQ9GpbC dJoDSPKGzKrLulbPTmnXjbLsZg1Y3dcy086Vjkb7Jq0P5mUcVAZsIwxukFjueZu45rgESTWIgk7 iD7S4wTrucQOREX1u9eUn4ScyM6hY= X-Received: by 2002:a17:90b:2fd0:b0:340:bfcd:6afa with SMTP id 98e67ed59e1d1-35367007f0amr1537429a91.8.1769139907061; Thu, 22 Jan 2026 19:45:07 -0800 (PST) Received: from [192.168.1.92] ([154.211.165.131]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3536dc3e1aasm674112a91.12.2026.01.22.19.45.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 19:45:06 -0800 (PST) Message-ID: Subject: Re: [bitcoindev] Re: Falcon Post-Quantum Signature Scheme Proposal From: Giulio Golinelli To: waxwing/ AdamISZ Cc: Bitcoin Development Mailing List Date: Fri, 23 Jan 2026 11:45:04 +0800 In-Reply-To: References: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com> Content-Type: multipart/alternative; boundary="=-x2Jc0TGUQSaXIEW1g8tM" User-Agent: Evolution 3.52.3-0ubuntu1.1 MIME-Version: 1.0 X-Original-Sender: golinelli.giulio13@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=jWjU8Nbf; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=golinelli.giulio13@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --=-x2Jc0TGUQSaXIEW1g8tM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adam, thanks a lot for the thoughtful question =E2=80=94 it=E2=80=99s 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=E2=80=99re referring to is technically called signature aggregatio= n, which is distinct from batch verification. Signature aggregation relies on a linear homomorphic algebraic structure that is inherent to Schnorr signatures, and it=E2=80=99s precisely this property that enables construct= ions 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 =E2= =80=94 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=E2=80=99m still relatively new to Bitcoin, so if I=E2=80=99ve = 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! >=20 > Forgive the rather ignorant question here, but: >=20 > 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). >=20 > 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. >=20 > Cheers, > AdamISZ/waxwing >=20 >=20 > On Thursday, January 22, 2026 at 4:09:34=E2=80=AFAM UTC-3 Giulio Golinell= i > wrote: > > Hi everyone, > >=20 > > 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]. > >=20 > > 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. > >=20 > > Benchmarking & Results > > Aspect=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Falcon=C2=A0 =C2=A0 ECDSA > > Public Key Size (B) 897=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A033 > > Signature Size (B) 655 =C2=A0 =C2=A0 =C2=A0 =C2=A0 71 > > Verification Time (=CE=BCs) 57 =C2=A0 =C2=A0 =C2=A0 =C2=A0 120 > >=20 > > Verification time is more critical than signature creation time in > > Bitcoin, since signature creation is performed by clients > > (wallets), while nodes focus on verification. > >=20 > > 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=E2=80=99s > > 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. > >=20 > > 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. > >=20 > > Best regards, > > Giulio > --=20 > 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 > bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-0933= f41ff398n%40googlegroups.com > [2]. [1] this fork https://github.com/thisisnotgcsar/bitcoin-falcon [2] https://groups.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-09= 33f41ff398n%40googlegroups.com https://groups.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-09= 33f41ff398n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter --=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/= e13546d438e0b871b8d6a4b449ce5c27b47cb765.camel%40gmail.com. --=-x2Jc0TGUQSaXIEW1g8tM Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ad= am,

thanks a lot for th= e thoughtful question =E2=80=94 it=E2=80=99s 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=E2=80=99re referring to is technically called signature aggregation, wh= ich is distinct from batch verification. Signature aggregation relies on a = linear homomorphic algebraic structure that is inherent to Schnorr signatur= es, and it=E2=80=99s precisely this property that enables constructions lik= e MuSig. Unfortunately, this kind of structure is not something we get acro= ss the post-quantum signature landscape (whether standardized or exotic sch= emes).

L2 ZK rollups can mitigate this by verifying many user signat= ures off-chain and proving the resulting state transition with a single suc= cinct proof, effectively collapsing many verifications into one on L1. In a= post-quantum setting, LaBRADOR ([https://eprint.iacr.org/20= 22/1341.pdf](https://eprint.iacr.org/2022/1341.pdf)), a lattice-based S= NARK 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 m= ay be a key part of the toolbox to mitigate the absence of aggregation and = efficient batching =E2=80=94 at least until we discover a PQ signature sche= me with Schnorr-like advantages. Considering it took roughly 30 years from = RSA to reach Schnorr, we should expect that fully realizing such a post-qua= ntum 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=E2=80=99m = still relatively new to Bitcoin, so if I=E2=80=99ve made any incorrect assu= mptions 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!
<= br>
Forgive the rather ignorant question here, but:
Given the obvious that we have a problem with size on-chain (an= d I'm aware you've focused here specifically on the most plausible scheme t= hat has the least ridiculously large size, and yet it's still 20x larger), = has there been comparison of the possibility of batched signing (not batche= d *verification*, but signing) in different PQ schemes, with a view to a CI= SA 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 fu= ngibility (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 specifical= ly can't support any kind of batched signing, but I have no idea whether th= at's correct.

Cheers,
AdamISZ/waxwing


On Thursday, January 22, 2026 at 4:09:34=E2=80=AFAM= UTC-3 Giulio Golinelli wrote:
Hi = everyone,

I am to share a technical demonstration and benchmarking p= roject that integrates the Falcon post-quantum signature scheme (Falcon-512= ) into Bitcoin Core, implemented as a soft-fork within the classic P2WPKH m= ode. This work aims to provide a practical reference for possible future Fa= lcon 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 sche= me designed to be secure against quantum attacks. Unlike other PQC candidat= es such as SPHINCS+ and ML-DSA, Falcon offers significantly smaller signatu= re and public key sizes, as well as efficient signing and verification time= s. It is implemented in pure C and does not require external dependencies.<= br>
Benchmarking & Results
Aspect      &nbs= p;                    Fal= con    ECDSA
Public Key Size (B) 897         33
Signature Size (B) 655         71
Verification Time (=CE=BCs) 57 &nb= sp;       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.t= xt) was updated to support Falcon.
  • Falcon verification has been sof= t-fork enabled via a new script verification flag.
N= ext Steps & Reference
This project serves as a practical demonst= ration of Falcon=E2=80=99s promising performance, highlighting its advantag= es over currently selected post-quantum signature algorithms such as SPHINC= S+ 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 th= ink and if this could be of interest for which case I can complement the pr= oject by integrating Falcon into all the other spending paths. I also look = forward to development/integration corrections.

Best regards,
Giu= lio

--
You received this message be= cause you are subscribed to a topic in the Google Groups "Bitcoin Developme= nt Mailing List" group.
To unsubscribe from this topic, visit http= s://groups.google.com/d/topic/bitcoindev/PsClmK4Em1E/unsubscribe.
To= unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@= googlegroups.com.
To view this discussion visit https://group= s.google.com/d/msgid/bitcoindev/e7977710-22ca-477c-b8cd-0933f41ff398n%40goo= glegroups.com.

<= /div>

--
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/bitcoi= ndev/e13546d438e0b871b8d6a4b449ce5c27b47cb765.camel%40gmail.com.
--=-x2Jc0TGUQSaXIEW1g8tM--