From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 27 Feb 2026 08:39:45 -0800 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vw0sS-0007My-Pw for bitcoindev@gnusha.org; Fri, 27 Feb 2026 08:39:45 -0800 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-679c5ed0942sf34424370eaf.1 for ; Fri, 27 Feb 2026 08:39:44 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1772210378; cv=pass; d=google.com; s=arc-20240605; b=LSy0FKbfBUZOQ2z40fVgP2+keLKOcuKyTa8lhAojCZP1xahOwSOXVoFuSVmgu8KdrW CiH35L9e3qr7LMq71Sf5kYbtzavaFgbGTrUBVjQckpLWWvn2tWSJmpG1yGH/izdzXgaC mutQYyK96Rpj4h5Lwb45eqAwDWRaszyaMyIAPo/vtKpHhYH9Ccdt1GGyUdBAl1cEVI+C GH6YC9WFBzlNpOMhtUSVqFrD7/Vw7ZZLdqt0oYuLdqJcvlkOh/So61Whda5ytg6go7yC Ak+1xrykmFMlrdh7rZ5v5LYV1zLEyQedQt28qgUSbtczZgF0Y2c2TOcxYSgn5iTWLxR5 ET9g== 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=wOopsDGgUiNotjq0Ge/g/xxO6M16rMuosOrkMYpkHIc=; fh=mXyVaYxoQXqBKbEPInXWe0STzep3zpQXvEFXBMGOZ8k=; b=QFUcoLRLWjfUujPhtbpH2zuwylXZX6bJ2ZHsapssMLoeML8fRpuBfmZxZpLz00HOK0 6f15ZmkNtbTzjJObGM8fNcUSjamuIK2yPtcj7xjWTb7ewHZIXH7H2DFPw8T8j03ldbo4 olwlPiyWf2zpu+Mw6/AVk+Q3yCz+S2zcVkSdOHPAnTji8b5kKnWMtXOrSzE566luwoxp HXqwEWL58T1t9VFzJYBUkEklSUTDWiHUGu8RoJWstqwm4WTKBui94iLMTHcOGldjx1Ti CCpm2SrOR/OUywyjcu3hKrtlYynJGTuhNIv0JGSjz1d8O6LgJw2nttw1wf89FbVvrVZJ k5CQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=m1VUPr4T; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::229 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=1772210378; x=1772815178; 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=wOopsDGgUiNotjq0Ge/g/xxO6M16rMuosOrkMYpkHIc=; b=rcGXImBmFQwWXE3yiMf1+6jGloKNw76k6sPeMFzwHpTAx/TVwdzCHddtTgtgYHV5Ml FAi942Z8TUh9vXe4eQaiusJnbwQUW1uEHQ29eqo8gkWK2IXUEhseiWwwQcx+v4HgcTQD uHJy95mMXtOlZHGbZHfItPnBZBihyKvQqR/Q0ybrRz4c/HD+4N11iG2/ZwUjFZxzWDUF tWBpxrvf0GCYHr9b90sMwYQEVDbv0lv9wpzpS6GAsqxzCKa6769WuykDXlHRQRnuiVC4 NvdfNI5D6Io9VsUNxcfIFuYbk86xy7k6j51IWvpt2T71wXE/nJxSjHLDZA0unhXZ+ZeE XB8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772210378; x=1772815178; 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=wOopsDGgUiNotjq0Ge/g/xxO6M16rMuosOrkMYpkHIc=; b=K2Z+tyY2VNn2/jWj8vMKsaa82M4faVgPDAROHsrbH/jwrAAyYKztKCyn9SgKVQ4r+f +lspZSDEX17o1Qyp7vTQYG0GYU7KyZYnGVh9Igg/nepHxyA6TKNWIa3Sc6jN+Z3X+cEX IzQAi30MjNZvMM2Z//wakjpcsYLUD6/faXlaQNJ1b+gcYcoFxiyzFHb9LWzlDizD3nKK 6+UeGYYWn8ztiKByMbcQLuNzqWVUvodo3f3wUKJE3OHJkc+FLEVYxPAk2q98OIyy3ASW uH6la4cgkBxRzL9/zz8bhqJFwFdcMHSo5OGUOnFX2PMI2Pz9JEv0fuOWRI4abcMGJd1c VFyg== X-Forwarded-Encrypted: i=3; AJvYcCVjdqEh4snN5K2jubK8xocWyp/MKDDZuk+E6Okpu86jjJhgTc8CWfmwf1Vm617yESAVV+E6M3i64Qne@gnusha.org X-Gm-Message-State: AOJu0Yz3qJII1Km3JSu6WyqD8NATK68UWOon/cXDkuOYLBLhoqvsG+x6 z/hDGRCmHfW8L+xwHL1cn0IqdnelAeKYBZj5kn/RvKzBHFU1bflshvLn X-Received: by 2002:a05:6820:3107:b0:679:92c7:2c11 with SMTP id 006d021491bc7-679fadb7490mr2369135eaf.10.1772210378242; Fri, 27 Feb 2026 08:39:38 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+EooCqHM3deNp/RAoN4UIpKMC9bW/pvLbMvsJ5bZVa9RA==" Received: by 2002:a05:6820:80d:b0:679:c3ec:1cf5 with SMTP id 006d021491bc7-679eab5f407ls1791874eaf.2.-pod-prod-08-us; Fri, 27 Feb 2026 08:39:30 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCX9wi916RsHm7u/5tZD0HhvqDkr2+RDaaxy2Ny/7k7PtFzYpfeuwdh8X31hlu2kDwIdCQ13B4nQryLd@googlegroups.com X-Received: by 2002:a05:6808:1786:b0:45c:881c:e0c0 with SMTP id 5614622812f47-464bebe885fmr2085396b6e.47.1772210370132; Fri, 27 Feb 2026 08:39:30 -0800 (PST) Received: by 2002:a05:600d:8494:20b0:483:7fa7:460a with SMTP id 5b1f17b1804b1-483c9c588cems5e9; Fri, 27 Feb 2026 07:19:03 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVHfK34BZOZ4HUDdMFyCCvdUF1eN/G8oeR0DIA3A5Gw1hsjzNzqO2SK3NleX+OQFpclbYrqfyzZaanG@googlegroups.com X-Received: by 2002:a05:600c:3106:b0:483:6a8d:b2f9 with SMTP id 5b1f17b1804b1-483c9ba6165mr55090515e9.5.1772205541660; Fri, 27 Feb 2026 07:19:01 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1772205541; cv=pass; d=google.com; s=arc-20240605; b=RHB3QSIqtVAl/EhhfzfakE9sXDcN2NNhDotYmzJ3QyxntcHFpJAv39kibr7oG6rZ/e 2vin1Z+li5ArtgmH5q8FhjVs+4JiJ1y4GnQcvtkEV0R7qsujEBc6i2VOHle3hInBMPg7 lGFmyEcqejcpKlvOG88N30QyFIOFA7DK/zyff7Qt0DISeNEsrs4kcXQqyFO9lkhN/0gX jgeIxV41+xPXqX3gKkwNoxDKv4zFbB5KXHyf5Nb90mEy+0Z9iDyS2BSOHvPZ1hIA8RHO unbk2z9anfbP+jdgZp1v2+xAoORcFK7fz8jfBN5ijpcbLPmWLv4qsyn/JGrCOOOuLrZD x0iA== 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=DrhYxvSlmHgb2F2O+9aY4s9vb/xXAaB6LlVCMpKmPMw=; fh=13jZNToYvVHSmh+GMJWW1Ataf9bDqgqe3e642v3+u+I=; b=Bo7P8d0fIa2KAWVXqnyvEa8f3I2Q/wLIhCft8MvLfhum8MCjq9fNjzTcFjgaTwOJ9m abNEuDWki8HDw3PheKoEqEgDfkDBkbR1oet6Ly1YxbzfuIMLWKAxS0aKCVCuwXCPXlFU UdPKIviLYTBm0jqxXTDrXQ+FywryVc2VgJ45a1CTCofManpSmSJIIUpf9J+Jrs6/ENrn Pp8jFIt9RkBMz0IIHflAruB3on/gz31QfWKINuFsVygHI8yw8+nKPcOplyFEphKzgxUO NfyLPR+uh6ITqRt1LAuJ4wrndJv+ZYxRPJN6KpR7xUdMWBofGtkcusYSUNIPkn2y3I4o wHqw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=m1VUPr4T; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::229 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-lj1-x229.google.com (mail-lj1-x229.google.com. [2a00:1450:4864:20::229]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-4399c60d939si73239f8f.2.2026.02.27.07.19.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Feb 2026 07:19:01 -0800 (PST) Received-SPF: pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::229 as permitted sender) client-ip=2a00:1450:4864:20::229; Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-389e146ed25so2388241fa.3 for ; Fri, 27 Feb 2026 07:19:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772205541; cv=none; d=google.com; s=arc-20240605; b=lP67QxLKcMsD7PBnSIVGzd+cqe2/y0uVxNgfJAIGpnE1bxj1DRt85RVFBl3r7fCLEC F8oH8FdDgbE/DR6SgwX2mF7QHIO5YM5YnqbBmjSaBuFJfMyK+1Cjcjq0VFrm/e1WtfBc ArfBpcziiCkP1BX7exBpYS9hUcOeKgot9l2nQpM8WDgNE7FAo5RTIgy1nUnsfEr7Q5Pl qzWKocgw3WL0hRERk8kWIOW2nD9+W/pCkGaB7dAz+T7eiXttXmnXZU0kGp6bYg4jGcAY xEkjT+bZrjXq1h1OB10QSxaZsKF406QuWGViO6cSNq1Qf4qbcMlURfAp776lZo5I3Keg Ht4w== 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=DrhYxvSlmHgb2F2O+9aY4s9vb/xXAaB6LlVCMpKmPMw=; fh=13jZNToYvVHSmh+GMJWW1Ataf9bDqgqe3e642v3+u+I=; b=Os1YzU77HMZQNvYgxbT9j0cd/idsfpykJAg7oOFHHZeiCo3SlmfkdBPjN1GV52VUvc jJt3kXfhbgS91nsD/93AZCeKvcOvIrwFP+wkTafdexV5U8ynyz3iKmbILVbFryiOtLu9 1rfeHL6NUhO1xbiKiF/ZX0CmEmtse6a+TuwNL6vLDfKUJufGi2cpBQaYFrkbfycXU/mQ aWS9zORUVhoyLlDj3efxUpm59WFLjX0P1OBmxDqvmgVyFO8i9eJXd9z58eNdLYjTeC2P 332DhWWJ8wpk0h3dZGwTXf4ERKjPh9qb+pSjdao4ra4J7HV9VTP3m9C7gRwg14ulBQDs Kg7w==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCXFPztLbCypLHbu8fexjabOT3E2bj1RSnrMVRueJFLOctrGs/p83mCLRXCuaQSd9ss53T4bfCdfG+JD@googlegroups.com X-Gm-Gg: ATEYQzz/etT+4pnQy3odcoOGFfCX4UlsYwwChGMo78pvIao5+Mdeav8T8KadfOG19xZ sO1+gFHzBr/PwobvzdsPgRqlAI6UZnz3I5U/l+ywUAjy/9POdDl94t/AXa27TWRlQIJdbqk29PX rANgt7M54DCn4N5aHiZq6ZOgzgfdCx+b4NKb2Rd0Rine3D2HDA1Ypecy4LUSTNdljrU5l/ELjlN s5v0vKS/vOTeVAZJrgR67GzDwcwtr81cGNk8pJ1G5veXwHDBjfQwbvl9/zquiJd9kukQTr99WDO i/MTtTrRnmCgA40oaZqYTjXH6XWhZOeRVwH2bQ== X-Received: by 2002:a05:651c:12c3:b0:386:3371:8 with SMTP id 38308e7fff4ca-389ff11477cmr9414381fa.2.1772205540393; Fri, 27 Feb 2026 07:19:00 -0800 (PST) MIME-Version: 1.0 References: <1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b@mattcorallo.com> In-Reply-To: <1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b@mattcorallo.com> From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" Date: Fri, 27 Feb 2026 16:18:46 +0100 X-Gm-Features: AaiRm50TgihOtelvYWombm4YgkDhdml5kEGIwYPrbLO1M1E8wcR0KMgkYbIYY44 Message-ID: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: Matt Corallo Cc: Ethan Heilman , Erik Aronesty , conduition , "garlonicon@gmail.com" , Jonas Nick , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000b45639064bcfc147" 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=m1VUPr4T; arc=pass (i=1); spf=pass (google.com: domain of mkudinov@blockstream.com designates 2a00:1450:4864:20::229 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 (-) --000000000000b45639064bcfc147 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking of Lattice-Based solutions. There has been significant progress in adopting PQ solutions in the real world. Signatures are not as widely deployed, but the work is going on. There is a recent update from Apple: https://support.apple.com/guide/security/quantum-secure-cryptography-apple-= devices-secc7c82e533/web . An interesting point is that it does not use level 1 security for lattice schemes (it offers level 3 or level 5, both for ML-KEM and ML-DSA). A similar approach was used in Cloudflare: https://blog.cloudflare.com/pq-2025/. More specifically, see this part: https://blog.cloudflare.com/pq-2025/#ml-kem-768-and-x25519. Let me cite Bas here: "There is a lot of trust in the (non post-quantum) security of X25519: matching AES-128 is more than enough. Although we are comfortable in the security of ML-KEM-512 today, over the coming decades, cryptanalysis could improve. Thus, we'd like to keep a margin for now." Cloudflare settles for a smaller margin for ML-DSA, but the reasoning is that they can upgrade later if needed: "ML-DSA-44 as level 2 is comfortably above level 1. It's indeed below ML-KEM-768. I'd be comfortable with level 2 ML-KEM, but that doesn't exist. Anyway, ML-DSA requires less margin as it doesn't suffer store-now/decrypt-later. We can roll ML-DSA certs if attacks improve, but we can't roll captured data encrypted with ML-KEM." In our setting, switching to a new set of parameters is more difficult. So, it seems reasonable that, if we are discussing a lattice-based construction, we should also include some margin. That said, if we exclude level 1 security, the smallest size we get is 3073 bytes for Falcon level 5. See https://pqshield.github.io/nist-sigs-zoo/ for a quick comparison. Level 3 ML-DSA requires 5,261 bytes. Of course, lattice constructions have more to offer than just smaller sizes. Different schemes may allow for public key derivation, maybe more efficient multi/threshold signatures, and so on. We should keep in mind that, if we want to include a security margin for possible future improvements, the sizes will be larger. Best, Mike On Thu, Feb 26, 2026 at 4:56=E2=80=AFPM Matt Corallo wrote: > > > On 2/23/26 4:42 PM, Ethan Heilman wrote: > > > I thought "tweaking", in general, is lost in SPHINCS, as well as > multiparty sigs. Be interested > > to see those solutions. But, regardless, 17kb sigs are... not > compatible with a decentralized > > bitcoin, imo. Lattice-sigs are the only reasonable PQ way forward and > they aren't ready yet. > > > > SPHINCS is ~8kb (7,888 bytes) not 17kb. > > > > SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures > > Total size of 7,888 bytes not 17kb. > > > > The Lattice sigs aren't that much better than SPHINCS > > > > CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte > signatures > > Total size of 3,732 bytes. > > > > Falcon has 897 byte public keys and 666 signatures > > 1,563 bytes > > > > ML-DSA currently has the most support in the Lattice world, but it is > still too large to be a drop > > in replacement for ECC without a witness discount. If we had to choose > tomorrow, I'd advocate for > > ML-DSA with a massive witness discount, but I'd be very unhappy with th= e > witness discount. If the > > witness discount was out of the question, then I'd advocate for > something similar to 324-byte > > stateful hash based SHRINCS signature. Neither is ideal. > > > > My current thinking is to use SLH-DSA as a backup. This keeps us safe i= f > everything goes wrong and > > allows us to reach safety early so we can take time to determine the > right drop-in replacement for > > ECC. Hopefully in 3 years, SQI-sign is fast enough to be considered. > > > Why not just do SHRINCS today? The cost to use it in "stateless mode" is > only marginally higher than > other stateless hash-based signatures, and wallets can elect to use the > stateful mode at signing > time if they're set up for it. > > Matt > > -- > 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/1ee30c09-ca46-404f-a9f4-2ff8= ff6a2c0b%40mattcorallo.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/= CAPcK4uQvkjUAAvVxS2%2BgX8VBiXp5cnxvCURRtkJSOMU5wfRVHA%40mail.gmail.com. --000000000000b45639064bcfc147 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking of Lattice-Based solutions.=C2=A0There has been s= ignificant progress in adopting PQ solutions in the real world. Signatures = are not as widely deployed, but the work is going on. There is a recent upd= ate from Apple: https://support.apple.= com/guide/security/quantum-secure-cryptography-apple-devices-secc7c82e533/w= eb.

