From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 26 May 2026 14:29:43 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wRzLJ-0006oS-FR for bitcoindev@gnusha.org; Tue, 26 May 2026 14:29:43 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-43b911ac62fsf2988865fac.2 for ; Tue, 26 May 2026 14:29:41 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1779830975; cv=pass; d=google.com; s=arc-20240605; b=Cui0CMcU+7b2NCMZEVGBER645RkmjVRwJ0XpojvdBsK1MNrd6k4lVYL8PNjBb/lCtz vKepj8jh/r04pe00tvSuymt8/5l2F+/+Xony+b+MmvozwBMDF1R4igfsSOaopDxx2t4V JootcH4TT3b3aXQwnqeKkTpKmU8OhnNrpBw3c1GDyFFPUPW1H34A80qCKPQFSyltuNRv Zkw8nW6DhspiX450uZUT9vvXxfuzgAV1+rskDoocXMBCyhPCxUX2ko7qsjeeP02Q+P4j Dud1QFZAhEKld6MaTeU3HMoWnnddS/N/kJD2gVdK7fHqx+LyWRgwo7W9qreesgAvfKMJ I1Fw== 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=ui+CQx5pRkiFQAzS+K0tg4MUovIZlEfhuvZ6JfdVxHg=; fh=ZOEmG1PWPrFS6VWliCU3Q8vtNYszsGMLKAlrsAG8gzs=; b=lFOgRQXMmz/XLFNDAw+w/tWjDtQaeBWebYpPtbz+6UX/1fNlqOLnLXS6N6MhW9JJR+ SRHenGUh2jMs4QFiZNc4fmROyzJ+OXUfH1RnqKtLmZxiWvcRDNCi6bsmtkq4sTRGwqyK 3nQlSVn56D/XMR9b3rNM2NyCWqHFZRmtQbjD52VmyeWBoKGDy2RTJe0APps0wTZe8FXQ k7KXg8pVoUWEwSD/hUYkbfD6vYEsIapQYytqAY1akyG5XnyOZTEXjycY06Q8lBWdsyvX go6WjVJiDXC9y7YktkfWOwj9uk5nsV2PBGMY2hJzoJZAbeakehYNc0X9nb+dRvgfZejd P0xw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=UntFATJX; arc=pass (i=1); spf=pass (google.com: domain of jesse.posner@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=jesse.posner@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=1779830975; x=1780435775; 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=ui+CQx5pRkiFQAzS+K0tg4MUovIZlEfhuvZ6JfdVxHg=; b=p7OusjY8YdFAPBitXgBTmDAwHMeI4ZKcVQnIu92w9PWVYxtpGj+ENRBAMaYUnZg17U xB1VsRGzucmVqczexwZxu7WMYzJfBSFYDcNY/T8BegQ/+K3+zyI/HyM6i/cKfA6Ub+Uc +LiZCm0UXVEIaGoSa30zNMcdOTNqASWsID9QldesHiBJf3n+jySPltR7g4wHZcBHrTC4 ahmT4jesiLFvuToi16N9YdWoDHNjv05d3djjqFHjK2CL0RXSL2dlcOYZrAyhsAAEWg7a T3AU6mYG46ygWJZE8pNjW6a6IGcxcoDw4Kx48foFZ5Px4EBkCeY1LNQ7MOUjZVmgXze4 A4pA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779830975; x=1780435775; 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=ui+CQx5pRkiFQAzS+K0tg4MUovIZlEfhuvZ6JfdVxHg=; b=bK6qJEk8LdOwjTpyHltNb7bvJ8RZDLysMFW3WiW/grDek5UDHHDadobHRLzIw55RQE HzGjnYlwkrR1W/05iH4/Eq14EH09b/+ecuZ1paTfhzw1L50aXSArjUa3D7EwmuUCxJTw wHYI2N3C1nGgpn7QyDfz8XeX/NgmaICgkXuKhH+guw3BMDJVJ3BLJxpJf8xIyyTP/2Us qZi5rLFilQ+to4ZlMR/xKcR1G9oG61hmC/8/1VZ66FI2qe9t7zPhkd9tG1mMW6RQULTM SHCLbUoFIZ15pLcBwPbhvni5h9eh/+g2e49O6I9zd63ZOAHzQGbUqtK3zMtWkruHREL1 Islw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779830975; x=1780435775; 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=ui+CQx5pRkiFQAzS+K0tg4MUovIZlEfhuvZ6JfdVxHg=; b=ptCKqdBNCufssJc7Af+RZHWvcAJQc8uVsOi3F9W62iXaNEuM//4jD2uGwCEDeBtgeV DXxLl9wRPwGYJWb4ykd1WXyUFJ0ur5TAPiuN4wDD23vZ0GUbo+S5vbxO2XHQYzKz+Pzm 4U5oHBLYzMqLoKRXXXVvSRRSGHC8TiJzmHscKTa40HC/SnS1xp5G7OqErftERyZByK3y HGoZ2VbIsh9VSHNOIzEl/hBXpLhPT+VE92h4ePGeWEr1mkhpUxX9GNHZm9xEUefsuZnf q6GDFqfU7dbkkFo7COLUINsIpUMxrApv4YqKkn0pqbOFyPR62yedMbJYRaULoDp+2zvk gl3g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/LBR+wI+Cw5VZXH5MYAjdTYSiri8bcXFYw3lBeXEzKxxVREC+eWC1PqxvkKn94cNROqB7ByZN2+wsi@gnusha.org X-Gm-Message-State: AOJu0YzMJFPyC1Us4Z1EHRQxEzEUyahXKD2xAYx9MMt7vNvD8mHQEhxf w4NsSH8ojvcY0v3iyxOVvgJvkb7tViDvsbb4NJsDFPMhz47DMwj+XaSb X-Received: by 2002:a05:6820:4c0f:b0:69d:c62a:f33d with SMTP id 006d021491bc7-69dc62af894mr3965852eaf.33.1779830975067; Tue, 26 May 2026 14:29:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPY4AfRunITN+3XKEe28FFt+2pZWakVW2OlivurFdcTNw==" Received: by 2002:a05:6870:f22a:b0:43b:6f92:1c26 with SMTP id 586e51a60fabf-43b6f92c577ls3250231fac.0.-pod-prod-09-us; Tue, 26 May 2026 14:29:28 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ+CjblbYg40oAMOg+vUHFQY6M9ZvC9bK3fn970cZAGC/X3S+sjbIM+mNERaF634U04lVMtmOZajcs3D@googlegroups.com X-Received: by 2002:a05:6808:c1cb:b0:467:1212:46fd with SMTP id 5614622812f47-4854a456d93mr12158469b6e.33.1779830968877; Tue, 26 May 2026 14:29:28 -0700 (PDT) Received: by 2002:a05:6809:248:10b0:480:77ce:ad79 with SMTP id 5614622812f47-4854b71b921msb6e; Tue, 26 May 2026 14:29:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/ni6dgM+6LYQWM5NP15ItfC7uJv6j0eMuA/A47nQ9X2l0IPOpqmiA6lyR8HI/fbRjRdWMQMV17zpAT@googlegroups.com X-Received: by 2002:a05:6820:4c05:b0:695:3a00:855c with SMTP id 006d021491bc7-69d7ec5ae13mr10591323eaf.39.1779830943284; Tue, 26 May 2026 14:29:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779830943; cv=pass; d=google.com; s=arc-20240605; b=LOTc8aLk7BUu3IPCQIZ8ixJnxa45Wi6cWsMfaWaGFtZPpiUjaJHwds/KUfbfWwMH9o imUCQ27tXUISutYs1LQGRV+tddps9mb5oKV6k67nQNkINiC57rm7lN3oX7R3Q4rsjhXP PydURDPd8Bqoh2pW+cEdu7/IKHcNvnT57G9+8Mdsp6+Do3g/nC+9FcPzkDfyIz52CTZQ obOXgdzRySgVKJmLFUxkIdHJEeYF5zjXIvwZOXomXguGOtCpYAITrwZLePppImuSqcQp v5VmXqLxD4MpTtw1Bv3jMWYrxx5G6eZq5iefHW5F6V00gevbrATrapl5PJ6MGaPqKloG gtSg== 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=7uBaeF7ON1hyUZDrQpat2dtOeizED9f99BNqy/oy3Ro=; fh=xAMzDYY/l0triuU2DOUDplvjrc+/7wqOQHmEOn+07eQ=; b=Wh9K92eQ+SvvT1ubzGlYZpTtPlKDOvFqJnQ/oP3QUtaOWbmug0VzKLlG5Qajd3htXK MBmEnvGe1l1Xwqc6Rhf5/KnQgfuZNhSXfofi25svp7ssqu5q27fRtkqzZuw31kh7KHto 4MY+iccDKO7RcVKN9dhjeLZ+XdarUkcfYweKScU2DPV6/rjgMEgpHQnWA/ILo5HUxIAP MmiKXDV1JT55kW+kkzzOuiUSvoJn6IPiol1pCBQKpzgu/BWt95bA3rCixg3sQmweKaG7 wn0GE9LzR3fti8g2EN0j+cwtFSI+0npYyBMbaHExKcUoe4w3oo2U25YaUJxN/EGoG0f+ zeqg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=UntFATJX; arc=pass (i=1); spf=pass (google.com: domain of jesse.posner@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=jesse.posner@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com. [2607:f8b0:4864:20::234]) by gmr-mx.google.com with ESMTPS id 586e51a60fabf-43b6390294esi432564fac.3.2026.05.26.14.29.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 14:29:03 -0700 (PDT) Received-SPF: pass (google.com: domain of jesse.posner@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) client-ip=2607:f8b0:4864:20::234; Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-479eb8bcacbso7043330b6e.1 for ; Tue, 26 May 2026 14:29:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779830943; cv=none; d=google.com; s=arc-20240605; b=j4c8bdtZD5YX4th0Zjp1M7aoRsX4BIh5nKDA3xz40Pa195oHnZKhJfg31W01Awkc10 bdOdE04ne2aac2sYARiZ7zCzPI3BYsOjbIM5f24aG87BEZvrPVc4w36jYsddXW00VGRx nuQ+Z5uIos3ADqFXokgI/ysJTys/pHJFOdZR1x+vjVKfG1NX8BxB2tyVPMsACMDZ5P8I BsfOakJhkKzGQQyV/hmyMZ9kSN0MaIqgs+43GhHLW+7imFeMNfStwE+iH/DAtRp+2Ruk RZawjKpCC0Mu19m7BNdvyfv3PPbwgr+ytYP+y/zwbGqgn7f6tKH1qqjHbiZpoOCshJcH GYvw== 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=7uBaeF7ON1hyUZDrQpat2dtOeizED9f99BNqy/oy3Ro=; fh=xAMzDYY/l0triuU2DOUDplvjrc+/7wqOQHmEOn+07eQ=; b=FP0Ufjg3WSYUWBjbBRVCDhFiv98Kh8KoK9g7taNsKuktmqDTQXgO0bq2IQvzShKWvz naBD3QOwGEP44qLkAX3gdRNeZqR5zNALfMqrUPYUvDpPUX0/EGIDXYo8aavK8rVpcoRK Z85HlI0W8lnEgb/UtIu5PB+6K0cU5vNHaD7JQwcoZtPJHoojzTmdkgBQyZDmZ30ERYME /lxeTxUNZN0Q/mnHnylTaopj49bWSnGOID0FsnpZMGTlC/DfHBwN7gjTDot0cd+6Ktay /3MpGtvcwWbFu7hp7GCXZ4HVncVW7Ysq028clpNnKDtHB+goZkFY2vsalK+hMNKmpoW3 lEiA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ/VcvXkPDwHV1+lFIfCsVriKEQLeTrRXBs/WuoG/IWJ6SO8ObtCVwyIdrSOZrbOEAvdITY/+QTfoVIn@googlegroups.com X-Gm-Gg: Acq92OHUWmFiLL2aN8VntG3MXZ3RKIY7KCe1KryQaEjK8ukWHpIF4UCyPoyP5fuLSx5 0P7eYEFTn1EXkEPBhSjsI1I9qXVlKbOhgl4BEmNtsW1YGCJ+omVyJkgOIZNl+g0XhgLNdu1WaJf ABIrIb2Nqs2jxOppX/c3AOGAZsIYDVwXm8mCZUbHZHohDDK3YnZ27zI3O0Wr7Oxw2tY8gw2QHGl H+9pNeaQwfsrJm6etG65o5NEiKGJCIjqwNRQUTpG+gNfR9oxTNduybapc8ako9QL3WxAIjSbVa8 NpUz5tKIzSghzghty69r62hgiRPSphVsxghlHwz051C4opOL8SHzIiUV0SCQ/Yo= X-Received: by 2002:a05:6808:6f91:b0:485:3dd3:771f with SMTP id 5614622812f47-4854a3f9002mr11147537b6e.30.1779830942705; Tue, 26 May 2026 14:29:02 -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: <01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA=@proton.me> From: Jesse Posner Date: Tue, 26 May 2026 14:28:51 -0700 X-Gm-Features: AVHnY4IzMz7vXsAMN8s5WjhDxIvjCh7cesP4mQPQ8o9h-mfOJskH6bTs7l6tGtE Message-ID: Subject: Re: [bitcoindev] PQC: Lattice-based signatures To: conduition Cc: Isabel Foxen Duke , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000019ac2c0652bf2f19" X-Original-Sender: jesse.posner@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=UntFATJX; arc=pass (i=1); spf=pass (google.com: domain of jesse.posner@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=jesse.posner@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 (/) --00000000000019ac2c0652bf2f19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not suggesting this is the right approach, but I believe the rationale for a hybrid scheme would be to enable lattice signatures with their superior functionality over hash-based schemes, while hedging against a break in lattice security using BIP340. On Sat, May 23, 2026 at 8:44=E2=80=AFAM 'conduition' via Bitcoin Developmen= t 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 > practical? In other words, does it still make sense to implement somethin= g > like SHRINCS before a lattice-based signature =E2=80=94 if we're ultimate= ly hoping > 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 > misuse, 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 individual schemes in isolation. > > But also, a unified hybrid scheme would immediately be handicapped and > uncompetitive after Q-day. It would inflate witness sizes by around 100 > bytes 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 pu= re > PQC scheme, maybe even requiring another soft-fork. That kind of tech-deb= t > is easier to 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 > everyone. Or we can bind individual schemes together into a hybrid scheme > using feature 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 own without a follow-up soft-fork. > > However, I'm not convinced that any of this engineering complexity is > necessary when you can achieve comparable security by hiding keys for > classical and PQ schemes in two different P2MR script leaves, which was a= n > OG defining 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 standards 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 arguably *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 < > isabel.duke@gmail.com> wrote: > > Hi Conduition, > > Nevermind on the hybrid scheme question -- Jonas explained in this thread > that > hybrid scheme is likely something that would happen on the wallet level > (not consensus/opcode level), so this is now clarified on my end - thanks > again for all your help! > > x Isabel > > > > On Friday, May 22, 2026 at 8:25:41=E2=80=AFAM UTC-7 Isabel Foxen Duke wro= te: > >> Hi Conduition, >> >> So glad you enjoyed the interview >> ! I'm thrilled = Dan >> is speaking on quantum-issues more publicly these days :) >> >> Noted about threshold signatures and other features potentially being >> only theoretical and not truly practical with Lattice based signatures. = I >> will bring this up with Dan and see if he has any comment here - or if h= e >> has updates that may affect thinking on this. >> >> 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 th= e >> strategy of implementing different signatures at different times less >> practical? In other words, does it still make sense to implement somethi= ng >> like SHRINCS *before* a lattice-based signature =E2=80=94 if we're ultim= ately >> hoping 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 Da= n >>> dodge your question about the mysterious "restrictions" google was unde= r >>> (hello NSA). >>> >>> Dan is right that lattice-based crypto offers the *promise* of >>> algebraic structure, whereas hash-based crypto offers none. Having open >>> research avenues towards goals like threshold signatures is a great thi= ng. Yet >>> the promise of the algebraic structure in lattices hasn't materialized = into >>> anything usable. At least, there are no schemes - yet - which tick the >>> boxes we need. At best we have *hope *for future developments. Lattice >>> threshold and key-rerandomization schemes will likely improve from wher= e >>> they are now, but until 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 >>> signatures 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 scheme= s >>> ready to build atop it, and when that happens we will still be glad to = have >>> hash-based crypto as a backstop in case the cutting-edge assumptions (o= r >>> implementations) are busted. >>> >>> regards, >>> conduition >>> On Wednesday, May 20th, 2026 at 3:47 PM, Isabel Foxen Duke < >>> isabe...@gmail.com> wrote: >>> >>> FWIW =E2=80=94 >>> >>> "I would actually like to push for lattice-based signatures..." says Da= n >>> Boneh in new interview >>> out this >>> morning (1:11:00) >>> >>> He primarily cites algebraic structure as allowing greater functionalit= y >>> - and is concerned that features like threshold signature schemes will = be >>> 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 t= hink >>>> of four major reasons: >>>> >>>> 1. Conservatism. Hash based signatures are incredibly conservative. >>>> They rely on strictly weaker assumptions than what we already depend o= n for >>>> other things. No other family of signatures can claim this property, a= nd >>>> for something as inflexible-yet-sensitive as Bitcoin, conservativism i= s >>>> appealing. >>>> >>>> 2. Simplicity. Hash-based signatures are easier to grasp, simpler to >>>> prove secure, and easier to implement compared to almost anything else >>>> (even simpler than ECC). We Bitcoiners tend to clutch our pearls in fe= ar of >>>> trusting flawed assumptions... but in reality most vulnerabilities are= not >>>> cryptographic in nature: Most are implementation failures. Hash-based = sigs >>>> are harder (but not impossible) to screw up. An experienced engineer c= an >>>> implement FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This >>>> simplicity 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]. >>>> Their cost-per-byte is way lower than Schnorr. If you can bite the >>>> statefulness bullet, hash-based sigs can even be compact (and still fa= st). >>>> There remains some hope we might be able to use them as a daily driver= if >>>> CRQCs appear faster than anticipated. This efficiency comes at a price= of >>>> course, but that price is paid by the signer implementation while veri= fiers >>>> remain slim, quick, and secure. >>>> >>>> 4. Future-proofing. Because of their conservatism, hash-based sigs >>>> stand a better chance of remaining secure over a long time-frame, so i= t >>>> seems more likely we could rely on them to fulfill a long-term fallbac= k >>>> role. We will likely someday need to deploy a new cryptosystem to repl= ace >>>> 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 fi= rst, >>>> because then we'll have something to use if the novel scheme's assumpt= ions >>>> (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 >>>> Blockstream 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 f= ind >>>> out. >>>> >>>> If I had to pen a wishlist of stuff I'd like to see from lattice crypt= o >>>> research, this would be it: >>>> >>>> - [ ] compact keys and sigs. Ideally, less than a kilobyte witness siz= e >>>> total, but I'd be happy with at least a twofold improvement over what >>>> stateless 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 s= izes >>>> of keys and/or signatures. >>>> - [ ] a multisignature scheme, or a threshold protocol with a DKG. >>>> Again, never seen this without massive keys and sigs, but I see no rea= son >>>> 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 arithmet= ic >>>> headaches. It'd be nice if we could do away with that. >>>> - [ ] signature aggregation. This is a more general wish of any PQ >>>> scheme, and if someone can do it, even with somewhat large sigs or poo= r >>>> performance, it might make the whole scheme way more palatable, in tan= dem >>>> 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-payments-k= ey-aggregation-and-threshold-signatures/1854/ >>>> >>>> On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov < >>>> nik...@karetnikov.org> 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 >>>> without a clear winner. >>>> > >>>> >>>> > So I=E2=80=99d like to bring everyone=E2=80=99s attention to this ne= w post from >>>> Blockstream: >>>> > >>>> https://blog.blockstream.com/schnorr-but-with-vectors-lattice-based-si= gnatures-explained/ >>>> > >>>> >>>> > This post is interesting because unlike a lot of PQC discussions, it >>>> actually includes a comparison table of various approaches, where latt= ices >>>> seem to come out ahead. >>>> > >>>> >>>> > This raises a few questions. >>>> > >>>> >>>> > Since lattices are not a new topic in cryptography, why has >>>> Blockstream 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 >>>> actually the current most likely candidate for a PQC implementation? >>>> > If so, should the community effort be focused on lattices instead of >>>> 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, >>>> send an email to bitcoindev+...@googlegroups.com. >>>> > To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/ffa56d63-32c6-4fc3-a150-4= fe62ac2e00b%40app.fastmail.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+...@googlegroups.com. >>> >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/42faeb16-5d01-41ba-a192-e0= 5936b84248n%40googlegroups.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/ce98d232-4f6b-456b-ac3e-a1df= 12fa91ecn%40googlegroups.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/01s-bZes3N5535LMO_sAysU1tdXt= sRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N7= 0jkA%3D%40proton.me > > . > --=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/= CAL3ujSqcOhwga_edaYs3WfEFOLYS%2BBfMj1rG2%3D%3D%2BfydxPczd-g%40mail.gmail.co= m. --00000000000019ac2c0652bf2f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not suggesting this is the right approach, but I b= elieve the rationale for a hybrid scheme would be to enable lattice signatu= res with their superior functionality over hash-based schemes, while hedgin= g against a break in lattice security using=C2=A0BIP340.

On Sat, May 23, 2026 at 8:44=E2=80=AFAM 'conduition' via Bitcoin= Development Mailing List <bitcoindev@googlegroups.com> wrote:
Hi Isabel,<= /span>

I'm curious to g= et your thoughts on the following: it sounds like Dan is advocating for a h= ybrid scheme and I'm wondering if this would render the strategy of imp= lementing different signatures at different times less practical? 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 hoping to imple= ment a single hybrid scheme as Dan proposes here?
=

Argh, I= 9;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 misuse, we c= ould do it. For example, SHRINCS+BIP340 in a single unified scheme. Or HAWK= +BIP340. This would be strictly more secure than any of these individual sc= hemes in isolation.

B= ut also, a unified hybrid scheme would immediately be handicapped and uncom= petitive after Q-day. It would inflate witness sizes by around 100 bytes pe= r input, and complicate signer code for no good reason (except arguably to = mitigate statefulness risks). A hybrid scheme would create a=C2=A0technical= debt we'd have to pay off later by migrating everyone to a pure PQC sc= heme, maybe even requiring another soft-fork. That kind of tech-debt is eas= ier to 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 E= CC component of a hybrid-scheme out later without the need to migrate every= one. Or we can bind individual schemes together into a hybrid scheme using = feature 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= own without a follow-up soft-fork.

However, I'm not convinced that a= ny of this engineering complexity is necessary when you can achieve compara= ble security by hiding keys for classical and PQ schemes in two different P2MR script leaves, whic= h was an OG defining use-case of P2MR.

Or you can get almost exactly the same security, if you u= se both schemes in the same script leaf:=C2=A0Anyone who wants the security of = a hybrid BIP340+SHRINCS scheme is free to implement it, and we could even w= rite wallet standards for it.=C2=A0But to require everyone to use a hybr= id scheme seems overkill to me, especially if we're talking about hash-= based sigs which are arguably more=C2=A0classically secure than ECC = (modulo the risks of stateful schemes).

= regards,
conduition
On Saturday, May 23rd, 2026 at 6:49 AM, Isabel Foxen Duke <isabel.duke@gmail.com= > wrote:
Hi Conduition,

Nevermind on the hybrid scheme question = -- Jonas explained = in this thread that hybrid scheme is likely something that would happen= on the wallet level (not consensus/opcode level), so this is now clarified= on my end - thanks again for all your help!

x Isabel


On Frida= y, May 22, 2026 at 8:25:41=E2=80=AFAM UTC-7 Isabel Foxen Duke wrote:
Hi Conduition,
So glad you enjoyed the interview! I'm thrilled Dan is speaking on quantum-issues mor= e publicly these days :)
Noted about threshold signatures and other features potentially being onl= y theoretical and not truly practical with Lattice based signatures. I will= bring this up with Dan and see if he has any comment here - or if he has u= pdates that may affect thinking on this.

I'm curious to get = your thoughts on the following: it sounds like Dan is advocating for a hyb= rid scheme and I'm wondering if this would render the strategy of imple= menting different signatures at different times less practical? In other wo= rds, does it still make sense to implement something like SHRINCS before= a lattice-based signature =E2=80=94 if we're ultimately hoping to = implement a single hybrid scheme as Dan proposes here?

thank= s 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 Dan dodge your quest= ion about the mysterious "restrictions" google was under (hello N= SA).

Dan is right th= at lattice-based crypto offers the promise of algebraic structure, w= hereas hash-based crypto offers none. Having open research avenues towards goals like= threshold signatures is a great thing. Yet the promise of the algeb= raic structure in lattices hasn't materialized into anything usable. At= least, there are no schemes - yet - which tick the boxes we need. At best = we have hope for future developments. Lattice threshold and key-rera= ndomization schemes will likely improve from where they are now, but until proven otherwis= e 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 signature= s 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 buil= d atop it, and when that happens we will still be glad to have hash-based c= rypto as a backstop in case the cutting-edge assumptions (or implementation= s) are busted.

re= gards,
cond= uition
On Wednesday, May 20th, 2026 at 3:47 PM, Isabel Foxen Duke <isabe...@gmail.com> wrote:
FWIW =E2=80=94

"I would actually like to push for l= attice-based signatures..." says Dan Boneh in new interview out this morning (1:11:00= )

He primarily cites algebraic structure as allowing greater functio= nality - and is concerned that features like threshold signature schemes wi= ll be 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 wr= ote:
Hey Nikita,= thanks for broaching the idea.

I can't speak for Blockstream, but as to the spirit of your questio= n - Why people are looking at hash-based sigs more than lattices - I can th= ink of four major reasons:

1. Conservatism. Hash based signatures are incredibly conservative. The= y rely on strictly weaker assumptions than what we already depend on for ot= her things. No other family of signatures can claim this property, and for = something as inflexible-yet-sensitive as Bitcoin, conservativism is appeali= ng.

2. Simplicity. Hash-based signatures are easier to grasp, simpler to pr= ove secure, and easier to implement compared to almost anything else (even = simpler than ECC). We Bitcoiners tend to clutch our pearls in fear of trust= ing flawed assumptions... but in reality most vulnerabilities are not crypt= ographic in nature: Most are implementation failures. Hash-based sigs are h= arder (but not impossible) to screw up. An experienced engineer can impleme= nt FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This simplicity = 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]. The= ir cost-per-byte is way lower than Schnorr. If you can bite the statefulnes= s bullet, hash-based sigs can even be compact (and still fast). There remai= ns some hope we might be able to use them as a daily driver if CRQCs appear= faster than anticipated. This efficiency comes at a price of course, but t= hat price is paid by the signer implementation while verifiers remain slim,= quick, and secure.

