From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 26 Jan 2026 04:38:04 -0800 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vkLr1-0004qF-1f for bitcoindev@gnusha.org; Mon, 26 Jan 2026 04:38:04 -0800 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-65f30d38617sf8426678eaf.1 for ; Mon, 26 Jan 2026 04:38:02 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1769431077; cv=pass; d=google.com; s=arc-20240605; b=Cc2N55C65lHi+LOIjplLl21oirCZMEbkLhgS4/v5dsmCqyOZSbl5CQrHeVS6V6Vijy frPS7G/USv+NicZGy4N8MPJgC5UH4EBIO0wFenSrOfCI0E8m2YGLkQ/UH4zvu0d2SmmO A5PQQWRpmZStEFsECFYy9GOJVFAkritpLNVIiuMtsVikfJ4+jdRzvjV2TheQ+OxB7NvH iS+SPmrjH2YceSEgkytBWaY6E724Ylr7ZLU4W636RigbnC4qzsaK9zPiRPfxnQgxnmiZ YNxnqBMvirnvUShtGdkSMom+0yrMrGW9B+IkCOEjrDtI/LU8awVuUgQ0KdkogHzzSY+z stgQ== 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=t6lR5qPNwFM8JeDMSMqLkMXiHyRAmG7ns2MoLDqG9Rw=; fh=zakJamvwlW4WOHRYyi/s3X+iNa/MfZ2FdxYNsK1y8d0=; b=A/mMPQouIURtpip9zxnuPeuA6EesxcrNHvEXqplk8gnYNTIfTFFSLEO4tKX8M3Blz0 Ahr2oFAs6cdyOi0YI65U65h/JKF20pJ1EQy72l34+fqxg4MJuOFMqnZ8a1/F6D9I4orA GJZysBMJAz/NTjdwZ86gGA0hZqNMx9mzQhRG/u4cHg9p0CRwB07j8m990ZAo5lTWv000 MxLpN2JlCoitT5dUUxSjG/Gsf6UHO1yn/Nxl9dYIR2ci+bcybVIHHEhRdgjXFeUtLmfp Y848AsV9nBnIIMxRIYzhFlgHCeqvN2xzVmcVx2GQNdIr3b7kQE1BBqd8CJBU7yv8IC6p hKWg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=JtDTQRNi; 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=1769431077; x=1770035877; 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=t6lR5qPNwFM8JeDMSMqLkMXiHyRAmG7ns2MoLDqG9Rw=; b=B7LRZcSjJK9V3jcwzs1hu29Z+O+7lErGJwS8goUqUzfoAojRepZJpvwvSrSY02fBv9 KCXJ3brzaQWJdwfaIStoxEQmH7cZ4KWSWyxAo6FYYy1P1jOxqqHcUifppIkUouC4mIfj fA1zyIIUKsTiPzVqnr7wYlI+W7LOg7i5HrV9kzet7YIKmoEsO5aWyF3p9kp+K8KFFyca 1rKFj4skX6WXZTxsRYf8eBgSfvjGia+tlzQJ0DR/ZNo8aJpyZbfMBQKLhYB8NEmnu8Yf aFLPEOUeI+tAmRQAZSq0OFIvQLfARcgpzDlw9GwuYuHL6ekv8yBu+gMxmBkQx7aZPnw6 L2mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769431077; x=1770035877; 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=t6lR5qPNwFM8JeDMSMqLkMXiHyRAmG7ns2MoLDqG9Rw=; b=WqY8ALGZ/qBw7cB6OMOWprZUFC6pCNHEbNN+9In3bqKWAlgVFKPAqiNnmVqSblmrlo neQMmJOYK977r2TbHWHo2cc/Z3kywCnwGIpoiKgvw3Xk06jftv8fft2bGCAkHF/pWDub 2H7IxFmmXf9W3kPH5JAmBUGFT0rt49Mj/Nb9qzgHU0sYSEEXmTVVH1yL+olyMu1Kcz5j 669KDMwOUkNYY2DsIeEdITvPpmLf2b87FTaLFYznjRTByUXXJkOEr8YzT6peqaqaoaGW CjebnCpz7FkEPsJb07/NPKNYjJ+fTiOxOcdz/jYHRYHbzXQYtIdP+zynbmHcfretrIDi XgBg== X-Forwarded-Encrypted: i=3; AJvYcCWkLeNpWcn8ipdGR7atZ1uBbJg0J4HoUKcW34JoerxIW/i7xl8U8h8Rnz/u4aWwvV7ilGCbJ0XLAn3B@gnusha.org X-Gm-Message-State: AOJu0YxWuoE+fl/m+ZYT3o3xAg7u32G3tySpTUYbJa20KQEON83Yxu2B fvVJiwekyuqSyJBvkZMBYjY1hQZ0KPWDhQY1HTYtwbMPbVpWTrTMe8Gc X-Received: by 2002:a4a:e847:0:b0:662:ca7c:b0e6 with SMTP id 006d021491bc7-662e0478bc9mr1823892eaf.58.1769431076490; Mon, 26 Jan 2026 04:37:56 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HoQmbMuKepn6RlZrnxy+f7UR9jskrZpUyaJa2g9xZQYQ==" Received: by 2002:a05:6870:331e:b0:3d4:d703:74d7 with SMTP id 586e51a60fabf-408820243b7ls1723034fac.0.-pod-prod-02-us; Mon, 26 Jan 2026 04:37:51 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUT+J6D8KD1cfT3/0QrAdqygrgu1zAKvhIlvmf8m1AJq3QBzT7wpATprJInDf7x1CRLlSKTaFp1y21i@googlegroups.com X-Received: by 2002:a05:6808:bd6:b0:44f:eb07:5042 with SMTP id 5614622812f47-45ed9a0ab24mr1618475b6e.44.1769431071556; Mon, 26 Jan 2026 04:37:51 -0800 (PST) Received: by 2002:ab3:738e:0:b0:2d1:a602:e60f with SMTP id a1c4a302cd1d6-2dcc7d77826msc7a; Mon, 26 Jan 2026 02:34:02 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWj/ITpQhLguNVzwpHDUGx61Mkuiw+Mks4cZB5kCOEkTSQCidJ56HP7F3/tenxmt+D0aohVI5zv429b@googlegroups.com X-Received: by 2002:a05:6512:304f:b0:59d:de87:3352 with SMTP id 2adb3069b0e04-59df3a736d0mr1059962e87.35.1769423640160; Mon, 26 Jan 2026 02:34:00 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1769423640; cv=pass; d=google.com; s=arc-20240605; b=dKO29TdTwbwIgyGTb3E7aBsIjxJNEG11jx6/C4TMD2h/T0E+bdRGTqMn3ADcpXd2cW b517Vn4bb0QdK3R6csjOC6K30ZJlPC5PsJZakBR3QGEBcmTlrW++W+90x3sQZ6l/gKiP retHd9zOcKtOmzLysllV1Wo5eka3Y+Z5uWRkGf68RkMlAz551vEW+jyGDtXhEIumXilU GGqayq6M7YMOuQRsmKC0AJQAKGmo4J4KDwd0+gFBGQl7hBWzvKJxJNW744FAwmCCAAFq WZLQhPmASaG7DThNOvc6JICTxUtlDNHY+LXFQ/JfyfNrEMj2V5iTOZijVzZgBtsgq3kx a8DA== 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=HuV8jg0IOEbzcQnpp1xvb0NxHjv0pjlwJEVQf01rVsE=; fh=eolwsgWeueVcGIfTHkjJWWG1JQKLVeXgxZsyhEaEAWE=; b=DkypZbaU53vYYYRCcwOmgh2VQDdwrKqAhcOZqtSJLbmJpP2J5aEnryKgt10vUQ6YI2 VFcS+xkFYMjvvqNoVdvsBCOJrHS/OIZz3fibwqhciUTzntSvNUJ6BtKw/JkV2OUL3vWh y+0qwan6FxjGqsZ060LjslA676hNEKTzR34IOZaKxSfFESUjr+vHPkjbd9Tvz4vWnmxK ZTflJBPiQXmnaqFrieAAx1xlc+rixcs2Sa96AY5p+z/SGNQdIES2xNxKL1+ESePwdb6t R0SGSihdJhcq5dpqPYCJiS4kJ8jij+5/10u0Lp2kr/6QIR5FOIWchVnPLH2aXhT7P7iq wu4g==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=JtDTQRNi; 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 2adb3069b0e04-59de4913c99si190963e87.8.2026.01.26.02.34.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 02:34:00 -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-59b6eb4aca0so578591e87.2 for ; Mon, 26 Jan 2026 02:34:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769423640; cv=none; d=google.com; s=arc-20240605; b=S+jDlr2s72ryhExuW5AqhrsuITF3pnkDijqX66TH0CpTLibvFmYm1FUBj6zvOnyibP gDsAumo+vN8Yqp0wZPBulDxfkqgsNTy3D2UPJUo3InMTfhilyFxlPGVwXg425W79xwyV 9Mfu9ranX4mjSTOR+xnE9m3uPW7x3O7ldRtpw2kexvylMdsjCss2MBWgAMHEFExBU3vI tfuxwzvcNBuz1RPBEsM9GVQfGu5HRhyejiF1d6LeclYRKuyHsfwccEjJGDeLnJAau5NT 2UGvzZXtNlq91LpTEIRaJjVc2oMUcKigiguMrk7QQ2JB+UV9F6tqwVGF1rHKWh01rNLB Yryw== 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=HuV8jg0IOEbzcQnpp1xvb0NxHjv0pjlwJEVQf01rVsE=; fh=eolwsgWeueVcGIfTHkjJWWG1JQKLVeXgxZsyhEaEAWE=; b=Ao4cpNqryVpdmqLjJrQ4GVJYmF7aDJyaSiZj0eo2YMkkWDgH3Jz5x5iZvCSqpekeXR aB/l82IrWRRafm+Bzs5FokdYqrmZNU7QP5txfN4O7z37HvlAaiBBuTGi0vtZ+U2c24B0 isEFnMykfahsqWmTy53YNoeX+IKSTetwks4yQ565so9ML26bPfJ+0ojXthyAFcCaGBU5 awHZcTCaq+mVXV5eJHMg/DF2uBtHYrFPVqyG4bVWBZHLhL8t7IzTWUk8KbTLIh+FPGKo d72fE6o3ac/cksMFL8+LkLiuRygqrEzZw8qq3q/0FZKRMMdC4uxtccedzurjZyDSJLDS 7yLA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCUI9pSyns7O0+BRZFFodiLNpSpHlbd8taeUW9ywRA4b/yxkA0VZEYVsNUggnns1/KQUfsFBrEqmxmyi@googlegroups.com X-Gm-Gg: AZuq6aLRvoR+q/6ePnJQnEAdnXD8ac7SRkO5GCPPGxM8MFClFBt4yWdnvlT0dCHoerW 7pKpS0HP4DuSA3+Zd8TmSW+aW3Wvdz69b392VZpeulL+V7upFsQlFthBwp71YPBBG8QIURUUmEK x3ET4vKZsuU1uNUg8E9uA3n8OZBPfrW8sfyCI7aiXCWXVT7qILCZ1agGbuP7KJg5cv5kW3jOUWQ BnMNrXt6uMIpcNIfE00eujbaCUdWf/yglYmfwcNzp3qwg/A9TNuJoQzbJFXgIfs3k8+TlYK X-Received: by 2002:a05:651c:4213:b0:383:1a86:ad09 with SMTP id 38308e7fff4ca-385fa1c2e42mr7805241fa.8.1769423639418; Mon, 26 Jan 2026 02:33:59 -0800 (PST) MIME-Version: 1.0 References: <16e01530-e9dd-481f-8c7f-ca9ccafcfcden@googlegroups.com> <2e4abb5a847ab9d78857aee2fded500a234f68a6.camel@gmail.com> <46faf0c0-d60d-49a4-83c5-8fe03f11c89dn@googlegroups.com> In-Reply-To: From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" Date: Mon, 26 Jan 2026 11:33:48 +0100 X-Gm-Features: AZwV_QiiCzx6BlMmW9P6S4rk1WBPaG-bsuiDwbCtk9dvJfsPeThKYpzNzhTyhnI Message-ID: Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal To: cassio gusson Cc: "waxwing/ AdamISZ" , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000007c26900649480b5f" 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=JtDTQRNi; 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 (-) --0000000000007c26900649480b5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The investigation of Lattice-Based approaches is on the table, so I think we will be able to make a thoughtful comparison at some point. I support the idea that SNARK/STARK-friendliness can not be a crucial point, as it is not currently supported, but can be an argument for tie-breaking cases. All pairing-based schemes are broken by a quantum computer, yes. STARKs are plausibly post-quantum. There are some schemes based on Lattices as well. The QKD problems are not important for our discussion; they do not affect PQ transition. Best, Mike On Sun, Jan 25, 2026 at 11:44=E2=80=AFPM cassio gusson wrote: > hey guys > > I don't know if this is important for the implementation being discussed, > but I think the study that identified a flaw in quantum key distribution > (QKD) is worthwhile. > > https://ieeexplore.ieee.org/document/11223709 > > Best regards > C=C3=A1ssio Gusson > > Em s=C3=A1b., 24 de jan. de 2026 =C3=A0s 17:12, waxwing/ AdamISZ > escreveu: > >> Hi Mike, >> >> > 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 i= ts >> own. What would you say? >> >> Does it depend on what we really mean by SNARK, apart from the literal >> definition? >> What SNARK schemes are we thinking of that are post quantum? I presume I >> can say "all the pairings based SNARKs (and the DLOG based ones) are not >> quantum resistant". Are STARKs the only realistic option in this scenari= o? >> I am enormously ignorant about STARKs, but I do seem to recall that they >> have large proofs, so at least in theory that's a problem for such plann= ing? >> >> Or maybe there's another PQ SNARK scheme that I'm just unaware of. >> >> I guess this is orthogonal to the point you're raising about >> arithmetic-circuit friendly hash functions like Poseidon, though. That p= art >> I find a bit brain-melting because: what mechanism is assumed to exist t= o >> translate a STARK or SNARK proof into an onchain effect? If there was sa= y a >> STARK op-code then, job done. You'd just somehow have to have sufficient= ly >> small STARK proofs which is AIUI not trivial, even with nice hash >> functions. If not, we're back to the current hyper-sophisticated scenari= os >> of things like Glock and BABE where you use garbled circuits, witness >> encryption, and also need something like the adaptor primitive of "swap >> signature for secret" which we currently get kind of "for free" in Schno= rr >> with the linearity. I suppose there might be alternatives (e.g. HTLC >> instead of PTLC) that might be more clunky, but viable. And all of that = is >> of course "fraud proof" style, with "slashing", and not anywhere near as >> clean a design as "just verify the STARK". >> >> How does one take the 10000ft view on this needed to make a design >> decision? Obviously I don't know, at all, just raising points here. I gu= ess >> the most interesting one is: "is STARK realistically the only game in to= wn >> here?". >> >> Cheers, >> AdamISZ/waxwing >> On Friday, January 23, 2026 at 1:34:36=E2=80=AFPM UTC-3 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, one option is to use SPHINCS+ as a fallbac= k >>> 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 kee= p 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 consider= ing >>> adoption. >>> >>> Best, >>> Mike >>> >>> 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 har= d to >>>> implement quickly and in constant time (securely). >>>> >>>> This is true for the first Falcon version published (randomized mode o= f >>>> operation). This implementation uses the author-recommended determinis= tic >>>> 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-frie= ndly >>>> and overcomes portability limitation. While this sacrifices the perfor= mance >>>> 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 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 degrada= tion >>>> 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 har= d 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. >>>> >>>> >>>> https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-point= s-falcons-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 i= t >>>> 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 >>>> mathematical tricks. However, much like Falcon, it is still immature a= nd >>>> needs more researchers to optimize its verification, explore its stren= gths, >>>> 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 parameters. The catch is a >>>> dependence on statefulness. >>>> >>>> regards, >>>> conduition >>>> On Wednesday, January 21st, 2026 at 11:09 PM, Giulio Golinelli < >>>> golinelli...@gmail.com> wrote: >>>> >>>> Hi everyone, >>>> >>>> I am to share a technical demonstration and benchmarking project that >>>> integrates the Falcon post-quantum signature scheme (Falcon-512) into >>>> Bitcoin Core, implemented as a soft-fork within the classic P2WPKH mod= e. >>>> 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 scheme >>>> designed to be secure against quantum attacks. Unlike other PQC candid= ates >>>> such as SPHINCS+ and ML-DSA, Falcon offers significantly smaller signa= ture >>>> and public key sizes, as well as efficient signing and verification ti= mes. >>>> 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), w= hile >>>> 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 p= romising >>>> performance, highlighting its advantages over currently selected >>>> post-quantum signature algorithms such as SPHINCS+ and ML-DSA, which f= ace >>>> significant time and space limitations. As Falcon approaches FIPS >>>> standardization, this work aims to provide a reference for future adop= tion >>>> and integration in Bitcoin. >>>> >>>> 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 o= ther >>>> spending paths. I also look forward to development/integration correct= ions. >>>> >>>> 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+...@googlegroups.com. >>>> >>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/2e4abb5a847ab9d78857aee2f= ded500a234f68a6.camel%40gmail.com >>>> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe= 03f11c89dn%40googlegroups.com >> >> . >> > > > -- > > -- > --- > Abra=C3=A7os > C=C3=A1ssio Gusson > > -- > 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/CAEQmO3h7Ao4mu2xfC2qE%2B4Ecx= hES-VBEG2s2LRN6msWELh19NA%40mail.gmail.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/= CAPcK4uSUP4Yzb3-bAkPGjSf8iUFA-_%3Dq%2BHSRTLd51GZw%2Bsj5Aw%40mail.gmail.com. --0000000000007c26900649480b5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The investigation of Lattice-Based approaches is on the ta= ble, so I think we will be able to make a thoughtful comparison at some poi= nt. I support the idea that SNARK/STARK-friendliness can not be a crucial p= oint, as it is not currently supported, but can be an argument=C2=A0for tie= -breaking cases.=C2=A0=C2=A0

