From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 23 Jan 2026 06:03:53 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vjHlQ-0003cD-Mx for bitcoindev@gnusha.org; Fri, 23 Jan 2026 06:03:53 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-4081db82094sf5600242fac.0 for ; Fri, 23 Jan 2026 06:03:52 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1769177026; cv=pass; d=google.com; s=arc-20240605; b=BnzigntIYF/nL/hkaSPfvSGNvZpaURjPHMHY+cbBRIFilKZ7mCfJbkaQ9R1aicp6/8 a6gEpQir9PqnDnwnbmVEL6QeqdpypKs6bu9Juady12Y3i3+F76saywLBEuJIxSSJNb2g zz+wVOH/bpG606f9cMmjtQYOB4p0qgwed5gHYDePFkfPtqHvfWbHc7pmJcB462CDrzjH ef8OwKqpJQSpixH44i2rFBCAdNq0LNtfDh7NLDrvnEQz5vWzY5emam5ycAOpc/sGw6N1 mlIyaU5MaGUB4jut+1OzjheqsZlKPHwD0mXjzdcdv9e0kbrAQLxXnMEuFEO5gicA1Zts BpRQ== 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=76Q4StJsbvleszU9jYPLE9iEcnAd2HCA+LAyA/JbC4I=; fh=eupQQku1uY0mBS1Dufdclsju/GZQZAJjsGQXry5cRtg=; b=dBD72N4lbzaa2LyI5RQ0anJndpLmfNEkMgrcl6V1SlgtWJSMhkoh09xZpEqx48zlmH XmEeBhM0pkGx0yBk9PsfnGHXF8JZ/g82nL9KJO+TJ9w+GEVZuDd56694lEUbvEHK4DXJ 2C7GA72FuhLSRSiPL/MM4bWRGZyPm11wgcV4eq4+yRZE9LOSmD6I+FTWCB53mVaMzAKu yb9iHIOAAnS1mTEo7LN+KqnFuNtPQrL3QQj+1qiGl4QwCWZjeKQdWy6da7sBc0bfA71s 9pKa80ospCbAXhS/+v3G6jz2U/SwMhibas+FSqpPTnh2I2zw9usbb0kHClKBBq03Jm14 rQ3g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="dfL4Hno/"; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::62d 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=1769177026; x=1769781826; 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=76Q4StJsbvleszU9jYPLE9iEcnAd2HCA+LAyA/JbC4I=; b=KdRgEZrpCNxZ5Ibtk4r3SwTDRU5vsfXCEUbg1QbV7Xinv656JNHsJ1RKMy1oxasRTr 0tdX0m2iWlL84VDzmY1jAdY7ifwjYS9xSNZjjX6AMw2FMQ7YDa3vyBXhCb5RLLgda5Wv 4XFfmgWeS0O7fSiigykAlOTMIaYE0TG6NPBVrr5cPFcXdSokuBt09tzNWLrX1BaEFNqG sMgK2dPP+4mmQL+vWVvLDkCsHiHOmXvwbdef6W7a62YaZWGqyko7eKabLkhc74lvs5oM GOdSrHi/LuTD4pgNJaQ+ExP2XBpTVSdffgm3IaTmknxaQUVvX1nrsdfKrnnj49anKsDi mxkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769177026; x=1769781826; 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=76Q4StJsbvleszU9jYPLE9iEcnAd2HCA+LAyA/JbC4I=; b=lHuxlQaQzS8eHIFWvhLo+omiJ8yZaVFQJqC4/kwUqaKDfy6IMjYuQ2zZTtm1+Lv6BS Hy8MxwWADm1mi/VqqIRqt7sy/lWmk1KHn11cElnKTBdzvJNbjoGtx2RVRfjM1jUai7uL pG/q9btQie2Wi7kgI48WzEHFNVapGO85D//jSaUx76huvuiotqxFHXiP4XJDn7nxGZye xCAInHYhJ6r+UZuJLOkyEUOkARgyBxqnUYi/UDz8zhxbCfr6xpPWoIm8b6aHa1BCDsb/ ENoIjSv9sq3lKVefODAy+3ac/pumgWilW3ab+3bAe+270PiC/ETR0BIGBq0r4hnvg3gG 6zRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769177026; x=1769781826; 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=76Q4StJsbvleszU9jYPLE9iEcnAd2HCA+LAyA/JbC4I=; b=w0e6HCwMnC8wTrGpqKq3yy56Esw+39BjFvhtt82rB9Yz6SBWYxoG+PLEqj7F05SSfv MKQ/yj07ADLvn3h1DmX2kGXSyJofmwoVMLc6u8df7alNt2r1bCQBR2oQuVgEybDU4tuy B+kI+gLfe5aguUMP2hLTyuqehDhVDLQ70ONK50/y3EDwSPR0fOQbxEQQZhObAud85IFy nqYL2VLGGw6oba98oLgRRRiGD73+tK7ynHASfQEqWb63d8RtBB4MRhmSeFlphpPLujYz gr5wIbpnrULp2M0CPWy5GjmxSEDolzyKk0UKh/QtVTfKSFGKjHTDZDzZ3EWG4iFo80ik NU/A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWfswOijYcQ9MX5KVXhrlrHZJTWPw96mgHVsVhp7gSRFwjXXGCWO/DIV4ZEx/+AXdqWjRvsnRYuzTHL@gnusha.org X-Gm-Message-State: AOJu0Yw5L7Ewxub/crPKgqtv1bmgNYWbjRcVm1sLDBkvRC6Pai4aweDz 3MlWCr6x+xOTnKQpUPUhvECy/h3lWCJKU+ojFcZfvf6YPc2xepVd00tV X-Received: by 2002:a05:6820:4a8e:b0:660:edc3:7bf2 with SMTP id 006d021491bc7-662d0782ff3mr371975eaf.64.1769177025814; Fri, 23 Jan 2026 06:03:45 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HSj2DRdyMtmv7Urq62sg9kKxdkVK8mFVzgJgc4+5/8Ow==" Received: by 2002:a05:6870:21cb:b0:3ff:9e43:57c5 with SMTP id 586e51a60fabf-408825778a8ls1348399fac.1.-pod-prod-01-us; Fri, 23 Jan 2026 06:03:41 -0800 (PST) X-Received: by 2002:a05:6808:4f08:b0:450:d833:6bb9 with SMTP id 5614622812f47-45ebb896555mr498192b6e.60.1769177021789; Fri, 23 Jan 2026 06:03:41 -0800 (PST) Received: by 2002:a05:6808:605:b0:457:b360:4f16 with SMTP id 5614622812f47-45eb4c38d87msb6e; Thu, 22 Jan 2026 23:13:04 -0800 (PST) X-Received: by 2002:a17:903:191:b0:295:290d:4afa with SMTP id d9443c01a7336-2a80ebe96dfmr3757315ad.23.1769152382690; Thu, 22 Jan 2026 23:13:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769152382; cv=none; d=google.com; s=arc-20240605; b=eqSyDqvSQ6RYDV5RaenSIVB3DYF3AGSk1WybdjN20ay00cydC7NxEa9rXAFqekqkn2 e4kwkZf2QVscb0pXqiyYjvY8UXUlN+bEHS5RrwSORDSnYVE97u43NyDzyRSeYFLs8WHN BPirv6acGuB5rZ0FgwlT7XJjVSXDqdvVXWEyStvMPbDUeNu0B5IchG9iUfgnlSVOLh2v ZdVdvHZp8xlHS+gExgzDvok3JBU/ukVp0QAAj8G8zVmnKQJBZ6fVosiMPFKUaPGX878V HV2G2DJjx2/PIOONcZR2diO5W9IsCglmJTk7wm7khRJS294GmfEjnwue7Y3dHdeIVVKG yMig== 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=PmFY8SZ7Ufyq5fv3vWW9yPCugZfqJiXpFRDYkM0mQ8A=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=J0wZcEdMTrDI2pbrUmj0+f2Vrm7P2k053jhDXMdPlbsq/XJvo2rpaOmTyq6xoI0nOs QJGwavuTFYy3Y+e3buYz2tHh4iJrQpOSfk64apP1NFQwQzTUtlWGKqMJ4sCeUi1GCWLE h3OU7u0Rbt9a/hh0M96qIhJdLI1iuusuB8ssCVrWNgNC/MISxKk8FoSxrgXFJPqAfLxi n8sB9k8VdSLcv4jV/klYJB8Ua4+tb25y4M8z64KbfOV3NxvZ5s3UIS8cbbWBK25AwH7J Zb+8y6IQVMcSL6lNMlOGCJNd2yMWlkevbUjHDrZw1pJzKl6kHCH2qGfwIEGFD6PC15Q2 5bUg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="dfL4Hno/"; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::62d 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-x62d.google.com (mail-pl1-x62d.google.com. [2607:f8b0:4864:20::62d]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2a802f9e895si470105ad.5.2026.01.22.23.13.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 23:13:02 -0800 (PST) Received-SPF: pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) client-ip=2607:f8b0:4864:20::62d; Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-2a79998d35aso12507595ad.0 for ; Thu, 22 Jan 2026 23:13:02 -0800 (PST) X-Gm-Gg: AZuq6aJ7xIJBnU7zAbrDd/fctyaFo1xMKttJ7TsvC9cdxAwLaTb8vZUQEVVGMGdjQRM 1lvQILIi2+kakjSYEjtJAgABwOboEVhKEa6tuLTcU8x3gMMriHSIXw36HHD9UntnKjvQ0AhVMXs Wr5nvvvsXfxtVLmNBm6aUsuc9ONlt31moSlnRc5V5maHaQwl9IgZ1aAOGPSZ5js9H0COCsQVfiB 9lbD1LFx0B7aNta/R42GKF9FhOrgLagYPuYnhifDqCXAmhTG8yVybelZ+uXrkjjLmcL1syButXD CV0xxQgEGi5sHzYybrtHQV4+wRMCjbwl8SH4rvZyXnI29zRJxOWOASYW4ji+DEUMRMjQ/B/2uB4 RB/7MjhcDkhYfyONlz6SpIN5z679cnZnYdPCbVa28fkUBfgYiiR9AZHolNqQww1Kj+85t7GlBJy rCA4Qke+Rlu8G+g7IDFPGe2TMOGQA= X-Received: by 2002:a17:902:ccc9:b0:2a2:dc1f:78d8 with SMTP id d9443c01a7336-2a80ec66e47mr3176975ad.42.1769152382008; Thu, 22 Jan 2026 23:13:02 -0800 (PST) Received: from [192.168.1.92] ([154.211.165.131]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a802daa66asm11131985ad.9.2026.01.22.23.13.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 23:13:01 -0800 (PST) Message-ID: <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal From: Giulio Golinelli To: conduition Cc: Bitcoin Development Mailing List Date: Fri, 23 Jan 2026 15:12:58 +0800 In-Reply-To: References: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com> Content-Type: multipart/alternative; boundary="=-i8HtsaC8ILOg3KuDe6eb" 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="dfL4Hno/"; spf=pass (google.com: domain of golinelli.giulio13@gmail.com designates 2607:f8b0:4864:20::62d 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 (/) --=-i8HtsaC8ILOg3KuDe6eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=A0which = 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. > 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. > If you want a PQC scheme that's ready=C2=A0today=C2=A0and also provides s= mall > signatures, I'll point you to XMSS, and=C2=A0Jonas Nick's SHRINCS proposa= l > [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. 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-points-f= alcons-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=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 [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/= 2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com. --=-i8HtsaC8ILOg3KuDe6eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Falcon (FN-DSA) relies on discrete gaussian sampling = using constant-time floating point arithmetic for signers, which is very ha= rd to implement quickly and in constant time (securely).
This is true for th= e first Falcon version published (randomized mode of operation). This imple= mentation uses the author-recommended deterministic Falcon mode (see <= a href=3D"https://github.com/algorand/falcon/blob/main/falcon-det.pdf">auth= or=E2=80=99s notes) which uses software floating-point emulation .= This eliminates side-channel risks associated with non-constant-time hardw= are FPUs. It is also SNARK-friendly and overcomes portability limitation. W= hile this sacrifices the performance optimizations of true FPUs, signing sp= eed is not critical in Bitcoin, where 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 b= ut all of these are far from being standardized soon.

