From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 26 May 2026 23:22:42 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.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 1wS7f7-0002qu-Rp for bitcoindev@gnusha.org; Tue, 26 May 2026 23:22:42 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7e3a338673esf24069536a34.0 for ; Tue, 26 May 2026 23:22:41 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1779862955; cv=pass; d=google.com; s=arc-20240605; b=cnhh7BrrXLf1w26LgO5Ary03qJFDXLb9XkXVBseI2/KwmdCVC1nJ1dLRmNwEjIwBMP VQIDBQKN1bYdqFtY26lWNJMyPjSbAG9zWSJnr/sWTIaJVMrUy36N9LG06LRqiFHJAwQ6 ogpHQ6NqRaXQ6OLQ8sHLtDzpizySLmIf0M8BiW3g7OfjBfcp+I9Wn4OhvhdVXttqXgTO vgaeUlgyJuMQwxkjilJmL9Pa0idPd6dPqPF7G850QY3f/ahZcRBlG1XHeP/v03/ePrW2 H8pDyuaj+LFmc1QpJIyafHkngWhr5eSd2xkgis0rpvn2cEHzWDyv5JZlFxw82c/huGRr ZpVA== 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:content-transfer-encoding:cc:to :subject:message-id:date:from:in-reply-to:references:mime-version :sender:dkim-signature:dkim-signature; bh=ZYsOWSob1S9XXGdzczRAJHYaCSFUNXzM4zlDqFtXNZg=; fh=r+f+IWnXlg4msSRyuCPs7Ob/cBw/JSr97G2i/38YQqw=; b=CrhpybbpeZXCZJFSnHzZvcBFWLh9/y914cuc78/4KVQxgg2RRy1UUth4mO2BxjuRaN a8SkzOeHCbZh5HX0p8iBxM85o+joj7n2LrQs1k2/hAAKDoliSX7VtZFupzOY3iXwUoiv okGgv7CiA+OqGQ4hHnj/q9nNtlVfLgXSUSw0H/DYYThTiuFKhOuUSQIwpXF5eRTcEj+8 oW8PmecoOtXXFb0wMOfBpcV9fgkWYfdXqmf7gsKxOwC5ifpp9EA/xsTVVlV9Ms2LNhbF LZvwmZo2slPyOYtk2X+bMgWidiMlkv7MdFiFs2i67NeA9zo+TMLdqWUTkuLVtIpg4vqb mx3g==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=AUrVx8W8; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::132b as permitted sender) smtp.mailfrom=bnagaev@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=20251104; t=1779862955; x=1780467755; 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:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:sender :from:to:cc:subject:date:message-id:reply-to; bh=ZYsOWSob1S9XXGdzczRAJHYaCSFUNXzM4zlDqFtXNZg=; b=CNyvhDQXai+sysNJfnxngcFFA4FQS01ZHg43rjTM0kMGhZ7xCbX2XXBN+2B0WDwWzU ipMkI7wd46eBbUS8onUs4jDBHKWHDgOOta51Sjnoh2TuxRPruaTK7gXTb2tshVPcap0P RSiyQOpqnWfpR2o8lKGfSlJIcTifAiXeDd/OAHahYU2ZzVR+vBI8GnoXOuB4IKHGaZ+Q Di67xM+NPiuxXopafV88cmghuSoH6/Yt/FpQ12CF3T87zdXEGCOYSZRWaksxhs1iEjjS 5a6EPdCZMkTl/4OSc9MzXmh/O4Ywl26leYnyRMurYnAR3drLrwjS6jEClajVSRhXWY/7 Yl6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779862955; x=1780467755; 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:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=ZYsOWSob1S9XXGdzczRAJHYaCSFUNXzM4zlDqFtXNZg=; b=aO3GwnXU62qOV2W+WuFE0azZKTeFf50NylrmhsFa12m4hWvkxF+vQFPdtd5KaJaheQ VVv+fhpxVy7hndFGCVtlL6AzhW6JL8W7oYqqPrmT8jQbO4d4Zxq83yFxlEjiNiV42DHj cOVM/4qehaFJ1+vChk6uk0QpYmCudxGRuWlhuJEKxAruWLYay1YTrrOb74F5Jgbny8L+ nTkpB0HYC2x8Ilb5GypJHC0dPMJ/ITLDlzQPTXUwZnYQW6xlD+1BwjK1mvsYUZgd7diS tTTtGFJCnYZfLgBNM8kaDpgYTvIofrbThnHyu1dI78gSzZzK5ZQUKwiQqHYEYX7F6s8n QHpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779862955; x=1780467755; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding: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=ZYsOWSob1S9XXGdzczRAJHYaCSFUNXzM4zlDqFtXNZg=; b=oE1yftY/qMqXYJPFLo5IT5uLd1sgyDxkmhBPvHXr/EK8gZmFuuFsLvyGu/QC+DNKhH WV955Y9G61rrWqM8pHF0nlCgvTR3+QCUg38AVAxKPQy3jmFsUt3JnGsA3MMis+gae6zL B1OMnUn6n4mo5NFrsMi6Ot0R0LuxIIv8vFp9YvmgTenknYYA9m9ymJsJAnO2SPSGoaeL kF2AxKx6h6QMD4d/sjZBv6/jd47ZlxWcA9dHXcb9Dn5Ij+cx8oT4hYNJPdsbA3XqGoVR Os/Tu20S6Zk+Jtn/8BewcuVjS/ect/1Ti8vla9w/lfB0CEVvoTYXfbthQ9nf8mVp5pNp tiIA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ9K5RaVTz0wWl+qdDWNBEpl3uHBsxLjg6FxC+7tiaazECprpAEWPlRZZ5fbdd8Mc8a0jAQjH0FWcZ/n@gnusha.org X-Gm-Message-State: AOJu0Yy/qAB83YIezug4X1pqN71Fo2FYBGTaC3oYSuEoTxQnX7llKB+r VeuTUDQNlR8IK7dY2CTxsljHTsPayItEWfpP6NRCHVtVyrJ8cYq8kA9Y X-Received: by 2002:a05:6820:1ca1:b0:69d:928a:9479 with SMTP id 006d021491bc7-69d928a953fmr8241922eaf.41.1779862955233; Tue, 26 May 2026 23:22:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPgDz5OCkdTy4Wjn5KdBp73bsseNTMPhATUmokvWbCsoA==" Received: by 2002:a05:6870:6e0c:b0:423:73f9:2b3 with SMTP id 586e51a60fabf-43c270f2604ls211912fac.1.-pod-prod-00-us-canary; Tue, 26 May 2026 23:22:27 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/k3BfbFzlSJu+XcMmolzE9BUa+2faL15mR+WQPdN23eqFoOjTaisAi2dLdHqrU/H12Bjtuq7QXARTi@googlegroups.com X-Received: by 2002:a05:6808:3505:b0:485:4202:eefc with SMTP id 5614622812f47-4854aacd6abmr9482093b6e.3.1779862947885; Tue, 26 May 2026 23:22:27 -0700 (PDT) Received: by 2002:a05:6808:5c8:b0:47c:339e:add7 with SMTP id 5614622812f47-4854bbe669fmsb6e; Tue, 26 May 2026 23:17:19 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/OzQN9gMQ5A9r2d/tHuXFImfvcV6sVQ+2frfT8xWBCGK/U+SzGJjHV2N5xlft10IiDgeuT+0kh7AKz@googlegroups.com X-Received: by 2002:a05:7022:6b95:b0:123:3c24:b15 with SMTP id a92af1059eb24-136340ce619mr9055389c88.19.1779862638255; Tue, 26 May 2026 23:17:18 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779862638; cv=pass; d=google.com; s=arc-20240605; b=LwgVhRmyFbhgALeDQ5YPi+gFdSSaNUmABNRRqo73KI8adZrjTratqaGCRfZB2ljhkm 4LJBUACjBmb5G4FkuEfeWs2jf/44yO1mQOtBsVcyI6O7ONomNiToMu6C+iQjyuPNvLnP 9Xnf1Ly4EH+2zTCTp9ivUUOUdGvdwkx/RTfQCcks3PAJtBcOORu95ysLALYSt2ooBYD6 hFNnW6a0O360yn+/UsQnipxh8rBNKa2UECIfjYtvv2fHMqXnimg2tqPhKauS8I/OCX2v u3RJneTsW1ZbkRpIJm2lSgqeLAh9KiSPAjvBZjr9k9ZyhxSED7xOEVvc9oAt980mm3TX RJmA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Pv1DBViEhBz1Vf750yqMFPPzJjGIARYhZTgf8L4G5hM=; fh=ZUODLdgftFENTa6M8s2NoytE0q5pa3MuljVpWNNnspM=; b=XSLJxFLsjDPJ4+nitFijXqPxP+6fEktlznFimarhaleRsD51s90iIYPr11k7Or4iqZ fK0mHW7e0EomYTVyC/fBfcy/erERhELsoGhnC3LfvtlQ26GS+WPSYT8xrKFH3nJE0HcX vA8Rrtt7R4PfYw6FOO+Q5JofE4FpRrVMIcSpqkZB5P4WrZUQ49cDx3ZJuy4eSHl5Lvq9 dFrRyRAYeqTmjlwD83tB1koxmJmEiw2JCkn1Z3vgBPFVEd4PsMuJqavyRK/tWo+YDfek eErrz9MxfGO1hBN5aDxKyrv2aNp93vPZfJV2zNUF3K8MlhyWXOn9yKGr/0BWepjZak2r +Bqw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=AUrVx8W8; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::132b as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dy1-x132b.google.com (mail-dy1-x132b.google.com. [2607:f8b0:4864:20::132b]) by gmr-mx.google.com with ESMTPS id a92af1059eb24-1366aba191bsi465922c88.5.2026.05.26.23.17.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 23:17:18 -0700 (PDT) Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::132b as permitted sender) client-ip=2607:f8b0:4864:20::132b; Received: by mail-dy1-x132b.google.com with SMTP id 5a478bee46e88-2bdcf5970cdso8022768eec.0 for ; Tue, 26 May 2026 23:17:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779862637; cv=none; d=google.com; s=arc-20240605; b=P5Mi40u4Iuck/yPA8YW2PdczTuJdrAsxoBn9+HjxgmX3FwB+QPuxW6bYtOLU3W5wz6 mI2UgbXIvKjJbvYLK3rmhlJ6I8nrUzeYmeyZcEXXqOIuibYDso1WMifoQiMOBq+CCYm8 PbppVK7NMM3l1c0MjWFisv3424YSPFL3qSl4a9l4NHs6uXYVWbEBYJezZB9OaoLUx732 3Ex0bDx3fvzSTmY/4hFhU1oGzsXLtQtTd7CXzM/wNYYrhbCJClIHwv5sL7OJWxG090OC RE2ghdZjtoRHWl65isbuRDgxdiFDY/KQKB8+c3TZgPmc+igU3TJBILi7/rtZRMt4nRn8 DPaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Pv1DBViEhBz1Vf750yqMFPPzJjGIARYhZTgf8L4G5hM=; fh=ZUODLdgftFENTa6M8s2NoytE0q5pa3MuljVpWNNnspM=; b=SLcg7QtZH/Bk/VnGjZh9qdUAGf2xkPCoTrRqzFXlnXQUYSk8WVvhYG0XLckQGdfx93 mkyM9XYFwnqr+XldZd+QIBlxSb55em6yHly3o3zWM89GMEHM1i7LiD56c1DDOl4e6ph1 s1gyBHwnLJh5i/vpAjuszQoXsii+9ekk/QC1auC6/5/AZhs3pxlLNLfh8bL/XeaAG8XV omOJV4Hf6hFu3bza6C4qsWK861+O4XTfQGNPO/STHV4/6eKU40VHsNUV/qv4lWwHUMHw LGRpLZi3pDchHVRVM12kp0Brn0ZBFwHmQt+tdkN0ZNanOA5uRqQMy0N+zfId7Qm5gwvJ 7FtA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ9sz5tbnDMhEbvEpsJw64JR4vAhY2LBIiaMJEWsXG5c3aPPVIpZRHjwq/rARD6mSZMzmMmYhVt1AxuE@googlegroups.com X-Gm-Gg: Acq92OHp9ES9wRGWIdXLkRg9OO2NslDFss8UqgyyIQgJzGsfhxW7TomejYkAnyKMXWs vGPkq9PShvCOlV1mTMcAQyzLvPzBUxtBR2oJCuaTeUoj5BvOKKs8sFmSVBO9+RCU9U77Y+mz+SL B/iIYW9XNlHuENSgZWEYQBSXmfrgY47tnP2NcwCqgSTT0HW35Kn5+SmKBUnNPjoyo0GQts4/l4n da3KrEAZa4Azfih9wyQWBUEAnGqgA62UrkO/zudIeRJztqTgOTpOSobmZTofW6VkZV5hs8MGC5o LdPS9g== X-Received: by 2002:a05:7300:5ba5:b0:2f9:1004:b2cd with SMTP id 5a478bee46e88-3043109e7admr12488250eec.20.1779862637013; Tue, 26 May 2026 23:17:17 -0700 (PDT) MIME-Version: 1.0 References: <42faeb16-5d01-41ba-a192-e05936b84248n@googlegroups.com> <673BCz5V_RyCwtNI8IxXeDdauWVmQm9MTvtZ97_2ADXzWZNT9bLJsTx1fli-PEb1-cNIi4nCCS-BIsDP1GBMaldfMSWGBHDKl7bFZWf7T6U=@proton.me> <3975ff59-50f0-4001-bcfb-f1f444873d22n@googlegroups.com> <01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA=@proton.me> In-Reply-To: From: Nagaev Boris Date: Wed, 27 May 2026 01:16:38 -0500 X-Gm-Features: AVHnY4I98DHNCfoImgWkSrfXW9v4zN7-s7tys8ZLXyfQ4V_NhC1jLB3Mspdj9ro Message-ID: Subject: Re: [bitcoindev] PQC: Lattice-based signatures To: conduition Cc: Jesse Posner , Isabel Foxen Duke , Bitcoin Development Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bnagaev@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=AUrVx8W8; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::132b as permitted sender) smtp.mailfrom=bnagaev@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 (/) Note that if the hybrid scheme is implemented as a single construction, we can optimize its total footprint. Let's assume we do the SHRINCS + EC hybrid scheme. We can apply the following optimizations to get the same footprint as SHRINCS itself, plus 32 bytes. 1. Use an EC signature with a recoverable public key. It could be ECDSA or a Schnorr with a public key recovery option (not exactly BIP-340). Then we can put the EC pubkey into the hybrid key commitment - no additional space! The verifier recovers the EC public key from the signature and message, then checks that it matches the hybrid key commitment. Then they just use the recovered EC pubkey as well as PQ pubkey to recompute the hybrid public-key commitment. No need to store EC pubkey separately. 2. We can also save 32 bytes of the total 64 bytes in the signature if we reuse the encoding of the EC signature's public nonce R to serve as the randomization field R of SHRINCS. So the total signature is just 32 bytes larger than a SHRINCS signature and the pubkey is of the same size - EC pubkey does not add to total pubkey size. However if the same policy is expressed as two consecutive Bitcoin Script opcodes, for example: OP_CHECKSIGVERIFY OP_CHECKSHRINCSSIG then the EC public key must appear in the revealed script/witness for a Taproot script-path spend, and the two independent signatures cannot share the public nonce/randomization field. That loses both optimizations. On Tue, May 26, 2026 at 4:41=E2=80=AFPM 'conduition' via Bitcoin Developmen= t Mailing List wrote: > > We can also do that with script. > > OP_CHECKSIGVERIFY OP_CHECKDILITHIUMSIG > > Note this is an opt-in construction. The main argument in favor of a unif= ied hybrid scheme is it prevents people from using a PQC CHECKSIG operation= independently - which is presumed risky because the new scheme or implemen= tation could have bugs. > > However that same restriction used for safety will eventually become dead= weight after enough time has passed, so we need a way to relax it later. > > regards, > conduition > > On Tuesday, May 26th, 2026 at 3:29 PM, Jesse Posner wrote: > > I'm not suggesting this is the right approach, but I believe the rational= e for a hybrid scheme would be to enable lattice signatures with their supe= rior functionality over hash-based schemes, while hedging against a break i= n lattice security using BIP340. > > On Sat, May 23, 2026 at 8:44=E2=80=AFAM 'conduition' via Bitcoin Developm= ent Mailing List wrote: >> >> Hi Isabel, >> >> I'm curious to get your thoughts on the following: it sounds like Dan is= advocating for a hybrid scheme and I'm wondering if this would render the = strategy of implementing different signatures at different times less pract= ical? In other words, does it still make sense to implement something like = SHRINCS before a lattice-based signature =E2=80=94 if we're ultimately hopi= ng to implement a single hybrid scheme as Dan proposes here? >> >> >> Argh, I'm a bit torn about the idea of a unified hybrid scheme. Like on = one-hand, yes, technically if we wanted to maximize security and reduce mis= use, we could do it. For example, SHRINCS+BIP340 in a single unified scheme= . Or HAWK+BIP340. This would be strictly more secure than any of these indi= vidual schemes in isolation. >> >> But also, a unified hybrid scheme would immediately be handicapped and u= ncompetitive after Q-day. It would inflate witness sizes by around 100 byte= s per input, and complicate signer code for no good reason (except arguably= to mitigate statefulness risks). A hybrid scheme would create a technical = debt we'd have to pay off later by migrating everyone to a pure PQC scheme,= maybe even requiring another soft-fork. That kind of tech-debt is easier t= o pay off in a web2 world, but not so easy on a blockchain. >> >> Perhaps there is a way to engineer it such that we can soft-fork the ECC= component of a hybrid-scheme out later without the need to migrate everyon= e. Or we can bind individual schemes together into a hybrid scheme using fe= ature flags (e.g. each pubkey starts with a flag byte, where bit 0 turns on= BIP340, and bit 1 turns on SHRINCS, etc), and let users migrate on their o= wn without a follow-up soft-fork. >> >> However, I'm not convinced that any of this engineering complexity is ne= cessary when you can achieve comparable security by hiding keys for classic= al and PQ schemes in two different P2MR script leaves, which was an OG defi= ning use-case of P2MR. >> >> Or you can get almost exactly the same security, if you use both schemes= in the same script leaf: Anyone who wants the security of a hybrid BIP340+= SHRINCS scheme is free to implement it, and we could even write wallet stan= dards for it. But to require everyone to use a hybrid scheme seems overkill= to me, especially if we're talking about hash-based sigs which are arguabl= y more classically secure than ECC (modulo the risks of stateful schemes). >> >> regards, >> conduition >> On Saturday, May 23rd, 2026 at 6:49 AM, Isabel Foxen Duke wrote: >> >> Hi Conduition, >> >> Nevermind on the hybrid scheme question -- Jonas explained in this threa= d that hybrid scheme is likely something that would happen on the wallet le= vel (not consensus/opcode level), so this is now clarified on my end - than= ks again for all your help! >> >> x Isabel >> >> >> >> On Friday, May 22, 2026 at 8:25:41=E2=80=AFAM UTC-7 Isabel Foxen Duke wr= ote: >>> >>> Hi Conduition, >>> >>> So glad you enjoyed the interview! I'm thrilled Dan is speaking on quan= tum-issues more publicly these days :) >>> >>> Noted about threshold signatures and other features potentially being o= nly theoretical and not truly practical with Lattice based signatures. I wi= ll bring this up with Dan and see if he has any comment here - or if he has= updates that may affect thinking on this. >>> >>> I'm curious to get your thoughts on the following: it sounds like Dan i= s advocating for a hybrid scheme and I'm wondering if this would render the= strategy of implementing different signatures at different times less prac= tical? In other words, does it still make sense to implement something like= SHRINCS before a lattice-based signature =E2=80=94 if we're ultimately hop= ing to implement a single hybrid scheme as Dan proposes here? >>> >>> thanks for all your hard work on this >>> >>> Warmly, >>> Isabel Foxen Duke >>> >>> On Thursday, May 21, 2026 at 12:29:21=E2=80=AFPM UTC-7 conduition wrote= : >>>> >>>> Hey Isabel, I watched the interview, very cool stuff. I loved seeing D= an dodge your question about the mysterious "restrictions" google was under= (hello NSA). >>>> >>>> Dan is right that lattice-based crypto offers the promise of algebraic= structure, whereas hash-based crypto offers none. Having open research ave= nues towards goals like threshold signatures is a great thing. Yet the prom= ise of the algebraic structure in lattices hasn't materialized into anythin= g usable. At least, there are no schemes - yet - which tick the boxes we ne= ed. At best we have hope for future developments. Lattice threshold and key= -rerandomization schemes will likely improve from where they are now, but u= ntil proven otherwise we should make choices about consensus based on what = we have, not what we hope we will have someday. >>>> >>>> Also, in the interview Dan acted as though deploying hash-based signat= ures would preclude the deployment of lattice crypto later. It doesn't. If = we deploy a more cutting-edge cryptosystem like HAWK or SQIsign, it will be= once we have a suitably flexible and compact schemes ready to build atop i= t, and when that happens we will still be glad to have hash-based crypto as= a backstop in case the cutting-edge assumptions (or implementations) are b= usted. >>>> >>>> regards, >>>> conduition >>>> On Wednesday, May 20th, 2026 at 3:47 PM, Isabel Foxen Duke wrote: >>>> >>>> FWIW =E2=80=94 >>>> >>>> "I would actually like to push for lattice-based signatures..." says D= an Boneh in new interview out this morning (1:11:00) >>>> >>>> He primarily cites algebraic structure as allowing greater functionali= ty - and is concerned that features like threshold signature schemes will b= e much harder to implement with hash-based signatures. >>>> >>>> -Isabel Foxen Duke >>>> >>>> On Tuesday, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 conduition wrote: >>>>> >>>>> Hey Nikita, thanks for broaching the idea. >>>>> >>>>> I can't speak for Blockstream, but as to the spirit of your question = - Why people are looking at hash-based sigs more than lattices - I can thin= k of four major reasons: >>>>> >>>>> 1. Conservatism. Hash based signatures are incredibly conservative. T= hey rely on strictly weaker assumptions than what we already depend on for = other things. No other family of signatures can claim this property, and fo= r something as inflexible-yet-sensitive as Bitcoin, conservativism is appea= ling. >>>>> >>>>> 2. Simplicity. Hash-based signatures are easier to grasp, simpler to = prove secure, and easier to implement compared to almost anything else (eve= n simpler than ECC). We Bitcoiners tend to clutch our pearls in fear of tru= sting flawed assumptions... but in reality most vulnerabilities are not cry= ptographic in nature: Most are implementation failures. Hash-based sigs are= harder (but not impossible) to screw up. An experienced engineer can imple= ment FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This simplicit= y also makes hash-based sigs easier to pitch during consensus debates: It's= harder to fear something once you understand it. >>>>> >>>>> 3. Efficiency. Hash-based sigs are surprisingly fast to verify [0]. T= heir cost-per-byte is way lower than Schnorr. If you can bite the statefuln= ess bullet, hash-based sigs can even be compact (and still fast). There rem= ains some hope we might be able to use them as a daily driver if CRQCs appe= ar faster than anticipated. This efficiency comes at a price of course, but= that price is paid by the signer implementation while verifiers remain sli= m, quick, and secure. >>>>> >>>>> 4. Future-proofing. Because of their conservatism, hash-based sigs st= and a better chance of remaining secure over a long time-frame, so it seems= more likely we could rely on them to fulfill a long-term fallback role. We= will likely someday need to deploy a new cryptosystem to replace ECC as a = daily driver if ECDLP is broken, whether classically or by a CRQC. When/if = this happens, we'll be REALLY glad we added hash-based sigs first, because = then we'll have something to use if the novel scheme's assumptions (or more= likely, implementation) are broken. >>>>> >>>>> This is not to say we shouldn't be researching lattices. Or isogenies= , or anything else for that matter. We need to know what's possible, and to= educate the community about the options we have. I'm glad to see Blockstre= am funding this important work. I view hash-based sigs as the first episode= of a decades-long saga, but unfortunately we lack enough knowledge to know= what should come next. Maybe that is lattices? maybe something else. With = time, effort, and (hopefully) funding, we shall find out. >>>>> >>>>> If I had to pen a wishlist of stuff I'd like to see from lattice cryp= to research, this would be it: >>>>> >>>>> - [ ] compact keys and sigs. Ideally, less than a kilobyte witness si= ze total, but I'd be happy with at least a twofold improvement over what st= ateless hash-based sigs can offer. >>>>> - [ ] rerandomization e.g. BIP32 unhardened derivation. This has been= done [1], but AFAIK it is impossible without massively expanding the sizes= of keys and/or signatures. >>>>> - [ ] a multisignature scheme, or a threshold protocol with a DKG. Ag= ain, never seen this without massive keys and sigs, but I see no reason why= it should be impossible. >>>>> - [ ] integer-only arithmetic. Falcon keys and sigs are smaller than = ML-DSA, but it comes at the expense of complex floating point arithmetic he= adaches. It'd be nice if we could do away with that. >>>>> - [ ] signature aggregation. This is a more general wish of any PQ sc= heme, and if someone can do it, even with somewhat large sigs or poor perfo= rmance, it might make the whole scheme way more palatable, in tandem with a= CISA proposal. >>>>> >>>>> Also see this relevant delvingbitcoin thread [1] for more sources. >>>>> >>>>> regards, >>>>> conduition >>>>> >>>>> [0]: https://conduition.io/code/fast-slh-dsa-verification/ >>>>> [1]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-paym= ents-key-aggregation-and-threshold-signatures/1854/ >>>>> >>>>> On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov wrote: >>>>> >>>>> > Dear list, >>>>> > >>>>> >>>>> > I hate to contribute to the recent flood of PQC posts, but I think = it=E2=80=99s an important issue that=E2=80=99s worth discussing. >>>>> > >>>>> >>>>> > In particular, what I usually see is various competing proposals wi= thout a clear winner. >>>>> > >>>>> >>>>> > So I=E2=80=99d like to bring everyone=E2=80=99s attention to this n= ew post from Blockstream: >>>>> > https://blog.blockstream.com/schnorr-but-with-vectors-lattice-based= -signatures-explained/ >>>>> > >>>>> >>>>> > This post is interesting because unlike a lot of PQC discussions, i= t actually includes a comparison table of various approaches, where lattice= s seem to come out ahead. >>>>> > >>>>> >>>>> > This raises a few questions. >>>>> > >>>>> >>>>> > Since lattices are not a new topic in cryptography, why has Blockst= ream focused their efforts on hash-based approaches so far? >>>>> > Are hashes seen as a more conservative choice? >>>>> > >>>>> >>>>> > Given the problems with hashes outlined in the post, are lattices a= ctually the current most likely candidate for a PQC implementation? >>>>> > If so, should the community effort be focused on lattices instead o= f other proposals? >>>>> > Or is the comparison table not telling the whole story? >>>>> > >>>>> >>>>> > I=E2=80=99d like to hear your thoughts on the topic. >>>>> > >>>>> >>>>> > Thanks, >>>>> > Nikita >>>>> > >>>>> >>>>> > -- >>>>> > 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, s= end an email to bitcoindev+...@googlegroups.com. >>>>> > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%40app.fastmail.com. >>>>> > >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Gro= ups "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/bitcoi= ndev/42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.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/bitcoind= ev/ce98d232-4f6b-456b-ac3e-a1df12fa91ecn%40googlegroups.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/bitcoind= ev/01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBI= x6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA%3D%40proton.me. > > -- > 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/bitcoinde= v/CAL3ujSqcOhwga_edaYs3WfEFOLYS%2BBfMj1rG2%3D%3D%2BfydxPczd-g%40mail.gmail.= 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/bitcoinde= v/BEYEntuP_982nSOJVg_e4oIDBg0XQWyhLtMSSdB31ue1iAvMLtksMiuJS0wF-QJGKIKGuWeSW= CtOZnDxz__yQgTagnUSDfcwicYQ-QHjvko%3D%40proton.me. -- Best regards, Boris Nagaev --=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/= CAFC_Vt6wrrz%2BpVmOazHoJitTDQCbEswWDALKxiBLhFayYntVcg%40mail.gmail.com.