All pairing-based schemes are broken by= a quantum computer, yes. STARKs are plausibly post-quantum. There are some= schemes based on Lattices as well.=C2=A0

The QKD problems are not i= mportant for our discussion; they do not affect PQ transition.

Best,=
Mike=C2=A0

On Sun, Jan 25, 2026 at 11:44=E2=80=AFP= M cassio gusson <cassio.gusso= n@gmail.com> wrote:
hey guys

I don't know if this is imp= ortant for the implementation being discussed, but I think the study that i= dentified a flaw in quantum key distribution (QKD) is worthwhile.

h= ttps://ieeexplore.ieee.org/document/11223709

Best regards
C= =C3=A1ssio Gusson

Em s=C3=A1b., 24 de jan. de 2026 =C3=A0s 17:12, waxwing/ A= damISZ <ekaggata= @gmail.com> escreveu:
Hi Mike,

> It is also a quest= ion: how much weight should we put on adopting an=20 explicitly SNARK-friendly signature scheme? While such compatibility is=20 clearly advantageous, it does not seem to me to be=C2=A0a decisive point on= =20 its own. What would you say?

Does it depend on wha= t we really mean by SNARK, apart from the literal definition?
Wha= t SNARK schemes are we thinking of that are post quantum? I presume I can s= ay "all the pairings based SNARKs (and the DLOG based ones) are not qu= antum resistant". Are STARKs the only realistic option in this scenari= o? I am enormously ignorant about STARKs, but I do seem to recall that they= have large proofs, so at least in theory that's a problem for such pla= nning?