4. Future-proofing. Because of their conservatism, hash-based sigs stan= d a better chance of remaining secure over a long time-frame, so it seems m= ore likely we could rely on them to fulfill a long-term fallback role. We w= ill likely someday need to deploy a new cryptosystem to replace ECC as a da= ily driver if ECDLP is broken, whether classically or by a CRQC. When/if th= is happens, we'll be REALLY glad we added hash-based sigs first, becaus= e then we'll have something to use if the novel scheme's assumption= s (or more likely, implementation) are broken.

This is not to say we shouldn't be researching lattices. Or isogeni= es, 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= Blockstream funding this important work. I view hash-based sigs as the fir= st episode of a decades-long saga, but unfortunately we lack enough knowled= ge to know what should come next. Maybe that is lattices? maybe something e= lse. 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 cr= ypto research, this would be it:

- [ ] compact keys and sigs. Ideally, less than a kilobyte witness size= total, but I'd be happy with at least a twofold improvement over what = stateless hash-based sigs can offer.
- [ ] rerandomization e.g. BIP32 unhardened derivation. This has been d= one [1], but AFAIK it is impossible without massively expanding the sizes o= f keys and/or signatures.
- [ ] a multisignature scheme, or a threshold protocol with a DKG. Agai= n, never seen this without massive keys and sigs, but I see no reason why i= t 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 head= aches. It'd be nice if we could do away with that.
- [ ] signature aggregation. This is a more general wish of any PQ sche= me, and if someone can do it, even with somewhat large sigs or poor perform= ance, it might make the whole scheme way more palatable, in tandem with a C= ISA proposal.

