From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 26 May 2026 14:41:19 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.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 1wRzWX-0007ZH-Pc for bitcoindev@gnusha.org; Tue, 26 May 2026 14:41:19 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-43a62b2f85csf13457076fac.1 for ; Tue, 26 May 2026 14:41:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779831672; cv=pass; d=google.com; s=arc-20240605; b=c3OPk41KnH6T0jFjUeg6G9UtDNuiFy+KjbosR/S5WIFUv8qidV0NdFysu9DBZmTOeX d0yNWNpXyGUBsagDgxR7zloMqKTQFvlHkg9rtT6MMZD6uF9Ez7ZBg06X59Fj6VsiP82u R/z73OwwSEiPE4mpCOxCPzADS+YqndVaBpbKTc+Lsts39TObFEJNTPOOpMtOocOOo2pr 0L7oBh41iJEiHGqSCk3uRvlo0fTJrpMLYhZZTparNiry1w/lE3XopC25hkqTColflOx8 41FKTT81y/UvXzFfCLu8ZUZBoU8Mn3Tq1GUoXHOFFpB/zYjwGn4evxpISXvy4kRWntoO EQNA== ARC-Message-Signature: i=2; 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:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=5S1/Oj1Gw1Pb6JBgjgkFnwpBnci5OpByCc/jcpy/FvY=; fh=UoBLx8sGieavfx6uWzhFExnD51p+7daA+gEBPh2hcy4=; b=chmbYWpK1zyysdzB71txkdwxc2ZQMCXSR9fnH3oE4A/5eA8sVGwP9DrWaNvJeiuxtn CpWMciY7aWQVzch0XxKG6PANE+NWzC1aTbB8OpKepgYj3ePpzWDZ+iyF0TrrBM/adHPR PgtAF2rXKesxw53wzqRgHKgMTtC5yt7gK/TO7kPeO9D7dhmevB8IQS9DsWdU996e6RWc N7SE/IfrwbsUlnR561W7LEROW8tvi1BNvxKEvW8cK7zkJYGnv5uk0bWsmkSFp+xOMuKa ZCVQjQDz4BEGqUfu4yGDLn73WUiLH2XDNflffUyRmzLY17+/7GXieOMQTrO5bnKyLxWH JcnQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="KeFGA4e/"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.27 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779831672; x=1780436472; 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:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=5S1/Oj1Gw1Pb6JBgjgkFnwpBnci5OpByCc/jcpy/FvY=; b=q7luEshjy1WwaA+sTuSZAA3J1wWPmHIDLzuvP4AkusoPfsC1BUomgZDrJnwC2h9YeB 09S7NM9ONbCsBoV6DvFnlIiGwxdmfBnav9H2tVtwXBjp7HXr3sU14/IUYXOZzxjTW3EL 8RFIbvy2eG0gR1Mow85mxnuTZ14Y3PlN+UFkIvfTaaR/Vm3cEyjCQTLWrzGwLGFI2he8 nyd1bSIdtlxgkgpIB9tnUY/o+Temq7OWrC8K+08kC5ziTQxF9NxMjwTF7azVTEYUzR1e vV2GAWmsVu9imkT/DgoftHdOQ3NUwv+HWyyFppUnwV/p2yKgN8oyRN1rCMkk9YlttNd7 vfiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779831672; x=1780436472; 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:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5S1/Oj1Gw1Pb6JBgjgkFnwpBnci5OpByCc/jcpy/FvY=; b=EaL3C+nEoXgl5rBE2V3rgjRY27SRRDtTmZaFdyAnSAgcNPz6ZIMjFJXaHKm2iWHGYN m+tyw3mHIS1079to53C3+Wx7eSOoPEVE7iUrvbYZfBgWIgnLs3BMfOQSLoEaz9d3rEUM eivZLoVr73LDiWWJRm1X1zD5VFMHD4GgPz8ckz7xE+WwqHfqjHQJLQ+UDYD54kL4hLzE GPCq4r5Q786y4z5wYDpoQj3W2y5WFnavc9ysBkzra/zqIPXHH7L6AhmY9YJ8yeyCe9j0 azs9vIfemN220Kza2fnh2ENMBM/XtnfXj9xWSKXDLGrfnYOniF6cxkb3J6UMUP5iAnfM vmxg== X-Forwarded-Encrypted: i=2; AFNElJ9D9tVYzqsVz28JIYVNXrgGPQOW/otl2uRBKbH7TsywYrfvAvpOlfCnBvAr2VDovvak5D+GX2p5QbVQ@gnusha.org X-Gm-Message-State: AOJu0YxBxBT8/juu+/BaYp3sAWcLoWZ9lmPqfhSocTPrI2zBCfr+wJVg o5sAwJxEuCt/N/TNBopn1ngOwuqU2Zcc1pi33QTHL//c1Ys+AaZr9e0g X-Received: by 2002:a05:687c:4089:b0:433:cb0d:7702 with SMTP id 586e51a60fabf-43b5c1d4b9emr10099459fac.13.1779831671669; Tue, 26 May 2026 14:41:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNzfLzL/X06Utfj6OyVC3KZ/EMUFXEixQbgITv9HAxbqg==" Received: by 2002:a05:6870:808b:b0:43b:5c4e:720b with SMTP id 586e51a60fabf-43c25e9a8e2ls111408fac.0.-pod-prod-00-us-canary; Tue, 26 May 2026 14:41:05 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+/SJDXSxfPa0iKUAhIcKspRmthOhhiSpBegNzBRlJbuiUXAQQe7Gx59oS9cbwueQCLWOgYTZIPuVW/@googlegroups.com X-Received: by 2002:a05:6808:3505:b0:485:4202:eefc with SMTP id 5614622812f47-4854aacd6abmr8786933b6e.3.1779831665642; Tue, 26 May 2026 14:41:05 -0700 (PDT) Received: by 2002:a05:620a:a1cc:10b0:8f9:4d19:af67 with SMTP id af79cd13be357-9150619931bms85a; Tue, 26 May 2026 14:38:30 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ87STJ2+YWZ9LB77N45lAs/Bpsx+I4rKqk9TDiiCMB3wVS7azyHDVzK1ygUs/7uZi4HUY4ndjpxSWIE@googlegroups.com X-Received: by 2002:a05:6122:4b0b:b0:575:9f5:ac57 with SMTP id 71dfb90a1353d-5868da99739mr5228978e0c.4.1779831509787; Tue, 26 May 2026 14:38:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779831509; cv=none; d=google.com; s=arc-20240605; b=GWxJyJLZFbOrnJB4dL7UJgIGHHlv8fkmYcBL0en7T7dmUfQxyFwwD9q/3T/btVWv30 cFo8Gws/oCE2Plzx0H21eTB5Ezh/VpwzIMjhIgtSGQBAgm/k3cnD1Nz/MloYEjlBYdc+ QhUmW8IW/8dULz6ZPtLdj4HAu5taAS467xQmTE6brunZaOvtZZMN9qyDLyat0bylk0Zb qZv6gs/ByYjYPGQYpsKt32xK/zGNsbwPsiwZN4okHuuFm8tVRCUkP7ZGhTL9Hf54W/uu mRU7bClHHvuoox7//+TnMs9tQupeA6yGnElMGsvG5JcvRVQtG2G4FYSjG4ECyYk9sjOZ 1csQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=mI8DlNWzkNi2Peb6N0YiTIkYt5B7i7ijY1kWixfX87E=; fh=t6OLrq1bcxOs8/IeIF2svcHnZuwgDskFGFC+lS+Jss0=; b=WNMXOHtUs1UtWKHP545WOSfsMlMJ+H9BMFoxKHevkKAGnjyRrQgRcvYQAC4sIeIeN7 q4bLSZVkt6OJ1g4PTD/rILb7aoyDIlDjHsihyLLizgJcoMIMcJ+ZUdbE1Q2m8ZT1tK+M JletQGNjqgd3i6ZsFKU7n0/Fe/rTpAXkK/ANMcbQjJLAiAROQ2e7RNKlKLlhl2W3nOKs YaAlH2VWc9iEm+8Qt1QAf/luj10XaeXg3HRh/dYVEpi/01OefTffGS6/rLGuwPd0O9Hi Uizc/+IHP/gCxsGk9hVVt3FTJeZNLH4DMg+mP3BwxZGmFv1huUIiHXy8XaLINwinJaxO 0oRw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="KeFGA4e/"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.27 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24427.protonmail.ch (mail-24427.protonmail.ch. [109.224.244.27]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-586ec467256si437795e0c.0.2026.05.26.14.38.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2026 14:38:29 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.27 as permitted sender) client-ip=109.224.244.27; Date: Tue, 26 May 2026 21:38:24 +0000 To: Jesse Posner From: "'conduition' via Bitcoin Development Mailing List" Cc: Isabel Foxen Duke , Bitcoin Development Mailing List Subject: Re: [bitcoindev] PQC: Lattice-based signatures Message-ID: In-Reply-To: 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> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 45781c7d9c07ea0402a075138098fbeed594a09e MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------99ec4117d72fc82eedba88701ab02d2f8b62bf79786ec61b439621f631f0043a"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="KeFGA4e/"; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.27 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------99ec4117d72fc82eedba88701ab02d2f8b62bf79786ec61b439621f631f0043a Content-Type: multipart/mixed;boundary=---------------------1e94595689fb67b27c987e59f892c3a6 -----------------------1e94595689fb67b27c987e59f892c3a6 Content-Type: multipart/alternative;boundary=---------------------7d93d7ce3fbd809a91e1f56326b3063a -----------------------7d93d7ce3fbd809a91e1f56326b3063a Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 unifie= d hybrid scheme is it prevents people from using a PQC CHECKSIG operation i= ndependently - which is presumed risky because the new scheme or implementa= tion could have bugs.=C2=A0 However that same restriction used for safety will eventually become dead w= eight 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. >=20 > On Sat, May 23, 2026 at 8:44=E2=80=AFAM 'conduition' via Bitcoin Developm= ent Mailing List wrote: >=20 > > Hi Isabel, > >=20 > > > 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 t= he strategy of implementing different signatures at different times less pr= actical? In other words, does it still make sense to implement something li= ke SHRINCS before a lattice-based signature =E2=80=94 if we're ultimately h= oping to implement a single hybrid scheme as Dan proposes here? > >=20 > >=20 > > 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 mi= suse, we could do it. For example, SHRINCS+BIP340 in a single unified schem= e. Or HAWK+BIP340. This would be strictly more secure than any of these ind= ividual schemes in isolation. > >=20 > >=20 > > But also, a unified hybrid scheme would immediately be handicapped and = uncompetitive after Q-day. It would inflate witness sizes by around 100 byt= es per input, and complicate signer code for no good reason (except arguabl= y 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 = to pay off in a web2 world, but not so easy on a blockchain. > >=20 > >=20 > > Perhaps there is a way to engineer it such that we can soft-fork the EC= C component of a hybrid-scheme out later without the need to migrate everyo= ne. Or we can bind individual schemes together into a hybrid scheme using f= eature flags (e.g. each pubkey starts with a flag byte, where bit 0 turns o= n BIP340, and bit 1 turns on SHRINCS, etc), and let users migrate on their = own without a follow-up soft-fork. > >=20 > > However, I'm not convinced that any of this engineering complexity is n= ecessary when you can achieve comparable security by hiding keys for classi= cal and PQ schemes in two different P2MR script leaves, which was an OG def= ining use-case of P2MR. > >=20 > >=20 > > Or you can get almost exactly the same security, if you use both scheme= s 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 sta= ndards for it. But to require everyone to use a hybrid scheme seems overkil= l to me, especially if we're talking about hash-based sigs which are arguab= ly more classically secure than ECC (modulo the risks of stateful schemes). > >=20 > > regards, > > conduition > > On Saturday, May 23rd, 2026 at 6:49 AM, Isabel Foxen Duke wrote: > >=20 > > > Hi Conduition, > > >=20 > > > Nevermind on the hybrid scheme question -- Jonas explained in this th= read 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 - t= hanks again for all your help! > > >=20 > > > x Isabel > > >=20 > > >=20 > > >=20 > > > On Friday, May 22, 2026 at 8:25:41=E2=80=AFAM UTC-7 Isabel Foxen Duke= wrote: > > >=20 > > > > Hi Conduition, > > > >=20 > > > > So glad you enjoyed the interview! I'm thrilled Dan is speaking on = quantum-issues more publicly these days :) > > > >=20 > > > > Noted about threshold signatures and other features potentially bei= ng 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 he= has updates that may affect thinking on this. > > > >=20 > > > >=20 > > > > I'm curious to get your thoughts on the following: it sounds like D= an 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 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? > > > >=20 > > > > thanks for all your hard work on this > > > >=20 > > > > Warmly, > > > > Isabel Foxen Duke > > > >=20 > > > > On Thursday, May 21, 2026 at 12:29:21=E2=80=AFPM UTC-7 conduition w= rote: > > > >=20 > > > > > Hey Isabel, I watched the interview, very cool stuff. I loved see= ing Dan dodge your question about the mysterious "restrictions" google was = under (hello NSA). > > > > >=20 > > > > >=20 > > > > > Dan is right that lattice-based crypto offers the promise of alge= braic structure, whereas hash-based crypto offers none. Having open researc= h avenues towards goals like threshold signatures is a great thing. Yet the= promise of the algebraic structure in lattices hasn't materialized into an= ything usable. At least, there are no schemes - yet - which tick the boxes = we need. At best we have hope for future developments. Lattice threshold an= d key-rerandomization schemes will likely improve from where 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. > > > > >=20 > > > > >=20 > > > > > Also, in the interview Dan acted as though deploying hash-based s= ignatures would preclude the deployment of lattice crypto later. It doesn't= . If we deploy a more cutting-edge cryptosystem like HAWK or SQIsign, it wi= ll be once we have a suitably flexible and compact schemes ready to build a= top it, and when that happens we will still be glad to have hash-based cryp= to as a backstop in case the cutting-edge assumptions (or implementations) = are busted. > > > > >=20 > > > > > regards, > > > > > conduition > > > > >=20 > > > > > On Wednesday, May 20th, 2026 at 3:47 PM, Isabel Foxen Duke wrote: > > > > >=20 > > > > > > FWIW =E2=80=94 > > > > > >=20 > > > > > > "I would actually like to push for lattice-based signatures..."= says Dan Boneh in new interview out this morning (1:11:00) > > > > > >=20 > > > > > > He primarily cites algebraic structure as allowing greater func= tionality - and is concerned that features like threshold signature schemes= will be much harder to implement with hash-based signatures. > > > > > >=20 > > > > > > -Isabel Foxen Duke > > > > > >=20 > > > > > > On Tuesday, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 conduition= wrote: > > > > > >=20 > > > > > > > Hey Nikita, thanks for broaching the idea. > > > > > > >=20 > > > > > > > I can't speak for Blockstream, but as to the spirit of your q= uestion - Why people are looking at hash-based sigs more than lattices - I = can think of four major reasons: > > > > > > >=20 > > > > > > > 1. Conservatism. Hash based signatures are incredibly conserv= ative. They rely on strictly weaker assumptions than what we already depend= on for other things. No other family of signatures can claim this property= , and for something as inflexible-yet-sensitive as Bitcoin, conservativism = is appealing. > > > > > > >=20 > > > > > > > 2. Simplicity. Hash-based signatures are easier to grasp, sim= pler to prove secure, and easier to implement compared to almost anything e= lse (even simpler than ECC). We Bitcoiners tend to clutch our pearls in fea= r 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 s= implicity also makes hash-based sigs easier to pitch during consensus debat= es: It's harder to fear something once you understand it. > > > > > > >=20 > > > > > > > 3. Efficiency. Hash-based sigs are surprisingly fast to verif= y [0]. Their cost-per-byte is way lower than Schnorr. If you can bite the s= tatefulness bullet, hash-based sigs can even be compact (and still fast). T= here remains some hope we might be able to use them as a daily driver if CR= QCs appear faster than anticipated. This efficiency comes at a price of cou= rse, but that price is paid by the signer implementation while verifiers re= main slim, quick, and secure. > > > > > > >=20 > > > > > > > 4. Future-proofing. Because of their conservatism, hash-based= sigs stand 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 E= CC 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. > > > > > > >=20 > > > > > > > This is not to say we shouldn't be researching lattices. Or i= sogenies, 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 B= lockstream 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 els= e. With time, effort, and (hopefully) funding, we shall find out. > > > > > > >=20 > > > > > > > If I had to pen a wishlist of stuff I'd like to see from latt= ice crypto research, this would be it: > > > > > > >=20 > > > > > > > - [ ] compact keys and sigs. Ideally, less than a kilobyte wi= tness 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 done [1], but AFAIK it is impossible without massively expanding t= he sizes 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 re= ason why it should be impossible. > > > > > > > - [ ] integer-only arithmetic. Falcon keys and sigs are small= er than ML-DSA, but it comes at the expense of complex floating point arith= metic headaches. It'd be nice if we could do away with that. > > > > > > > - [ ] signature aggregation. This is a more general wish of a= ny PQ scheme, and if someone can do it, even with somewhat large sigs or po= or performance, it might make the whole scheme way more palatable, in tande= m with a CISA proposal. > > > > > > >=20 > > > > > > > Also see this relevant delvingbitcoin thread [1] for more sou= rces. > > > > > > >=20 > > > > > > > regards, > > > > > > > conduition > > > > > > >=20 > > > > > > > [0]: https://conduition.io/code/fast-slh-dsa-verification/ > > > > > > > [1]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-sil= ent-payments-key-aggregation-and-threshold-signatures/1854/ > > > > > > >=20 > > > > > > > On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov wrote: > > > > > > >=20 > > > > > > > > Dear list, > > > > > > > > > > > > > > >=20 > > > > > > > > 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. > > > > > > > > > > > > > > >=20 > > > > > > > > In particular, what I usually see is various competing prop= osals without a clear winner. > > > > > > > > > > > > > > >=20 > > > > > > > > So I=E2=80=99d like to bring everyone=E2=80=99s attention t= o this new post from Blockstream: > > > > > > > > https://blog.blockstream.com/schnorr-but-with-vectors-latti= ce-based-signatures-explained/ > > > > > > > > > > > > > > >=20 > > > > > > > > This post is interesting because unlike a lot of PQC discus= sions, it actually includes a comparison table of various approaches, where= lattices seem to come out ahead. > > > > > > > > > > > > > > >=20 > > > > > > > > This raises a few questions. > > > > > > > > > > > > > > >=20 > > > > > > > > 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? > > > > > > > > > > > > > > >=20 > > > > > > > > Given the problems with hashes outlined in the post, are la= ttices actually the current most likely candidate for a PQC implementation? > > > > > > > > If so, should the community effort be focused on lattices i= nstead of other proposals? > > > > > > > > Or is the comparison table not telling the whole story? > > > > > > > > > > > > > > >=20 > > > > > > > > I=E2=80=99d like to hear your thoughts on the topic. > > > > > > > > > > > > > > >=20 > > > > > > > > Thanks, > > > > > > > > Nikita > > > > > > > > > > > > > > >=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 fr= om it, send an email to bitcoindev+...@googlegroups.com. > > > > > > > > To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%40app.fastmail.com. > > > > > > > > > > > > > >=20 > > > > > > -- > > > > > > You received this message because you are subscribed to the Goo= gle Groups "Bitcoin Development Mailing List" group. > > > > > > To unsubscribe from this group and stop receiving emails from i= t, send an email to bitcoindev+...@googlegroups.com. > > > > >=20 > > > > > > To view this discussion visit https://groups.google.com/d/msgid= /bitcoindev/42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.com. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/ce98d232-4f6b-456b-ac3e-a1df12fa91ecn%40googlegroups.com. > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "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/bitcoin= dev/01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZB= Ix6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA%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= 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. --=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/= BEYEntuP_982nSOJVg_e4oIDBg0XQWyhLtMSSdB31ue1iAvMLtksMiuJS0wF-QJGKIKGuWeSWCt= OZnDxz__yQgTagnUSDfcwicYQ-QHjvko%3D%40proton.me. -----------------------7d93d7ce3fbd809a91e1f56326b3063a Content-Type: multipart/related;boundary=---------------------e5578b79bff28b793ae41cbb01e9f9b3 -----------------------e5578b79bff28b793ae41cbb01e9f9b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We can also= do that with script.