Or maybe there's another PQ SNARK schem= e that I'm just unaware of.

I guess this is or= thogonal to the point you're raising about arithmetic-circuit friendly = hash functions like Poseidon, though. That part I find a bit brain-melting = because: what mechanism is assumed to exist to translate a STARK or SNARK p= roof into an onchain effect? If there was say a STARK op-code then, job don= e. You'd just somehow have to have sufficiently small STARK proofs whic= h is AIUI not trivial, even with nice hash functions. If not, we're bac= k to the current hyper-sophisticated scenarios of things like Glock and BAB= E where you use garbled circuits, witness encryption, and also need somethi= ng like the adaptor primitive of "swap signature for secret" whic= h we currently get kind of "for free" in Schnorr with the lineari= ty. I suppose there might be alternatives (e.g. HTLC instead of PTLC) that = might be more clunky, but viable. And all of that is of course "fraud = proof" style, with "slashing", and not anywhere near as clea= n a design as "just verify the STARK".

H= ow does one take the 10000ft view on this needed to make a design decision?= Obviously I don't know, at all, just raising points here. I guess the = most interesting one is: "is STARK realistically the only game in town= here?".

Cheers,
AdamISZ/waxwing
On Fri= day, January 23, 2026 at 1:34:36=E2=80=AFPM UTC-3 Mikhail Kudinov wrote:
<= div dir=3D"ltr">Hi everyone,
I am happy that the discussion on the PQ to= pic is active. I wanted to add my view on the raised issues.=C2=A0

