From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 23 Jan 2026 08:34:43 -0800 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vjK7O-00009g-5L for bitcoindev@gnusha.org; Fri, 23 Jan 2026 08:34:43 -0800 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-45e9fe1b808sf3470923b6e.0 for ; Fri, 23 Jan 2026 08:34:41 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1769186076; cv=pass; d=google.com; s=arc-20240605; b=HIvlpy6QmTWLinTzGC88Cv5D+qqXhwiNx70vu/vk64pYDpe71tvDVkevO5wHXfHNLJ aZN6pLtScOp0FU5521cHJtG3s+vS0WB37ScjJjFqHSoE4/+alTzLHCy0uGDwl1nI2fIw ZY3+2GMgUSrZ2ixpEYaFY07bXtgv0QX7cFXVOviqgMUKInXCuqh7swdlJj5maEyH8dVN MQAZGTlqtWIGiKngk5XiPO25HuZYIUv8ZkbtulmDVD959GaLiM4bnCgAhzPSMnTnxFbC yuXKe647w4rFenPKMcv7J7vq6KPBKKAZnJFiaZFHeb2K9bIw9UmATrzDgfHzPqOI2n44 ZMaQ== ARC-Message-Signature: i=3; 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:reply-to:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:dkim-signature; bh=A7jZMtyMe71LtZP9thno21ezoB20oSf0sv7VF4P6zi4=; fh=oDUoBr9C+e0Cj+F8VvwPgV/7U0VFbCzEcgwMs8+Lv1s=; b=gZfAgxGfenSNDQuS5q8HXXBVPPRmbWAdzxRZnrJU1hrr119dWU/mwrzwYomGE7FBG5 1SauAgF9mTfr6jLeWSYqovLjuwwdurbJUUmUv5M4Gs1NKhRuv/UYC/J7ueJm4Qt38Zr7 4JQZl4ha3NjyCDXHxoVo14wXiIkWt0bO6+Mdj7INBUdNgcwM+gaL1IfG8aIjh2i14tp4 OulpLMkcxtuJDuPMhPYbf4931yFFwvdKLGhk4tbzePMCCsKYpR0ANw898FpMaGAGNisu CrDES42QdNSOD/C7WWLiRkBrh2gFN3gcGx8PwVWs7nIgyySYQexrMNklC0uzT5g97Edk aOfg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=JMF3OwJf; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=mkudinov@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1769186076; x=1769790876; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=A7jZMtyMe71LtZP9thno21ezoB20oSf0sv7VF4P6zi4=; b=Ug64NCPTlGP4ubM+oswNGsLooqRXImNuNFzQEwqkENY+O0r7DmboVeyb5Hi8OVpfMz Nj3mGQzPh42haXa5mc0bYNvGGfo8kZPYvABT69mC3bUa4ihwaagi6jo0/9sSDlQDh+p+ IYFPyewlDLzD6zneKCqZhZkBz4H6LInrYv670P3JunWPqQXtK7mq7ZgFR11mDhzVHG4q AJhoI1ZS/UZ/ak+cAzW8QCtRPHO1XwCvIUJ1urRNV4erPx7JGm6YCZIfrAC8Vcz8Xbbi 23yigbyM027txfXOooJCx7CJqcM3/oWy7IV5XVPndZAKszv8wT5bNaXleNPlC0YLuAWp +TZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769186076; x=1769790876; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:x-gm-gg :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A7jZMtyMe71LtZP9thno21ezoB20oSf0sv7VF4P6zi4=; b=ASHPBAsAfBJRYlW6oY4AqWjexGUW1kwoWRL9YETMiMKvN87KAnX6qJoDCMwn1T7a/6 6T5/kvOBwpGyiurwLYFokDUA/9XX5tgj2BXUAfNJHNC9fafcarZNrDlRfM4v/GZ5O0Xo xze6ekLurWFRsyVFu/s3Jc4msAYyGlYh0C/Qa+wsPxEhk5wF6JdcYH9JYYiIS+T+T3t1 Spmmnb1VPYpNdyH0x7ruckSqAG0Rgl18zIN93K/xDI/edObJT5dhVXwIDZe7HEkxG886 wR2cakDQj8hBCVNGS0O9eViXgWXFZrnGFeqCCizbluWMQsaizDVn/BZF8tlto0pCCQed hpdA== X-Forwarded-Encrypted: i=3; AJvYcCUEK+AK4f3o+XXiek0DQ55KqmYTljCIIfLC8dhE4n6CaPr8CLLsDY6P2dja7uwRCepCkrfwaq5WuA/Q@gnusha.org X-Gm-Message-State: AOJu0YwhtBfoEWF1dLom6H1fBYAu6Oxpy+hNu+ROZkA3JbPnCdiNAvVz wMn196Zlv55KYaqqxpXmo2IB1H970KniVeVUtQcFqQ0dpq0et8rYmo72 X-Received: by 2002:a05:6820:1894:b0:65d:4d4:e7c9 with SMTP id 006d021491bc7-662caad7475mr1553526eaf.8.1769186075720; Fri, 23 Jan 2026 08:34:35 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GntcEMBuaP3gm9f+kkklLDeKm9fRs7IBZ6eQB1gYm7hw==" Received: by 2002:a05:6820:1690:b0:65f:1dcf:88b6 with SMTP id 006d021491bc7-662c1ca391als1187457eaf.0.-pod-prod-09-us; Fri, 23 Jan 2026 08:34:31 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCW/WExosxfNEi9jMwcGDH0Aa7OmUKNC4W1AkwhVXz7OP5WeFOt957bnA6IfqIFJm9Sr8U+BWfE3m/9n@googlegroups.com X-Received: by 2002:a05:6808:1316:b0:45c:916b:ef9d with SMTP id 5614622812f47-45eb1a7dde4mr1632991b6e.9.1769186071363; Fri, 23 Jan 2026 08:34:31 -0800 (PST) Received: by 2002:a7b:c044:0:b0:471:13aa:415a with SMTP id 5b1f17b1804b1-4804dff037bms5e9; Fri, 23 Jan 2026 07:37:07 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUsLiS9aF+oKp/TbPMZqzOXkrOLKpdChe/VokorrPt+Y0q5caCLAXVnAduz3GYHEoDi3i2BU3ML0jHP@googlegroups.com X-Received: by 2002:a05:600c:8b09:b0:480:1e9e:f9b with SMTP id 5b1f17b1804b1-4804c960f04mr60333395e9.16.1769182624812; Fri, 23 Jan 2026 07:37:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1769182624; cv=pass; d=google.com; s=arc-20240605; b=G14J5ioYUEEWBgjJrEgPOQpVhMSc53S02aHJgp0PSAX02xtyBqXkoIGVYrGGKYEVZL q+cgj2fJOrrGkdF3YY+P5ImVN1AdQfZAaA1i0IWzWeQLEQm7W3Sv9MxklApCRmBhUOUi cquJmEg9KmNeZIrGGxS2y6eDfi9DeHlOEb0qx4G6ihp88nbSUJ1Np6Oea9yrfdXYxnCU KfbVBfuDlEBk9P49nscxxTpaYS+cuNvcZRs+9Bz9URHu+wTSf1co7yff1I09skgLHFrT itHsH0vrMCx4lFShzxAWkOlKMDXA19T1zJhc7a8KAVQOVdxi15vmpGXDawcwFltqH191 7ffA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=2axRDmfdqRwPbWOTx0YYxDLRpL9i+HZvnUzWLUN1ptQ=; fh=l1TkMYu0AFGuMNT9xJW7aSigiXeT/nw3Birmk4SSvNU=; b=CFThpD6vV6PGcYko+Sgw+pWsSxNC2dlScpgShtqyjv8Bml4IdNN8snYt6+XyhV1JnY CsYqp7ryKVW4j7cydeVpigN4NhqDWn4w8uEF3/2wm05lR2+D6TOvKy/YkGDj47vmdeey UC2z3mUIrEz9Cg8TvClTqW5uuKkmBNZpx9IjQ17sY35wgu8wTuYnYUEOibmMd2afu6jB 1ndZkG47Kquo+DQ7JBG+e//DBCjidV9JXmVjSWyqRv4C3pUfsltFHRonB1/SnJpLMivv i5hGFC7o5yu0AkrkDwGaDCskRdf1GFr2XD+13/BgS9gyPfdZz6n8RcWVJerUjWXQe7rD JmRg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=JMF3OwJf; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=mkudinov@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com. [2a00:1450:4864:20::136]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4804db5d467si157385e9.3.2026.01.23.07.37.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jan 2026 07:37:04 -0800 (PST) Received-SPF: pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::136 as permitted sender) client-ip=2a00:1450:4864:20::136; Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-59dd784efddso289339e87.1 for ; Fri, 23 Jan 2026 07:37:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769182624; cv=none; d=google.com; s=arc-20240605; b=WpenHfQTjvGON3E8xGrrts9fTlYMDKF9WNHzXc0eY1sRwHeGyKOVwdxUDUFGmBcpVh TKbvoa3/pyx6hTNQuCCt904AzsxX3TBWARWGYVp9xBt2Gv+ku7p99EdeK23HbWZLtS8d W7mKam/CT6hzpA3/yO00Hv6Eu7B8zgTSvgdfkIR8JQ36FIwDsNSLeHY/cZC+6WGVnVBu p/NA/tmu3BqPCOc7H3lmZney56D8Uo8hLMzKSNG21VWwzeZrxCxnLidJTmajT2lhHKHr SqjUlzsxWP72PKucWzuBDb8V0UHi/w3eQa3buHINtpyps/NtMZUEiC3y0awwajiLKUeu zRTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=2axRDmfdqRwPbWOTx0YYxDLRpL9i+HZvnUzWLUN1ptQ=; fh=l1TkMYu0AFGuMNT9xJW7aSigiXeT/nw3Birmk4SSvNU=; b=EiEXW392+5kPGY2pJ5XgNO+v6goGPg1nbWUmugkS3n7A9tpmFpHTh/W3YgxKc5FjRK Cd2x74PVVonXydXQqM2NMv2ddkxAdUw29dN79+wqNoWiPdz4KxxdUjmqGe6xmfEGHGLj LRaMMyvfh8FI9KYaM11zi4yQ/2JEINBIhPp5k1Z8n7Zw84Bg8hM/a9Mbi4obIHk4VtO9 bR8CODzOwTK7tJOeGt0DMMDp1EfCyAaUg6KlR+FNq+cOxJQeCbyGoZN7hYdSaT5EK1Z9 U/dyQUmQd1L2eD5k1sBsSPYLB3QhdPUZbdj8WyP9TKxA3rRXimRZeIu1tHCI16y1MUxd 31lQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCXc2ajzJNNf576C5tHoJ4/qKhZFcQrn+GVfT8zt8qAKDvUGjPF/zM9mxVLUGTJE+e3LmtXtW/jU2fpu@googlegroups.com X-Gm-Gg: AZuq6aJF8yuaSKMQc/h6HD71wjt4kfx8/v/DHgmCnCXQyrUR25bngek6idxHqJOmTrC XP44BLOCUJQ8v9+wL1rOQEUVGeYpD7/DwlMVBiMwUP7wa1eYkgWWy/3GC0Co7pldkWbnrqhR1so loN75PQISl855hJ6DuZGea+2r6B8YFvsFTknrv0o/w06Xt56NeDJBstMdAAemrcGK1UrwBTHXZZ wnEmYjGddv+eSoSsS2ZcGU+/TSDi1AOH6RrOaEK1LqQdxT7Si1/OfCmK3gG50j51S6HzEPNMpye lSFVkq0= X-Received: by 2002:a05:6512:64aa:b0:59b:7291:9cd8 with SMTP id 2adb3069b0e04-59de4929897mr510278e87.7.1769182623641; Fri, 23 Jan 2026 07:37:03 -0800 (PST) MIME-Version: 1.0 References: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com> <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> In-Reply-To: <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" Date: Fri, 23 Jan 2026 16:36:53 +0100 X-Gm-Features: AZwV_QhcR69k9JN-LP3lDgAOWAfBScr3mKUjA_2KRzXFh8xXvf84WFe7CPd1-z8 Message-ID: Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal To: Giulio Golinelli Cc: conduition , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000d33f6606490fed87" X-Original-Sender: mkudinov@blockstream.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=JMF3OwJf; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=mkudinov@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com X-Original-From: Mikhail Kudinov Reply-To: Mikhail Kudinov 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 (-) --000000000000d33f6606490fed87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 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. 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 more efficient. 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 a 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? Finally, regarding SQIsign: although the signature sizes are remarkable, I agree that we need more time for the scheme to mature before considering adoption. Best, Mike On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giulio Golinelli < golinelli.giulio13@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 > 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 author=E2=80=99s notes > ) which uses > software floating-point emulation . This eliminates side-channel risks > 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, whe= re > verification dominates node activity. > > If small signatures are your goal, then I'd look into SQIsign > > > This 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 *today* 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, > potentially smaller if you crank up the parameters. The catch is a > dependence on statefulness. > > 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 degradatio= n > 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 > floating point arithmetic for signers, which is very hard to implement > quickly and in constant time (securely). Despite being significantly hard= er > 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. > > > 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 > 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. > > If small signatures are your goal, then I'd look into SQIsign > , which uses isogeny-based cryptography to produce > very small sigs (148b) and pubkeys (65b) using some convoluted mathematic= al > tricks. However, much like Falcon, it is still immature and needs more > researchers to optimize its verification, explore its strengths, and atta= ck > its weaknesses. > > If you want a PQC scheme that's ready *today* 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, > potentially smaller if you crank up the parameters. The catch is a > dependence on statefulness. > > regards, > conduition > On Wednesday, January 21st, 2026 at 11:09 PM, Giulio Golinelli < > golinelli.giulio13@gmail.com> wrote: > > Hi everyone, > > I am to share a technical demonstration and benchmarking project that > integrates the Falcon post-quantum signature scheme (Falcon-512) into > 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 find 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 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 > Bitcoin, since signature creation is performed by clients (wallets), whil= e > nodes focus on verification. > > *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 prom= ising > 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 adoptio= n > and integration in Bitcoin. > > Let me know what you think and if this could be of interest for which cas= e > I can complement the project by integrating Falcon into all the other > spending paths. I also look forward to development/integration correction= s. > > Best regards, > Giulio > > > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded= 500a234f68a6.camel%40gmail.com > > . > --=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/= CAPcK4uSY_fz9jGb8QrL7j4giqq2pGZ6K%3DCuPOzjQdqoMZgYPAw%40mail.gmail.com. --000000000000d33f6606490fed87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,
I am happy that the discu= ssion on the PQ topic is active. I wanted to add my view on the raised issu= es.=C2=A0