<bip340_pubkey> OP_CHECKSIGVERIFY <dilithium_pubkey= > OP_CHECKDILITHIUMSIG

Note this is an opt-in construction. The main argument i= n favor of a unified hybrid scheme is it prevents people from using a PQC C= HECKSIG operation independently - which is presumed risky because the new s= cheme or implementation 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

<= div class=3D"protonmail_quote"> On Tuesday, May 26th, 2026 at 3:29 PM, Jesse Posner <jesse.posne= r@gmail.com> wrote:
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, whil= e hedging against a break in lattice security using BIP340.

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

I'm curious to get your thoughts on the following: it sounds li= ke Dan is advocating for a hybrid scheme and I'm wondering if this would re= nder the strategy of implementing different signatures at different times l= ess practical? In other words, does it still make sense to implement someth= ing like SHRINCS before a lattice-based signature =E2=80=94 if we're ultima= tely 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. L= ike on one-hand, yes, technically if we wanted to maximize security and red= uce 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 the= se individual schemes in isolation.

But also, a unified hybrid scheme would immediately be handi= capped and uncompetitive after Q-day. It would inflate witness sizes by aro= und 100 bytes per input, and complicate signer code for no good reason (exc= ept 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 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-for= k the ECC component of a hybrid-scheme out later without the need to migrat= e 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 o= n their own without a follow-up soft-fork.

= However, I'm not convinced tha= t any of this engineering complexity is necessary when you can achieve comp= arable security by hiding keys for classical and PQ schemes in two different P2MR script leaves, w= hich was an OG defining use-case of P2MR.

Or you can get almost exactly the same security, if yo= u 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 wri= te wallet standards for it. But to require everyone to use a hybrid sche= me seems overkill to me, especially if we're talking about hash-based sigs = which are arguably more classically secure than ECC (modulo the risk= s of stateful schemes).

regards,<= /div>
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 more pu= blicly these days :)