Also see this relevant delvingbitcoin thread [1] for more sources.

regards,
conduition

[0]: https://conduition.io/code/fast-slh-dsa-verification/
[1]: h= ttps://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-payments-key-agg= regation-and-threshold-signatures/1854/

On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov <nik...@karetnikov.org> 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 w= ithout a clear winner.
>

> So I=E2=80=99d like to bring everyone=E2=80=99s attention to this = new post from Blockstream:
> https://blog.blockstream.co= m/schnorr-but-with-vectors-lattice-based-signatures-explained/
>

> This post is interesting because unlike a lot of PQC discussions, = it actually includes a comparison table of various approaches, where lattic= es seem to come out ahead.
>

> This raises a few questions.
>

> Since lattices are not a new topic in cryptography, why has Blocks= tream 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 = actually the current most likely candidate for a PQC implementation?
> If so, should the community effort be focused on lattices instead = of 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, = send an email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ffa56d63-32c6-4f= c3-a150-4fe62ac2e00b%40app.fastmail.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 bitcoindev+...@googlegroups.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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ce98d232-4f6b-456b-ac3e-= a1df12fa91ecn%40googlegroups.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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkw= QzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA%3D%40proton.me.

--
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/CAL3ujSqcOhwga_edaYs3WfEFOLYS%2BBfMj1rG2%3D%3D%2Bfyd= xPczd-g%40mail.gmail.com.
--00000000000019ac2c0652bf2f19--