F= or the=C2=A0fallback in SHRINCS, one option is to use SPHINCS+ as a fallbac= k with a limited number of signatures. By setting an upper bound as large a= s 2^30 or 2^40, the signature size can be significantly reduced, and the sc= heme would only be invoked in exceptional circumstances. In most realistic = scenarios, the fallback would consist of generating a single signature to m= ove 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=C2=A0more e= fficient.

It is also a question: how much weight should we put on ad= opting an explicitly SNARK-friendly signature scheme? While such compatibil= ity is clearly advantageous, it does not seem to me to be=C2=A0a decisive p= oint on its own. What would you say?
I am also unsure to what extent Fal= con can be considered SNARK-friendly. Has there been any research in this d= irection, or are there benchmarks evaluating its performance in SNARK envir= onments?

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

Best,
Mike

On Fri, Jan 23, 2026 at 3:03=E2=80=AFPM Giuli= o Golinelli <golinelli...@gmail.com> wrote:
Falcon (FN= -DSA) relies on discrete gaussian sampling using constant-time floating poi= nt arithmetic for signers, which is very hard to implement quickly and in c= onstant time (securely).
This is true for the first Falcon version published= (randomized mode of operation). This implementation uses the author-recomm= ended deterministic Falcon mode (see=C2=A0a= uthor=E2=80=99s notes)=C2=A0which uses software floating-point emulatio= n . This eliminates side-channel risks associated with non-constant-time ha= rdware 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 activi= ty.

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