No= ted about threshold signatures and other features potentially being only th= eoretical and not truly practical with Lattice based signatures. I will bri= ng this up with Dan and see if he has any comment here - or if he has updat= es that may affect thinking on this.

I'm curious to get your tho= ughts on the following: it sounds like Dan is advocating for a hybrid sche= me and I'm wondering if this would render the strategy of implementing diff= erent signatures at different times less practical? In other words, does it= still make sense to implement something like SHRINCS before a latti= ce-based signature =E2=80=94 if we're ultimately hoping to implement a sing= le hybrid scheme as= Dan proposes here?

thanks for all your h= ard work on this

Warmly,
Isabel Foxen D= uke

On Thursday, May 21, 2026 at 12:29:21=E2=80=AFPM UTC-7 conduition wrote= :
Hey Isabel, I watched the inte= rview, very cool stuff. I loved seeing Dan dodge your question about the my= sterious "restrictions" google was under (hello NSA).

Dan is right that lattice-based crypto of= fers the promise of algebraic structure, whereas hash-based crypto o= ffers none. Having open research avenues towards goals like threshold signatures is a= great thing. 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 likel= y improve from where 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 some= day.

Also, in the interview Dan= acted as though deploying hash-based signatures would preclude the deploym= ent 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 it, 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 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 lattic= e-based signatures..." says Dan Boneh in new interview out this morning (1:11:00)

