From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 25 Jan 2026 14:45:07 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vk8qw-000257-7O for bitcoindev@gnusha.org; Sun, 25 Jan 2026 14:45:07 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-3ff59bab16asf11946064fac.3 for ; Sun, 25 Jan 2026 14:45:05 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1769381100; cv=pass; d=google.com; s=arc-20240605; b=Xufo6hX2Q+jR5Zckzrf2UQo3hXvHECmy2/2sL4Fce+R0H4A95YcsBBBeipv/iCWEzM QC/zOfnUoWunbya3a3OgCOZzpOTpdz6DtrNL0X/VWkFkcWWoz7KICjgHNGBMPIAbmTWc sUNz5QIG2sSfE/udUNJDcaWjw/g21aPEld+e/Nl1rj76Z52b7ftTKhV4knBSTHI+QlYW +xIeKBsLzToc44djHysWmNF+1f47o3xGYzh1XxLwQCcse1u31DXBbj4ZybQzTMP4Hkj3 S2J8eH4Q6M50opziZb+yfleHZvWe0VEMq3PpDpNGksO6vZ3T5kDwQ0hHEOrXROgTQxeI h+hA== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=8OMrfw10iVj1aAJsd4CoH63keKokLS5RYH+ay9j72Bo=; fh=H7nUL7TDEgePkt530WgXwHAc77iFd8Fn23lS6os4MI4=; b=NBGU812ZxTIC3Wgy95jHcO8u/3WFRdRLTl60G4ik+qQQ5l2flf5SiorwiTplY/+ckZ /WLcMxAtxeh29FFXc78vpm+q8BV8pa5wWqptpdHBZmZuAg5NK8Fr+BWd/crqU+F4UwLc uJniYDg0AvpneYVe5c8zqMvws064p9UinnO4eTJ9wP78Nb0OdGBI28UGTmUh5ygl+hHU BSNjz3wU7HUen5lgRdZf1DsfizdrecZsPn9P9vZmK7rk5GUUMSfxDTy+F1CY9qK8MpM2 N11nsjD+UcCS3Jmcla/1hl36y2tqmYcd4WRpdparaL5H4Iw2scPzK1xFQB+fGsizDNUN HpUQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YWpKuMx7; arc=pass (i=1); spf=pass (google.com: domain of cassio.jv@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=cassio.jv@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=1769381100; x=1769985900; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=8OMrfw10iVj1aAJsd4CoH63keKokLS5RYH+ay9j72Bo=; b=PuZoieaVoZMx+MURbk9lQt4DNy5uS4Kb1KaRML38YnqJMiSJUNqDsmLl8XcCzjXTeQ KrW2Fwh3rmS3aq/tuvzLCO5QgaWtLF/W+7HJLXEuVyBMVOwDUG2GVTNwUVil96pdvIg2 dmxq/GdWLmiPqoKHW8qeR+NQhWERTErXQWjACc1Uc99DMXWip+iNz2a3t7Uc9LUxjVj9 BtrwjUNJoYrXkJ3MSKRE0QwrduF++c75pmj2N89Zq9UT3R5lxrGeXC4VN9JRsTBjqoNS fq3mu8F3/tjkMzNHkx+OqlzFzFJFu9L1IR/gUZKVUl5FHYyLUYoezl6yKHear57XaUkW s93A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769381100; x=1769985900; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8OMrfw10iVj1aAJsd4CoH63keKokLS5RYH+ay9j72Bo=; b=AbogQtuTXZe60OENkBgCQcVpMlGjzKMsbKamSFW9vtk8iECdxkcqZRHXskhNf7tc6h sGbyzqGZqORDy4aNyo9L4O3XDvPzOhjkiapq/ot1jn86QOR5GmTn43mxK+1auBJh9qPJ h6bgzwG2U8k+R8sbq1LApgyimq4mRP/hs/Y8t6KdWbwkoVuoO7awzbNt0x9GAPFFTon4 Xk0XTRu+eFWK7gpMHlVfxqGid6S1MK8McIMdes1DdlQZFvia3Mm6Ve/gngji4CZUdJsA 5VzjDKaNyw+qcj48D9p2wPlgxFT8btqjJuSKAez+TmbvvrNDWDAZ1dwzno4YtPPjbUVp daKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769381100; x=1769985900; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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 :sender:from:to:cc:subject:date:message-id:reply-to; bh=8OMrfw10iVj1aAJsd4CoH63keKokLS5RYH+ay9j72Bo=; b=ROJGoA++qy7IJgiRb3TgEVm6KvGNfWzsVZT/GdVZG7rWs9cnJqZHg/iBbnDQzUzzg/ pKRr4kf95SLGZtBwOwurQ1QoHexwanEKQCiPMLW++DO2im3elzGKryFWSJ9D7K5juYha oMSSqsPw+iFpwVyJ+NsWBgpdWGzubNVTvFCj8YkuHQnPVuoPffD2ILrhd5MdDZWFTKHm Eou6H6M9RG3Bg7FifabcaU14TI9QRyuJ7bsfTidnoDjyfy9MRireNSkX2u7KdOb7BYyi 5PJSRbYIg0px3nfNsG2WmET/0m+i3Q9SErLT9Gs1Kr+ek2HvzzyTDMDlY2qayl7AyqIk ld8A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCV87V0gpSZyoY5Dd6LMgJFYLdxC7g3R/17UichRrMKN1GXTnYeXeRyjY6/I6UUp8z1qn2q3cQjlI05+@gnusha.org X-Gm-Message-State: AOJu0Yx0i+EyF4tBsqZXMBNNT7cNzv9Quh84iOjyTQZ1Iy7Qkj8XZ8Nv VOK8BiXHSTOAWqpoMhzK0G4NC6c/IdMCy2RrmVUWWtJudLM0gkyEdCyd X-Received: by 2002:a05:6870:a78e:b0:3fd:ec4f:d1d2 with SMTP id 586e51a60fabf-408f7f2a286mr1373676fac.10.1769381099110; Sun, 25 Jan 2026 14:44:59 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GVvFjdAchI+xczFgJvdzygXI8VOWDDfrMoHqLHl8m2xQ==" Received: by 2002:a05:6870:21cb:b0:3ff:9e43:57c5 with SMTP id 586e51a60fabf-408825778a8ls2248002fac.1.-pod-prod-01-us; Sun, 25 Jan 2026 14:44:54 -0800 (PST) X-Received: by 2002:a05:6808:13d6:b0:450:b64e:9c14 with SMTP id 5614622812f47-45ed95748d2mr1443970b6e.5.1769381094625; Sun, 25 Jan 2026 14:44:54 -0800 (PST) Received: by 2002:a05:6402:20c4:10b0:64b:3e1b:1324 with SMTP id 4fb4d7f45d1cf-6584e84a4cdmsa12; Sun, 25 Jan 2026 13:54:27 -0800 (PST) X-Received: by 2002:a17:906:c141:b0:b88:8782:fead with SMTP id a640c23a62f3a-b8d2e83fe19mr200595066b.47.1769378065134; Sun, 25 Jan 2026 13:54:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1769378065; cv=pass; d=google.com; s=arc-20240605; b=NGNcHvpwojCXpsCxXx04yLJcb6cC8tYQh5AfaJBRzD7DBktljwIDZ6ojKr8RFPu48W /1fAExJGDltQa/CqOTo/MpXSvrc/SRC8LB0+B+M46X6IwrX8ClIkQ8IGiiecaUJm539t Wh+EATHUHPExUGiGRvSz1I4YtB/1GtYYt0TRV67K/y0RIkebkHv7JZWUadrJYRh65lmY 2sF6b84udQUyvXRR+GVszd4T6KHhBKdGrpdBZuhIx2t6vVdfvAGDbF+vaEKRQep/NYFe TBsBLqGlABDm6mGaSv2Pq0OVLjzOo+T+s/UUFzlfB32gbiTsY35KcCFZXzZHde159Pa5 9v3A== 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=FUTRZhLFXeMuHaWabQOZCUPikF2Ci1D6/luaW+wKs5o=; fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=; b=QNOmhWgH7hlUkVXk9LVc9kN8IRa1ZY//B3bbdRAr3dm1CMd00sVmYULlYMOJuoD4M+ vVpNFbxOWYa+QIvB/YSk1/DODFyfplKWVNJhcqceKQsXW9AWSBfkuERr2z3T3jauHFXL 1m3cXjQajhtmcqznvQN6jIFX+a79jvv/sCW7RH+6Swj+PIbyDiDJXP6rzIxJLLC7scf3 Mx1RraNbUsY/fj54n9GtjWDhCEyTT21ak0MWlzJi3WPSUB6gXkQGmUgNYu2rWjEVhiIe 8+IgtuziR+JxUasZaC+a7bu4aAZyoR0F7K7oKuZ1HPBlKry92JgvRGSbA4Zycifu+sWT SClQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YWpKuMx7; arc=pass (i=1); spf=pass (google.com: domain of cassio.jv@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=cassio.jv@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com. [2a00:1450:4864:20::62f]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-b885b67f781si18774066b.2.2026.01.25.13.54.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Jan 2026 13:54:25 -0800 (PST) Received-SPF: pass (google.com: domain of cassio.jv@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) client-ip=2a00:1450:4864:20::62f; Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-b8845cb5862so580494166b.3 for ; Sun, 25 Jan 2026 13:54:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769378065; cv=none; d=google.com; s=arc-20240605; b=FhTqWvjoKoCNadX1xHd3BgKRothU8EhtcoL3V+zN2GHxQoWsm5WMqDeLctIoVUwLPA 0iEpMYfnWVtRwM6o50rKQKlX/8d7mRid3OmqFa8HHYRuJWlPI2xKlCYUhmjHszffMnvk kqbnKAKLP7weFVzLJWGGPyxqOCHBkFhvVlHiqlquSaZ+tGKr06xu/mq3DLmbpmp8ga5M OieXR0QOUT4aMW1eSCAW9TqWS72wiJ483UHOAl4mMscqPiwtldStSNIMHXRRMQmdUCd1 KVvHn4RZB4Z665jm038nmAiAqLcygJ+pRKlhtY8XAw/dfKrHgE8yaRQKWnozcK6N8CVX ypMQ== 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=FUTRZhLFXeMuHaWabQOZCUPikF2Ci1D6/luaW+wKs5o=; fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=; b=MTugRJaDo7YJjHyCxsHfGNSK6q5F+RfoMJ0Gt0hf5VLnhaFcvfMECdSCy3r71gE50J ZLeyHDEl05cbmZ0+Kl5czMiwMQTwj/pPGw7rKOzIkVuok1UjFMYhz9OKBQ/yzg6rUC4v Jyr/eCYjFnlY+LxFAgUkD0OMRLK0FjrUbUfGstA8r+RWZzPICB3UeTbK9lymOvxd+uPY p5GcnsuzxdmkfnnDmas5u1HKIyuqMTM3qohPEF6SAJMrbmWZ3EIahxqR0UZVNqDdrxJc pNWzpDvuvEwR23AP0vCtVmguMPPELTkJwoqt5aqY09CAT8cLU/bNP7TX1j3CiJZrTl9g E8Xw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aL0ugYXiptO08NbbYTTcVWhI5F8PrHpL9VbZaGvGeaESvgXt/KIVpSeoxAxJ96 34VF+7RUDOMW6WUcE/aqEjdDQQjwyRh5cZ43h9UUhzsFtZe2XiZXa9dFrUXcBdh3zjrxUUn25W7 UVM8rr1/HxFt/z4hQ0atHb7toQJk5D2wDEfSRwaafyg+WoBfJ2ejdYec+QXv9uo7haTjtD6fiBZ o/20gHhmsGVt513BnPy6acQNHnY/ssUpfhuSl5K3x31P69yYZGCpsPDQwiesjPdQ2pe4HeR X-Received: by 2002:a17:907:6d16:b0:b87:2abc:4a32 with SMTP id a640c23a62f3a-b8d20d7e8e4mr208750866b.18.1769378064170; Sun, 25 Jan 2026 13:54:24 -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: <46faf0c0-d60d-49a4-83c5-8fe03f11c89dn@googlegroups.com> From: cassio gusson Date: Sun, 25 Jan 2026 18:54:12 -0300 X-Gm-Features: AZwV_QhRlL0K5CCrjYM0Suv-qN7cO6Kh6BFyZAg-ig0NEdxAX-zWuW7_zVLAN2U Message-ID: Subject: Re: [bitcoindev] Falcon Post-Quantum Signature Scheme Proposal To: "waxwing/ AdamISZ" Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000fd04d806493d6ebf" X-Original-Sender: cassio.gusson@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=YWpKuMx7; arc=pass (i=1); spf=pass (google.com: domain of cassio.jv@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=cassio.jv@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 (/) --000000000000fd04d806493d6ebf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 it= s > 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 scenario= ? > 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 planni= ng? > > 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 pa= rt > I find a bit brain-melting because: what mechanism is assumed to exist to > translate a STARK or SNARK proof into an onchain effect? If there was say= a > STARK op-code then, job done. You'd just somehow have to have sufficientl= y > small STARK proofs which is AIUI not trivial, even with nice hash > functions. If not, we're back to the current hyper-sophisticated scenario= s > 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 Schnor= r > 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 i= s > 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 gue= ss > the most interesting one is: "is STARK realistically the only game in tow= n > here?". > > Cheers, > AdamISZ/waxwing > On Friday, January 23, 2026 at 1:34:36=E2=80=AFPM UTC-3 Mikhail Kudinov w= rote: > >> Hi everyone, >> I am happy that the discussion on the PQ topic is active. I wanted to ad= d >> 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 i= ts >> 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 consideri= ng >> 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-tim= e >>> 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 determinist= ic >>> Falcon mode (see author=E2=80=99s notes >>> ) which >>> uses software floating-point emulation . This eliminates side-channel r= isks >>> associated with non-constant-time hardware FPUs. It is also SNARK-frien= dly >>> and overcomes portability limitation. While this sacrifices the perform= ance >>> optimizations of true FPUs, signing speed is not critical in Bitcoin, w= here >>> 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 degradat= ion >>> 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-tim= e >>> floating point arithmetic for signers, which is very hard to implement >>> quickly and in constant time (securely). Despite being significantly ha= rder >>> 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= -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 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 >>> mathematical tricks. However, much like Falcon, it is still immature an= d >>> needs more researchers to optimize its verification, explore its streng= ths, >>> 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 mode= . >>> This work aims to provide a practical reference for possible future Fal= con >>> 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 candida= tes >>> such as SPHINCS+ and ML-DSA, Falcon offers significantly smaller signat= ure >>> and public key sizes, as well as efficient signing and verification tim= es. >>> 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), wh= ile >>> 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 pr= omising >>> performance, highlighting its advantages over currently selected >>> post-quantum signature algorithms such as SPHINCS+ and ML-DSA, which fa= ce >>> significant time and space limitations. As Falcon approaches FIPS >>> standardization, this work aims to provide a reference for future adopt= ion >>> 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 ot= her >>> spending paths. I also look forward to development/integration correcti= ons. >>> >>> 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/2e4abb5a847ab9d78857aee2fd= ed500a234f68a6.camel%40gmail.com >>> >>> . >>> >> -- > 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/46faf0c0-d60d-49a4-83c5-8fe0= 3f11c89dn%40googlegroups.com > > . > --=20 --=20 --- Abra=C3=A7os C=C3=A1ssio Gusson --=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/= CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40mail.gmail.com. --000000000000fd04d806493d6ebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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/do= cument/11223709

Best regards
C=C3=A1ssio Gusson

Em s=C3=A1b., 24 de jan. de 2026 =C3=A0s 17:12, waxwing/ AdamISZ &l= t;ekaggata@gmail.com> escreveu= :
Hi Mike,<= /div>

> It is also a question: 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CAEQmO3h7Ao4mu2xfC2qE%2B4EcxhES-VBEG2s2LRN6msWELh19NA%40ma= il.gmail.com.
--000000000000fd04d806493d6ebf--