If you want a PQC scheme that's ready=C2= =A0today=C2=A0and also provides small signatures, I'll po= int you to XMSS, and=C2=A0Jonas Nick's SHRINCS proposal. You can configure an unbala= nced 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 ov= erhead (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-thr= oughput L2 environments, state management, limits on the number of signatur= es and performance degradation proportional to published signatures are cri= tical bottlenecks.

On T= hu, 2026-01-22 at 14:35 +0000, conduition wrote:
Falcon (FN-DSA) relies on discrete gaussian samp= ling using constant-time floating point arithmetic for signers, which is ve= ry hard to implement quickly and in constant time (securely). Despite being= significantly harder to implement than ML-DSA, it only provides a mild (fa= ctor of two or so) improvement in signature + pubkey size. This is why we&#= 39;re probably not including FN-DSA in our PQ signature opcode BIP followin= g 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<= /a>, which uses isogeny-based cryptography to produce very small sigs (148b= ) and pubkeys (65b) using some convoluted mathematical tricks. However, muc= h like Falcon, it is still immature and needs more researchers to optimize = its verification, explore its strengths, and attack its weaknesses.=C2=A0

If you want a PQC scheme that's ready toda= y=C2=A0and also provides small signatures, I'll point you to XMSS, = and Jonas Nick's SHRINCS p= roposal. You can configure an unbalanced XMSS tree to get 272 byte sign= atures, potentially smaller if you crank up the parameters. The catch is a = dependence on statefulness.=C2=A0

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