If you want a P= QC scheme that's ready today and also provides small signatures, I'll point you to XMSS,= and 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. 
SPHINCS+ cannot be considered a va= lid fallback as it introduces large signature overhead (it's not meant for = bitcoin-like use-cases). Any TPM-based state management would reduce perfor= mance and compatibility across architectures. The hash-based nature of SHRI= NCS is highly SNARK-unfriendly, making them incompatible with emerging L2 Z= K 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.
=

On Thu, 2026-01-22 at 14:35 +0000, = conduition wrote:
Falcon (FN-DSA) r= elies on discrete gaussian sampling using constant-time floating point arit= hmetic for signers, which is very hard to implement quickly and in constant= time (securely). Despite being significantly harder to implement than ML-D= SA, 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 si= gnature opcode BIP following BIP360.

<= a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://bl= og.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achil= les">https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-point= s-falcons-achilles

While I w= ouldn't rule out Falcon permanently, I personally feel more research is nee= ded to explore Falcon, its weaknesses, and how flexibly it can be adapted t= o schemes like CISA, BIP32, and multisignatures. Let it bake a little longe= r.

If small signatures are your goal, then I= 'd look into SQIsign= , which uses isogeny-based cryptography to produce very small sigs (148b) a= nd pubkeys (65b) using some convoluted mathematical tricks. However, much l= ike Falcon, it is still immature and needs more researchers to optimize its= verification, explore its strengths, and attack 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 pa= rameters. The catch is a dependence on statefulness. 
regards,
conduition
On Wednesday,= January 21st, 2026 at 11:09 PM, Giulio Golinelli <golinelli.giulio13@gm= ail.com> wrote:

Hi everyone,

I am to share a tec= hnical demonstration and benchmarking project that integrates the Falcon po= st-quantum signature scheme (Falcon-512) into Bitcoin Core, implemented as = a soft-fork within the classic P2WPKH mode. This work aims to provide a pra= ctical reference for possible future Falcon adoption, especially as it appr= oaches FIPS standardization.
You can find details at this fork.

Why Falcon?
Falcon is a lattice-based, post-quantum digital sign= ature scheme designed to be secure against quantum attacks. Unlike other PQ= C candidates such as SPHINCS+ and ML-DSA, Falcon offers significantly small= er signature and public key sizes, as well as efficient signing and verific= ation times. It is implemented in pure C and does not require external depe= ndencies.

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), whi= le nodes focus on verification.

Integration
  • Falcon was included into the codebase from the original GitH= ub repository.
  • T= he build system (CMakeLists.txt) was updated to support Falcon.
    • =
  • Falcon verification has bee= n soft-fork enabled via a new script verification flag.
Next Steps & Ref= erence
This project serves as a practical demonstration of Falcon=E2= =80=99s promising performance, highlighting its advantages over currently s= elected post-quantum signature algorithms such as SPHINCS+ and ML-DSA, whic= h face significant time and space limitations. As Falcon approaches FIPS st= andardization, this work aims to provide a reference for future adoption an= d integration in Bitcoin.

Let me know what you think and if this cou= ld be of interest for which case I can complement the project by integratin= g Falcon into all the other spending paths. I also look forward to developm= ent/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/bitcoi= ndev/2e4abb5a847ab9d78857aee2fded500a234f68a6.camel%40gmail.com.
--=-i8HtsaC8ILOg3KuDe6eb--