For the=C2=A0fallback in SHRINCS, one option is to use SPH= INCS+ as a fallback with a limited number of signatures. By setting an uppe= r bound as large as 2^30 or 2^40, the signature size can be significantly r= educed, and the scheme would only be invoked in exceptional circumstances. = In most realistic scenarios, the fallback would consist of generating a sin= gle signature to move assets to a new address. As for the statefulness prob= lems, I agree that this is an important drawback that we should keep in min= d.

The SHA-based SPHINCS+ is indeed not particularly efficient in SN= ARK 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 s= hould we put on adopting an explicitly SNARK-friendly signature scheme? Whi= le 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 performa= nce in SNARK environments?

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

Best,
Mike

On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giulio Golinelli <<= a href=3D"mailto:golinelli.giulio13@gmail.com">golinelli.giulio13@gmail.com= > wrote:
=
Falcon (FN-DSA)= relies on discrete gaussian sampling using constant-time floating point ar= ithmetic for signers, which is very hard to implement quickly and in consta= nt time (securely).
This would be good like many other PQ exotic schemes but all of thes= e are far from being standardized soon.

If you want a P= QC scheme that's ready=C2=A0today=C2=A0and also pro= vides small signatures, I'll point you to XMSS, and=C2=A0<= a href=3D"https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quant= um-signatures-with-static-backups/2158" title=3D"Jonas Nick's SHRINCS p= roposal" target=3D"_blank">Jonas Nick's SHRINCS proposal. You can c= onfigure an unbalanced XMSS tree to get 272 byte signatures, potentially sm= aller if you crank up the parameters. The catch is a dependence on stateful= ness.=C2=A0
SPHINCS+ cannot be considered a valid fallback as it introduces = large signature overhead (it's not meant for bitcoin-like use-cases). A= ny TPM-based state management would reduce performance and compatibility ac= ross architectures. The hash-based nature of SHRINCS is highly SNARK-unfrie= ndly, making them incompatible with emerging L2 ZK rollup constructions. Mo= reover in high-throughput L2 environments, state management, limits on the = number of signatures and performance degradation proportional to published = signatures are critical bottlenecks.

On Thu, 2026-01-22 at 14:35 +0000, conduition wrote:
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). Despite being significantly harder to implement than ML-DSA, it only p= rovides 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 o= pcode BIP following BIP360.