H= e primarily cites algebraic structure as allowing greater functionality - a= nd is concerned that features like threshold signature schemes will be much= harder to implement with hash-based signatures.

-Isabel Foxen Duke=

O= n Tuesday, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 conduition wrote:
Hey Nikita, thanks fo= r 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 think = 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 h= arder 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, because th= en we'll have something to use if the novel scheme's assumptions (or more l= ikely, 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 e= ducate 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 o= f a decades-long saga, but unfortunately we lack enough knowledge to know w= hat should come next. Maybe that is lattices? maybe something else. With ti= me, effort, and (hopefully) funding, we shall find out.

If I had to pen a wishlist of stuff I'd like to see from lattice crypto= 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 stat= eless 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 "= 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 "= 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 "= 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 h= ttps://groups.google.com/d/msgid/bitcoindev/01s-bZes3N5535LMO_sAysU1tdXtsRs= aFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jk= A%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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/C= AL3ujSqcOhwga_edaYs3WfEFOLYS%2BBfMj1rG2%3D%3D%2BfydxPczd-g%40mail.gmail.com= .

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/BEYEnt= uP_982nSOJVg_e4oIDBg0XQWyhLtMSSdB31ue1iAvMLtksMiuJS0wF-QJGKIKGuWeSWCtOZnDxz= __yQgTagnUSDfcwicYQ-QHjvko%3D%40proton.me.
-----------------------e5578b79bff28b793ae41cbb01e9f9b3-- -----------------------7d93d7ce3fbd809a91e1f56326b3063a-- -----------------------1e94595689fb67b27c987e59f892c3a6 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------1e94595689fb67b27c987e59f892c3a6-- --------99ec4117d72fc82eedba88701ab02d2f8b62bf79786ec61b439621f631f0043a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmoWEsAJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdc0TEk1cJXfKyHG8jx4aV9JuZqzVqgT6z73F1N xzxC2RYhBEdIka0CMtrLdg13a3gpbO2E9rPFAACrZwD/clb71SPdjuROjdCI CI1iHmjvv4OwhtwJVnCXg4D6iCkBAKpHF34PtK+dn5M8TcudWSGpsAtimEZN KMhOwMNnpGYK =7yzl -----END PGP SIGNATURE----- --------99ec4117d72fc82eedba88701ab02d2f8b62bf79786ec61b439621f631f0043a--