Hi everyone,

I am to share a technical demonstration and = benchmarking project that integrates the Falcon post-quantum signature sche= me (Falcon-512) into Bitcoin Core, implemented as a soft-fork within the cl= assic P2WPKH mode. This work aims to provide a practical reference for poss= ible future Falcon adoption, especially as it approaches FIPS standardizati= on.
You can find details at thi= s fork.
Why = Falcon?
Fa= lcon is a lattice-based, post-quantum digital signature scheme designed to = be secure against quantum attacks. Unlike other PQC candidates such as SPHI= NCS+ and ML-DSA, Falcon offers significantly smaller signature and public k= ey sizes, as well as efficient signing and verification times. It is implem= ented in pure C and does not require external dependencies.

Bench= marking & Results
Aspect Falcon ECD= SA
Public Key Size (B) 897 = 33
Signature Size (B) 655 71
Verification= Time (=CE=BCs) 57 120

Verification time is m= ore critical than signature creation time in Bitcoin, since signature creat= ion is performed by clients (wallets), while nodes focus on verification.

Integration
  • Falcon was include= d 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 scr= ipt verification flag.
Next Steps & Reference
This project serves= as a practical demonstration of Falcon=E2=80=99s promising performance, hi= ghlighting its advantages over currently selected post-quantum signature al= gorithms 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.

= 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 spend= ing paths. I also look forward to development/integration corrections.
<= br>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+...@googlegroups.com.
<= /blockquote>

--
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.googl= e.com/d/msgid/bitcoindev/46faf0c0-d60d-49a4-83c5-8fe03f11c89dn%40googlegrou= ps.com.


--

--
---
Abra=C3=A7os
C=C3=A1ssio Gusson

--
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.google.com/d/msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG= 2s2LRN6msWELh19NA%40mail.gmail.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.co= m/d/msgid/bitcoindev/CAPcK4uSUP4Yzb3-bAkPGjSf8iUFA-_%3Dq%2BHSRTLd51GZw%2Bsj= 5Aw%40mail.gmail.com.
--0000000000007c26900649480b5f--