While I wouldn't rule= out Falcon permanently, I personally feel more research is needed to explo= re Falcon, its weaknesses, and how flexibly it can be adapted to schemes li= ke CISA, BIP32, and multisignatures. Let it bake a little longer.
If small signatures are your goal, then I'd look into= SQIsi= gn, which uses isogeny-based cryptography to produce very small sigs (1= 48b) and pubkeys (65b) using some convoluted mathematical tricks. However, = much like Falcon, it is still immature and needs more researchers to optimi= ze its verification, explore its strengths, and attack its weaknesses.=C2= =A0

If you want a PQC scheme that's ready today=C2=A0and also provides small signatures, I'll point you to X= MSS, and Jonas Nick's SHRINCS proposal.= You can configure an unbalanced XMSS tree to get 272 byte signatures, pote= ntially smaller if you crank up the parameters. The catch is a dependence o= n statefulness.=C2=A0

regards,
condu= ition
On Wedn= esday, January 21st, 2026 at 11:09 PM, Giulio Golinelli <golinelli.giulio13@gmail= .com> wrote:

Hi everyone,

I a= m to share a technical demonstration and benchmarking project that integrat= es 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, espec= ially as it approaches FIPS standardization.
You can find details at this fork.
<= font face=3D"Arial, Helvetica, sans-serif">
Why Falcon?
Falcon is a lattice-based, post-quan= tum digital signature scheme designed to be secure against quantum attacks.= Unlike other PQC candidates such as SPHINCS+ and ML-DSA, Falcon offers sig= nificantly smaller signature and public key sizes, as well as efficient sig= ning and verification times. It is implemented in pure C and does not requi= re external dependencies.

Benchmarking & Results
Aspec= t 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 Bitcoin, since signature creation is performed by clients (wallets= ), while nodes focus on verification.

Integration
  • Falcon was included into the codebase from the origina= l GitHub repository.
  • The build system (CMakeLists.txt) was updated to support Falcon.
  • Falcon verification h= as been soft-fork enabled via a new script verification flag.
Next Steps &am= p; Reference
This project serves as a practical demonstration of Fal= con=E2=80=99s promising performance, highlighting its advantages over curre= ntly selected post-quantum signature algorithms such as SPHINCS+ and ML-DSA= , which face significant time and space limitations. As Falcon approaches F= IPS standardization, this work aims to provide a reference for future adopt= ion and integration in Bitcoin.

Let me know what you think and if th= is could be of interest for which case I can complement the project by inte= grating Falcon into all the other spending paths. I also look forward to de= velopment/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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.goo= gle.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%4= 0gmail.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/bitcoindev/CAPcK4uSY_fz9jGb8QrL7j4giqq2pGZ6K%3DCuPOzjQdqoMZgYPAw%40ma= il.gmail.com.
--000000000000d33f6606490fed87--