An interesting point is that it does not use level 1 securit= y for lattice schemes (it offers level 3 or level 5, both for ML-KEM and ML= -DSA). A similar approach was used in Cloudflare: https://blog.cloudflare.com/pq-2025/. More spec= ifically, see this part: https://blog.cloudflare.com/pq-2025/#ml-kem-768-and-x2= 5519. Let me cite Bas here: "There is a lot of trust in the (non p= ost-quantum) security of X25519: matching AES-128 is more than enough. Alth= ough we are comfortable in the security of ML-KEM-512 today, over the comin= g decades, cryptanalysis could improve. Thus, we'd like to keep a margi= n for now."
Cloudflare settles for a smaller margin for ML-DSA, but= the reasoning is that they can upgrade later if needed:
"ML-DSA-44= as level 2 is comfortably above level 1. It's indeed below ML-KEM-768.= I'd be comfortable with level 2 ML-KEM, but that doesn't exist. An= yway, ML-DSA requires less margin as it doesn't suffer store-now/decryp= t-later. We can roll ML-DSA certs if attacks improve, but we can't roll= captured data encrypted with ML-KEM."
In our setting, switching to= a new set of parameters is more difficult.
So, it seems reasonable that= , if we are discussing a lattice-based construction, we should also include= some margin. That said, if we exclude level 1 security, the smallest size = we get is 3073 bytes for Falcon level 5. See=C2=A0https://pqshield.github.io/nist-sigs-zoo/ = for a quick comparison. Level 3 ML-DSA requires=C2=A05,261 bytes.

