From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 02 Feb 2026 15:37:07 -0800 Received: from mail-qt1-f184.google.com ([209.85.160.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vn3Td-0006nq-Q1 for bitcoindev@gnusha.org; Mon, 02 Feb 2026 15:37:07 -0800 Received: by mail-qt1-f184.google.com with SMTP id d75a77b69052e-5033c6265d2sf161551391cf.2 for ; Mon, 02 Feb 2026 15:37:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770075419; cv=pass; d=google.com; s=arc-20240605; b=aTf/QoWiOAmsm7XAeKT3vQP5aKYoDW+f42NHsGBd9LaLEG34ZoGvX/ll2g9MH9TBib t0+hyY1LGR/Q0xKxIZfMla5rmqI944saCuqGK0dj4wGtdm6+/OJTifu2atLOLT1Yc7Bx 3HC9MKbO58nMN5UB2WaYhKmx7KYAaUhMhOKOuepFPRIAiNvfVUaX1MzSn+nZ+45sY8Ml BnsfpsDZir6BNrrOP9kVsnt9MKRcoh79JvSvvwd/bN2v0f9xIag0HjspOiESt82B2uA+ we/SHhTQyYk9o0IZwRUvts9GTnBMVo49PnOKqrA9OJGp2hgz24ZebT7OiNoby2BEe1op 1fkw== 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=NXSOkTP63pdfQYzLt+my2bmYr1cn9RFlcOWrkMw85lA=; fh=Fbh1uYAGrCI9PfMK2mIE9g9oJkeBbNQr42peXg55hug=; b=fSxKpko9cvcrbjQ2RkwjGhln0WUvR+/JIwG3aibixrOp/HytM9BCMJQI8tX0OryR15 jB2LFrQ5VI0172+MrdUuz7qoBhRUFNwCwhL3eeoENmm6GYkyLkvQgThdJfFAz6Af6J5f Pgg6i2MyUwRiyTTZht39ocl+awIGjNiIRDtGlxfRV1f2SjfOtiD1EZNHGa5tsc3Oncn2 3iBe3HQ3/3glgJ796HszUdnQLMeDO7fZV1nAux17Y5cAWr++4+375LE5zRXWhun+9R5d 2I3zKk1vgGcPLjmMWmtd33lFaSRScWZDZsGmSuir2KZK2M4PvcZQsKeCSzpR+XnGpe8K Xmvg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=JDsf9jMn; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::643 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=1770075419; x=1770680219; 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=NXSOkTP63pdfQYzLt+my2bmYr1cn9RFlcOWrkMw85lA=; b=G9wv8GVURPgsTJLx4HY2kYMN0MhWUUw4ZdtSKs46V58+H1TI8r9Zf7xxjEfBE2CO6o HiVfIH3dDOktEHXCkg6GMunFBfEpD3Yevjq8UpWGyM4ARbyaz9JVXZYZEEjDUYsyQTDK LTBPIIGuRRJvi9A1sWKnRquMr2A13sISNTos7ryPGXOWJzr5oOzHnYiBNfs8rYp6HemI RwwrxqhAk43ZMS6iM3hJLjriL+gwJytw2Bx5iEvO3Yg5aJX8GeOS3+LMZ/qEIUO6HvSH wwJvp+ImujxIL/Yrd3s5ek86sCSadCDDxNVSPI/PzMAyC0THg3RYMELhdJLLnnBPMJ1V h0XQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770075419; x=1770680219; 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=NXSOkTP63pdfQYzLt+my2bmYr1cn9RFlcOWrkMw85lA=; b=Xz72U61eL22fqO8SHBKi1XbGtCj128dgMYFSc5hBtu18aIpyfuYJmVpUDz9VaJh/Qy UyiC1rZU98R+Ut14zCYUQm6xlCHpYUqLvzcS7E3I1u9+3Ytu6lOf1xOIQhEgJFAjU8hq c/78688ixubj+a7ofZSTUySalRXnAPmoD9o4m9ZEnTKyTT43L79wOKoWa7f5W679lD2d VHukuXw4htQO5wb6a4MUDz3xzL+Ynf+a1ljqWxJWlppqdoMw8I9PiAEVFUb2BEEkxRVW uAHansp87QDzj/T5pn2yIfDsKasu2O+iEBI5Eukj/syB9eurhoj/dZmIRdpNcgLtPwQQ XRDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770075419; x=1770680219; 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=NXSOkTP63pdfQYzLt+my2bmYr1cn9RFlcOWrkMw85lA=; b=g9IU6aoneXJVqQ/O/CcgfU/hFlrAw/yd77dpkBx6OoUNVjPskNzpp7M6tCruBuwDjd vdBv/LRlJQkJuC/vdbbSWhtYgBwsEL5eOaSfUx7lUeFCVayzBlabs04uE2Hs+/igD7lQ uJA2MHrIYv7OOqFhMXA+yDj5oNzWefMNEHYtPxJl9a/hEUyQoAWoAZyRbpLyk6gyoGIj FslLUAEgGuDGPu49J1Q5J5uQD8ItVO91uSJZKBJjsD29nnYffgzuriJd5oBRnePHQEJG qCdyeyE4wM3BDTLOTYnrCogAfVqrh584vUIS+CqFnHWt9cIHf9THYXz2YuV+L86fdCV/ L8kg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCX9RMVON9R3nEwYBentiUmfRByEd2Gi70JrW9ttNHSSzc9AEhXRBck+kbqQFJMPI+KCtkzNchSXyKFv@gnusha.org X-Gm-Message-State: AOJu0Yy8VKvfupz7zMDJLc9QW1YjynkC+kc6chD6tixWS8Uet132yDba iQP1McbOPFxcICa1XR9FsofeciYuJnjRK8zstIZVN3TXd6JuuSG5HFqN X-Received: by 2002:a05:622a:15cd:b0:4f4:de1a:7a83 with SMTP id d75a77b69052e-505d21300abmr160452431cf.1.1770075418921; Mon, 02 Feb 2026 15:36:58 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FsBhmtyjriQXJHKQtFqGRVryhf5VMkUab9cSg+IuMpIQ==" Received: by 2002:a05:622a:104:b0:501:4a3e:41ff with SMTP id d75a77b69052e-505df87695dls51552541cf.1.-pod-prod-09-us; Mon, 02 Feb 2026 15:36:51 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWtr6NzQfGdpXpUkh21qXmQqqm7a8aQzut0hZDxytp6p5RFiBSM+b1kf+4NVXvAwubu2dqifOKX013e@googlegroups.com X-Received: by 2002:a05:620a:390f:b0:8c8:8126:7772 with SMTP id af79cd13be357-8c9eb28fa17mr1561112985a.30.1770075411592; Mon, 02 Feb 2026 15:36:51 -0800 (PST) Received: by 2002:a05:6808:1250:b0:450:c180:fd79 with SMTP id 5614622812f47-45eb4d4ba50msb6e; Sat, 24 Jan 2026 05:32:09 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXgJ5g+Lt3+ijBLVeBtY/thCsHcwAzcKBgcFyXJ3jMx8M4wCjPTEt/C+sjugtM/iIyeHc93KSD8gHMJ@googlegroups.com X-Received: by 2002:a17:903:1aa4:b0:2a0:d4e3:7181 with SMTP id d9443c01a7336-2a7fe7418b8mr65585085ad.49.1769261523541; Sat, 24 Jan 2026 05:32:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769261523; cv=none; d=google.com; s=arc-20240605; b=W9q77wYAFclbkoMwmBw/c6/J+0XZTuxmbsxvwTKI2QYJmA3qUOjfdamDbrOsntoV4B 2UVBHBRHa8qHjTfz2sNJEI+mXAHHOfrzkGEI3r7YU42Xvu91icIlMRE5Vl7rKqK2dHGr UFOMVmEn+XK4fo+oZt4Zdo+/l5wOpsXQlNpo3ZadAP3KWhNOkoNw/PrN4Zdzq4MaBeod kDohd0agmUi6qbSegpkR58xcTi6Xnml+ipm79nRUb9rTrKGm1tKI5pHt/B/t/AbUnq+H 1fObjWEhRYUbmbUlQyURuB8/iMmd3sqorPVLYRXjOG6jfcpTPkxKHZW7mCxWoIevIwoE Ky3Q== 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=lF+exp+QyH0sUfjtUoPSNvmNfnzUKPCgVxAGTVGpZ9c=; fh=TdZvXWmc76e9DLu9ZscjuRXs9igXrCZ6HSQURimz52o=; b=eSZyDvVZqcM/f/WHKHRbLrZlu9CKgB2vVtBS7Os6MjJOjSjF5uSZnvs9IzSTnTxDrQ 2eBXcASk8Fd2aQVy5J+kKqnkjDRYiCFYKI2SXHO+1p3ZfDyyUemXW+46lzlxuVzOzZhH 4Lq6wxrhTH4MoBtZUywZGrDgJ/KDMBqjd1RCJMue0/UEjM+nEY4Brho68zleKWJpQ1AC PEKQ9QoHNnXTNAsanp9eKUvt3YmejsQm/grAGIVrl0VNGSjyVY4m2O2uj1a6jMFdWRvJ xCJIzi28C4910DqkfAhRXv+2N8vjgdBj6PxaW+f9vCHCWaePEwXy2OamF4O37abF5oqP sfUQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=JDsf9jMn; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::643 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-pl1-x643.google.com (mail-pl1-x643.google.com. [2607:f8b0:4864:20::643]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2a80300037bsi1837645ad.10.2026.01.24.05.32.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jan 2026 05:32:03 -0800 (PST) Received-SPF: pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::643 as permitted sender) client-ip=2607:f8b0:4864:20::643; Received: by mail-pl1-x643.google.com with SMTP id d9443c01a7336-2a0ac29fca1so23387405ad.2 for ; Sat, 24 Jan 2026 05:32:03 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUfR2gVMqJDq3E8jssJ2V0/3atQ2xMO8y8/wu8xtpL6TgtykMbkpqeGXVkBdYy5qU8RhPaAx0enNvAS@googlegroups.com X-Gm-Gg: AZuq6aKDZlvaMdBPPfmWVriaPhCsYjdICOgzpQE/hagPi975u2p5uIe+uohbBRFcdMA jSWrfmtmppLz7TQvaPvkx58+Bs9v3yLjAIrsrv7/wKbC8TqSahjhLaxke1RPZm+iC3ns0x61n+/ Jrc2Ka0eSBwxuuEYU8Jr01b5k39C8P9A6yTaMKiZpQRgfPh3j5WQimZgWwcxtIzr2asdl830IE/ nNqIqf/rfSS1Bhs9JDCD/j2zvBsmODK9je6L6yo4ZAJHbGXosjBBjznlUqD1+J6qT4exriIKgWY dd0pnVW4cNFFMsQfQ+1vNLnJNzxERY0W2/0ZwDTSXNmccuiqYom/VsnGRnjXuzcOorTO62fiCCf zGDCE9hCiFkQGOqHMXZrbFLGAVsWxjLst3URkyTfVPp+3Vlc2Cqud+B8ruM3xHCRvdVZAvlDcRa WwQMlQPBBAxYKsuA0XMJI4QoKAq9w= X-Received: by 2002:a17:902:d505:b0:2a0:abba:a2f4 with SMTP id d9443c01a7336-2a7fe444ed1mr63431865ad.2.1769261522048; Sat, 24 Jan 2026 05:32:02 -0800 (PST) Received: from [192.168.1.92] ([154.211.165.131]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a802dd09d0sm47003345ad.37.2026.01.24.05.32.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Jan 2026 05:32:01 -0800 (PST) Message-ID: <8fd0631e2db52a48d66fe74bf4ffa9dfe23f5dd5.camel@gmail.com> Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal From: Giulio Golinelli To: Mikhail Kudinov Cc: conduition , Bitcoin Development Mailing List Date: Sat, 24 Jan 2026 21:31:59 +0800 In-Reply-To: References: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com> <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> Content-Type: multipart/alternative; boundary="=-UtvwBuZ5yK6XgUHgzJ1R" 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=JDsf9jMn; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::643 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 (/) --=-UtvwBuZ5yK6XgUHgzJ1R Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mike, > how much weight should we put on adopting an explicitly SNARK- > friendly signature scheme? While such compatibility is clearly > advantageous, it does not seem to me to be=C2=A0a decisive point on its > own. What would you say? >From a security perspective it's=C2=A0irrelevant. Best, Giulio On Fri, 2026-01-23 at 16:36 +0100, Mikhail Kudinov wrote: > Hi everyone, > I am happy that the discussion on the PQ topic is active. I wanted to > add my view on the raised issues.=C2=A0 >=20 > 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 would only be invoked in > exceptional circumstances. In most realistic scenarios, the fallback > would consist of generating a single signature to move assets to a > new address. As for the statefulness problems, I agree that this is > an important drawback that we should keep in mind. >=20 > 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 efficient. >=20 > It is also a question: how much weight should we put on adopting an > explicitly SNARK-friendly signature scheme? While such compatibility > is clearly advantageous, it does not seem to me to be=C2=A0a decisive > point on its own. What would you say? > I am also unsure to what extent Falcon can be considered SNARK- > friendly. Has there been any research in this direction, or are there > benchmarks evaluating its performance in SNARK environments? >=20 > Finally, regarding SQIsign: although the signature sizes are > remarkable, I agree that we need more time for the scheme to mature > before considering adoption. >=20 > Best, > Mike >=20 > On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giulio Golinelli > wrote: > > > Falcon (FN-DSA) relies on discrete gaussian sampling using > > > constant-time floating point arithmetic for signers, which is > > > very hard to implement quickly and in constant time (securely). > > This is true for the first Falcon version published (randomized > > mode of operation). This implementation uses the author-recommended > > deterministic Falcon mode (see=C2=A0author=E2=80=99s notes [1])=C2=A0wh= ich uses > > software floating-point emulation . This eliminates side-channel > > risks associated with non-constant-time hardware FPUs. It is also > > SNARK-friendly and overcomes portability limitation. While this > > sacrifices the performance optimizations of true FPUs, signing > > speed is not critical in Bitcoin, where verification dominates node > > activity. > >=20 > > > If small signatures are your goal, then I'd look into=C2=A0SQIsign [2= ] > > This would be good like many other PQ exotic schemes but all of > > these are far from being standardized soon. > >=20 > > > If you want a PQC scheme that's ready=C2=A0today=C2=A0and also provid= es > > > small signatures, I'll point you to XMSS, and=C2=A0Jonas Nick's > > > SHRINCS proposal [3]. 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 performance and > > compatibility across architectures. The hash-based nature of > > SHRINCS is highly SNARK-unfriendly, making them incompatible with > > emerging L2 ZK rollup constructions. Moreover in high-throughput L2 > > environments, state management, limits on the number of signatures > > and performance degradation proportional to published signatures > > are critical bottlenecks. > >=20 > > On Thu, 2026-01-22 at 14:35 +0000, conduition wrote: > > > Falcon (FN-DSA) relies on discrete gaussian sampling using > > > constant-time floating point arithmetic for signers, which is > > > very hard to implement quickly and in constant time (securely). > > > Despite being significantly harder to implement than ML-DSA, it > > > only provides a mild (factor of two or so) improvement in > > > signature + pubkey size. This is why we're probably not including > > > FN-DSA in our PQ signature opcode BIP following BIP360. > > >=20 > > > https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-poin= ts-falcons-achilles > > >=20 > > > While I wouldn't rule out Falcon permanently, I personally feel > > > more research is needed to explore Falcon, its weaknesses, and > > > how flexibly it can be adapted to schemes like CISA, BIP32, and > > > multisignatures. Let it bake a little longer. > > >=20 > > > If small signatures are your goal, then I'd look into SQIsign > > > [2], which uses isogeny-based cryptography to produce very small > > > sigs (148b) and pubkeys (65b) using some convoluted mathematical > > > tricks. However, much like Falcon, it is still immature and needs > > > more researchers to optimize its verification, explore its > > > strengths, and attack its weaknesses.=C2=A0 > > >=20 > > > If you want a PQC scheme that's ready today=C2=A0and also provides > > > small signatures, I'll point you to XMSS, and Jonas Nick's > > > SHRINCS proposal [3]. 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 > > >=20 > > > regards, > > > conduition > > > On Wednesday, January 21st, 2026 at 11:09 PM, Giulio Golinelli > > > wrote: > > >=20 > > > > 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 [4]. > > > >=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 Falcon ECDSA > > > > Public Key Size (B) 897 33 > > > > Signature Size (B) 655 71 > > > > Verification Time (=CE=BCs) 57 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=99= s > > > > promising performance, highlighting its advantages over > > > > currently selected post-quantum signature algorithms such as > > > > SPHINCS+ and ML-DSA, which face significant time and space > > > > limitations. As Falcon approaches FIPS standardization, this > > > > work aims to provide a reference for future adoption and > > > > integration in Bitcoin. > > > >=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 [1] author=E2=80=99s notes https://github.com/algorand/falcon/blob/main/falcon-det.pdf [2] SQIsign https://sqisign.org/ [3] Jonas Nick's SHRINCS proposal https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-sig= natures-with-static-backups/2158 [4] this fork https://github.com/thisisnotgcsar/bitcoin-falcon --=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/= 8fd0631e2db52a48d66fe74bf4ffa9dfe23f5dd5.camel%40gmail.com. --=-UtvwBuZ5yK6XgUHgzJ1R Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mike,

=
how much weight should we put on adopting an = explicitly SNARK-friendly signature scheme? While such compatibility is cle= arly advantageous, it does not seem to me to be a decisive point on it= s own. What would you say?
From a security perspective it's irrelevant.

Best,
Giulio

On Fri, 2026-01-23 at 16:36 +0100, Mikhail Kudinov wrote:
Hi everyone,
I = am happy that the discussion on the PQ topic is active. I wanted to add my = view on the raised issues. 

For the fallback in SHRINCS, o= ne option is to use SPHINCS+ as a fallback with a limited number of signatu= res. By setting an upper bound as large as 2^30 or 2^40, the signature size= can be significantly reduced, and the scheme would only be invoked in exce= ptional circumstances. In most realistic scenarios, the fallback would cons= ist of generating a single signature to move assets to a new address. As fo= r the statefulness problems, I agree that this is an important drawback tha= t we should keep in mind.

The SHA-based SPHINCS+ is indeed not parti= cularly efficient in SNARK settings. But one could replace the hash functio= ns with SNARK-friendly alternatives (for example, Poseidon) in the future, = which will make it much, much more efficient.

It is also a ques= tion: how much weight should we put on adopting an explicitly SNARK-friendl= y signature scheme? While such compatibility is clearly advantageous, it do= es not seem to me to be a decisive point on its own. What would you sa= y?
I am also unsure to what extent Falcon can be considered SNARK-friend= ly. Has there been any research in this direction, or are there benchmarks = evaluating its performance in SNARK environments?

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

Bes= t,
Mike

On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM= Giulio Golinelli <golin= elli.giulio13@gmail.com> wrote:
=
Falcon (FN-DSA) relies on disc= rete gaussian sampling using constant-time floating point arithmetic for si= gners, which is very hard to implement quickly and in constant time (secure= ly).
This is true for the first Falcon version published (randomized mode of= operation). This implementation uses the author-recommended deterministic = Falcon mode (see author=E2=80=99s notes) which= uses software floating-point emulation . This eliminates side-channel risk= s associated with non-constant-time hardware FPUs. It is also SNARK-friendl= y and overcomes portability limitation. While this sacrifices the performan= ce optimizations of true FPUs, signing speed is not critical in Bitcoin, wh= ere verification dominates node activity.

If small signatures are your = goal, then I'd look into SQIsign
<= div>This would be good like man= y other PQ exotic schemes but all of these are far from being standardized = soon.

If you want a PQC scheme that's ready today<= /i> and also provides small signatures, I'll point you to XMSS, and Jonas Nick's SHRINCS proposal. = You can configure an unbalanced XMSS tree to get 272 byte signatures, poten= tially smaller if you crank up the parameters. The catch is a dependence on= statefulness. 
SPHINCS+ cannot be considered a valid fallback as it in= troduces large signature overhead (it's not meant for bitcoin-like use-case= s). Any TPM-based state management would reduce performance and compatibili= ty across architectures. The hash-based nature of SHRINCS is highly SNARK-u= nfriendly, making them incompatible with emerging L2 ZK rollup construction= s. Moreover in high-throughput L2 environments, state management, limits on= the number of signatures and performance degradation proportional to publi= shed signatures are critical bottlenecks.

On Thu, 2026-01-22 at 14:35 +0000, conduition wrote:
Falcon (FN-DSA) relies on discrete gauss= ian sampling using constant-time floating point arithmetic for signers, whi= ch is very hard to implement quickly and in constant time (securely). Despi= te being significantly harder to implement than ML-DSA, it only provides a = mild (factor of two or so) improvement in signature + pubkey size. This is = why we're probably not including FN-DSA in our PQ signature opcode BIP foll= owing BIP360.


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

<= div style=3D"font-size:14px">If= small signatures are your goal, then I'd look into SQIsign, which uses isoge= ny-based cryptography to produce very small sigs (148b) and pubkeys (65b) u= sing some convoluted mathematical tricks. However, much like Falcon, it is = still immature and needs more researchers to optimize its verification, exp= lore its strengths, and attack its weaknesses. 

=
If you want a PQC scheme that's ready today and also provi= des small signatures, I'll point you to XMSS, and J= onas Nick's SHRINCS proposal. You can configure an unbalanced XMSS tree= to get 272 byte signatures, potentially smaller if you crank up the parame= ters. The catch is a dependence on statefulness. 

regards,
conduition
On Wednesday, January 21st, 2026 at 11:09 PM, Giul= io Golinelli <golinelli.giulio13@gmail.com> wrote:

Hi eve= ryone,

I am to share a technical demonstration and benchmarking proj= ect that integrates the Falcon post-quantum signature scheme (Falcon-512) i= nto Bitcoin Core, implemented as a soft-fork within the classic P2WPKH mode= . This work aims to provide a practical reference for possible future Falco= n adoption, especially as it approaches FIPS standardization.
You can fi= nd details at this fork.

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

Benchmarking & Res= ults
Aspect Falcon ECDSA
Public Key = Size (B) 897 33
Sign= ature 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.
bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoi= ndev/8fd0631e2db52a48d66fe74bf4ffa9dfe23f5dd5.camel%40gmail.com.
--=-UtvwBuZ5yK6XgUHgzJ1R--