O= f course, lattice constructions have more to offer than just smaller sizes.= Different schemes may allow for public key derivation, maybe more efficien= t multi/threshold signatures, and so on. We should keep in mind that, if we= want to include a security margin for possible future improvements, the si= zes=C2=A0will be larger.=C2=A0

Best,
Mike=C2=A0

On Thu, Feb 26, 2026 at 4:56=E2=80=AFPM Matt Corallo <lf-lists@mattcorallo.com> wrote:


On 2/23/26 4:42 PM, Ethan Heilman wrote:
>=C2=A0 > I thought "tweaking", in general, is lost in SPHI= NCS, as well as multiparty sigs.=C2=A0 Be interested
> to see those solutions.=C2=A0 =C2=A0But, regardless, 17kb sigs are... = not compatible with a decentralized
> bitcoin, imo.=C2=A0 =C2=A0Lattice-sigs are the only reasonable PQ way = forward and they aren't ready yet.
>
> SPHINCS is ~8kb (7,888 bytes) not 17kb.
>
> SPHINCS SLH-DSA-128s has 32 byte public keys and=C2=A07,856 byte signa= tures
> Total size of 7,888 bytes not 17kb.
>
> The Lattice sigs aren't that much better than SPHINCS
>
> CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte si= gnatures
> Total size of 3,732 bytes.
>
> Falcon has 897 byte public keys and 666 signatures
> 1,563 bytes
>
> ML-DSA currently has the most support in the Lattice world, but it is = still too large to be a drop
> in replacement for ECC without a witness discount. If we had to choose= tomorrow, I'd advocate for
> ML-DSA with a massive witness discount, but I'd be very unhappy wi= th the witness discount. If the
> witness discount was out of the question, then I'd advocate for so= mething similar to 324-byte
> stateful hash based SHRINCS signature. Neither is ideal.
>
> My current thinking is to use SLH-DSA as a backup. This keeps us safe = if everything goes wrong and
> allows us to reach safety early so we can take time to determine the r= ight drop-in replacement for
> ECC. Hopefully in 3 years, SQI-sign is fast enough to be considered.

Why not just do SHRINCS today? The cost to use it in "stateless mode&q= uot; is only marginally higher than
other stateless hash-based signatures, and wallets can elect to use the sta= teful mode at signing
time if they're set up for it.

Matt

--
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/1= ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b%40mattcorallo.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/CAPcK4uQvkjUAAvVxS2%2BgX8VBiXp5cnxvCURRtkJSOMU5wfRVHA%40ma= il.gmail.com.
--000000000000b45639064bcfc147--