From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 23 May 2026 08:44:31 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wQoWb-0000cI-MG for bitcoindev@gnusha.org; Sat, 23 May 2026 08:44:31 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-43b469c6e24sf4709257fac.1 for ; Sat, 23 May 2026 08:44:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779551063; cv=pass; d=google.com; s=arc-20240605; b=LjCbVsQioNKGB82/Ij62vMkolwrFw/ys9lVoRgVOOKgxE5CBznrxT1W1WycoRm2WIy bJUiI5BiviZVSGWyh7TQU0IX/uHP/rzhyWpVwKlzdNUklxkw/8LsSYpUdcvmrAnFwykU 73c7cYTc5X9c6xJghxR+IWWu8x/JQsJ5SmkwkB6NkEFr4zX87/9hw9V0tIrmgI8kLNTp nF+mO3gxHXdzCgQqWwcccaZ5MJV1srlCMYNh+3fYvUYctwVyG0dOcOFvRhMsbi7J54sA wdUqhUcmOccez5VZlX050KaBK5z5yKTgOWDxllgkO5r5LYF2Z5lxkqEbnBreN0KlcNkI 52og== 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=5Jh8YmTvL9qs7sFqtflcUqfZT3dy++3tb/cAYxakGyo=; fh=4cHc/GMPRKTtMcvGgRKRHWr74g+2lF4DUHq4QxN1Akg=; b=Zp9lKH0o+ySVv62BL001sjH7k8NKBxMSsSFx1LD/4juEmpjx/vvURoRsu7YqDDOxzK 7aSgivZs0IBslTVbgfIjtljj4CMvQKGHBiOpQsjjW7gWAtMWhOIG5wxVmKOxkv1kXr/T +HNB4MN1uqGZScbeVuMw+EmVFaIr3s/cCqoQ2xqJVyGNETs4E8b/na3iUVv2qTuXMuqm cVRpiu6r8666c/ky8OTBoxVLfU+hsOnORQOdFam4RVF6PfNjDSbaVT6kVTcDWxJPBVEz g/6UKLPlAbZpfY0xkfj5U9qQG8Au2xitS46wCf9MbLRIxKUAWMuLNbd4waTnLiB7vCgn LwMg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Vgkv7V+d; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 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=1779551063; x=1780155863; 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=5Jh8YmTvL9qs7sFqtflcUqfZT3dy++3tb/cAYxakGyo=; b=bUAQVHTKtocJJka744D4TxMOqBAE3JRul32BtIr5kMFb55d8EBr13Nslb0raZvTyJr j3EFMOTEcX493N5prgUxvFJZ1AwjOlI4Awaq1oMd6w+B/jLAg+ZQSwwaRHRFJm3Tzz35 PZtGbDqEg+FenIK6HSceQ2CVbdmZxNxQC+eF1QER8GyeMLGECxNc76p9yXieOTuTplr5 Zg5pJXSMC9mLfqFcWqdF0SKvN3s+Xo0y+cIv/Nwjbvn+z61GPEuxo1gHxj9H5a/iGR0U xI8WyOScX4FpUo+4yjXCIHtJpmX/YUo7s6oZx1m+QEtKu9W3pvcS3n/Z70ljvQqW4tHT Mn1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779551063; x=1780155863; 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=5Jh8YmTvL9qs7sFqtflcUqfZT3dy++3tb/cAYxakGyo=; b=UynToPjA9cei/bPbvJBMYnaGmsMF0wpE2vauUEAwW8bGORlYW0RAazqn4s/g4fgfU1 JRtITJYSchKEr1i6hTMinMVmDwp7X9+XmX8fI54gDlI+yDsIv6vlAACFQiFyd6okM/Zw jiDJ5MT1kPSbXk+zQvTz51lLNWjJkgR+RtqhGorXkV8W+l/agM6GA9aS2IYs8syxkCIc RzrwRDSGQQnXOxUinWw6kDvtfj2DGgPBy1aOpT6GDdorVjBvW+h+VcOaOJBl8RRQ4Vhl Xl6eCNND0LdKedK4wb2m5/zrSCvaPJPRcaeXH9IOQYe/9QN3NXOGwHiCH8SFDp5OxMs5 WopQ== X-Forwarded-Encrypted: i=2; AFNElJ90upaK7LiH0gzC4zsE6qrJNaqCaf3l8uvRuagQq6Rr3KnTPHCcq3SGa6QbXnE60T6yzqLnHQHAPj6k@gnusha.org X-Gm-Message-State: AOJu0YwfZogAU3r736U0TnM+d2GjAe6vROOp4fty4Nngt9Jvx2xd9JwU yH7CI/BrsEo9nQhw87g9+iP9wbZKVx1+zli5+b9HuRAKcnV8PLYlk57N X-Received: by 2002:a05:6871:c3c1:b0:41c:6bf0:677c with SMTP id 586e51a60fabf-43b5abcf07emr4829495fac.2.1779551062994; Sat, 23 May 2026 08:44:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMO9wz15T//8+z67PVDU2S/YPNmcjZS3oZoyN+6XhMvXCQ==" Received: by 2002:a05:6870:8a27:b0:43b:8167:953 with SMTP id 586e51a60fabf-43b81674ccels676110fac.2.-pod-prod-01-us; Sat, 23 May 2026 08:44:17 -0700 (PDT) X-Received: by 2002:a05:6808:640f:b0:485:42f0:7eb9 with SMTP id 5614622812f47-48549d6bb9dmr4821592b6e.5.1779551057304; Sat, 23 May 2026 08:44:17 -0700 (PDT) Received: by 2002:a05:600c:188f:b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-49042d0e671ms5e9; Sat, 23 May 2026 08:38:37 -0700 (PDT) X-Received: by 2002:a05:6000:2608:b0:45d:2b7e:a20 with SMTP id ffacd0b85a97d-45eb3131940mr11345149f8f.14.1779550715411; Sat, 23 May 2026 08:38:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779550715; cv=none; d=google.com; s=arc-20240605; b=jMrykxeDM4xQTn+67EQslRvmAFP8tGLjZQz5yWDFPQ8m1FNubc8BNTEqBxa0taARKn cmX7GeRYwL6gog5Nj5/UR3GVVXdyuDNY2tWZU1RnWaySOrTUzj7djtB3isEywf8UyFmo 8d80+9DEmADhTucAqstVtDY0Rrn7W/sa5/19G1ZuqA/755XpVcI04WZtilsHKEdawaAD tq+5m3+N2uNKhypnL1ZlN4DbFZcv78gkL7eTuB6MeVbEYFMoQqS4HoaBk5r5HF6QLTSs 7ujIL9PSxw3YcLMLU2/COCdRh8pzTWLFLcxthsP9EKOMEMi2jM6UM/OObuQ5pa/uh7tj cWcw== 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=Qi2fouMWSLbxkrj5HzSdI6c3ma9D0ooQKOhln+dlgjU=; fh=Cvkve5G8fns8GvOAplP1n0GHzn8p4Rz2Z/deam205cU=; b=R63zzpPZmpWsbciUnkfgYJOHohP9gCZ+/HPlrGrIen23WrW41EMngOvkV++Qx+qEFT /442Mjej7rBAwkY4TDybWYgeBWfkr6s10fM76I+zWgMxB/JM8xfh4s9QEQXR+4zVGbO8 /LegwS+11QSQwvjjgSaqzwCVQSpXx2UczVZ+uusjEYqU/s+fbTtBlnZosm4lFPePBhqh /+KN2bD+sxmDzaW88wrqEsapn8pICbAOKPtA8ZnAxH4gMMYNG7/8J0lxyYZHV7FTrEUw //6H4UvaNTRldD7UpGT4NhQPkIpFkZIRBwkgHpbc/nvUywUR2klB1WtEa/djcCktIGlo GDAA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Vgkv7V+d; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10697.protonmail.ch (mail-10697.protonmail.ch. [79.135.106.97]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-45eb6d66441si104437f8f.6.2026.05.23.08.38.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 May 2026 08:38:35 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.97 as permitted sender) client-ip=79.135.106.97; Date: Sat, 23 May 2026 15:38:27 +0000 To: Isabel Foxen Duke From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] PQC: Lattice-based signatures Message-ID: <01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA=@proton.me> 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> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: cb4534161588415ef0b4634ecb6e44571929eef3 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------4788b17f7e7a625feb9e72c16be49ebedc3f679ca564f1dbd14a22a97ac1d903"; 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=Vgkv7V+d; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 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) --------4788b17f7e7a625feb9e72c16be49ebedc3f679ca564f1dbd14a22a97ac1d903 Content-Type: multipart/mixed;boundary=---------------------6f5c956aff593a3ea481e1ad901a12ae -----------------------6f5c956aff593a3ea481e1ad901a12ae Content-Type: multipart/alternative;boundary=---------------------4ac8235c3acd92ee146fbb87df3e3bbb -----------------------4ac8235c3acd92ee146fbb87df3e3bbb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 s= trategy of implementing different signatures at different times less practi= cal? In other words, does it still make sense to implement something like S= HRINCS before a lattice-based signature =E2=80=94 if we're ultimately hopin= g 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. O= r HAWK+BIP340. This would be strictly more secure than any of these individ= ual schemes in isolation. But also, a unified hybrid scheme would immediately be handicapped and unco= mpetitive after Q-day. It would inflate witness sizes by around 100 bytes p= er input, and complicate signer code for no good reason (except arguably to= mitigate statefulness risks). A hybrid scheme would create a=C2=A0technica= l debt we'd have to pay off later by migrating everyone to a pure PQC schem= e, 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-fork the ECC co= mponent of a hybrid-scheme out later without the need to migrate everyone. = Or we can bind individual schemes together into a hybrid scheme using featu= re flags (e.g. each pubkey starts with a flag byte, where bit 0 turns on BI= P340, 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 neces= sary when you can achieve comparable security by hiding keys for classical = and PQ schemes in two different P2MR script leaves, which was an OG definin= g use-case of P2MR. Or you can get almost exactly the same security, if you use both schemes in= the same script leaf:=C2=A0Anyone who wants the security of a hybrid BIP34= 0+SHRINCS scheme is free to implement it, and we could even write wallet st= andards for it.=C2=A0But to require everyone to use a hybrid scheme seems o= verkill to me, especially if we're talking about hash-based sigs which are = arguably more=C2=A0classically secure than ECC (modulo the risks of statefu= l schemes). regards, conduition On Saturday, May 23rd, 2026 at 6:49 AM, Isabel Foxen Duke wrote: > Hi Conduition, >=20 > Nevermind on the hybrid scheme question -- Jonas explained in this thread= that hybrid scheme is likely something that would happen on the wallet lev= el (not consensus/opcode level), so this is now clarified on my end - thank= s 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 wro= te: >=20 > > Hi Conduition, > >=20 > > So glad you enjoyed the interview! I'm thrilled Dan is speaking on quan= tum-issues more publicly these days :) > >=20 > > 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. > >=20 > >=20 > > 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? > >=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 wrote= : > >=20 > > > Hey Isabel, I watched the interview, very cool stuff. I loved seeing = Dan dodge your question about the mysterious "restrictions" google was unde= r (hello NSA). > > >=20 > > >=20 > > > Dan is right that lattice-based crypto offers the promise of algebrai= c structure, whereas hash-based crypto offers none. Having open research av= enues towards goals like threshold signatures is a great thing. Yet the pro= mise of the algebraic structure in lattices hasn't materialized into anythi= ng usable. At least, there are no schemes - yet - which tick the boxes we n= eed. At best we have hope for future developments. Lattice threshold and ke= y-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 signa= tures 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 b= e 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 a= s 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..." say= s Dan Boneh in new interview out this morning (1:11:00) > > > >=20 > > > > He primarily cites algebraic structure as allowing greater function= ality - and is concerned that features like threshold signature schemes wil= l 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 wro= te: > > > >=20 > > > > > Hey Nikita, thanks for broaching the idea. > > > > >=20 > > > > > I can't speak for Blockstream, but as to the spirit of your quest= ion - 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 conservativ= e. They rely on strictly weaker assumptions than what we already depend on = for other things. No other family of signatures can claim this property, an= d for something as inflexible-yet-sensitive as Bitcoin, conservativism is a= ppealing. > > > > >=20 > > > > > 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 fear 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 can i= mplement FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This simpl= icity also makes hash-based sigs easier to pitch during consensus debates: = It's harder to fear something once you understand it. > > > > >=20 > > > > > 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 state= fulness bullet, hash-based sigs can even be compact (and still fast). 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 verifiers remain= slim, quick, and secure. > > > > >=20 > > > > > 4. Future-proofing. Because of their conservatism, hash-based sig= s stand a better chance of remaining secure over a long time-frame, so it s= eems 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 a= s 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, beca= use 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 isoge= nies, or anything else for that matter. We need to know what's possible, an= d to educate the community about the options we have. I'm glad to see Block= stream funding this important work. I view hash-based sigs as the first epi= sode of a decades-long saga, but unfortunately we lack enough knowledge to = know what should come next. Maybe that is lattices? maybe something else. W= ith 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 lattice = crypto research, this would be it: > > > > >=20 > > > > > - [ ] compact keys and sigs. Ideally, less than a kilobyte witnes= s size total, but I'd be happy with at least a twofold improvement over wha= t 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 reason= why it should be impossible. > > > > > - [ ] integer-only arithmetic. Falcon keys and sigs are smaller t= han ML-DSA, but it comes at the expense of complex floating point arithmeti= c headaches. It'd be nice if we could do away with that. > > > > > - [ ] signature aggregation. This is a more general wish of any P= Q scheme, and if someone can do it, even with somewhat large sigs or poor p= erformance, it might make the whole scheme way more palatable, in tandem wi= th a CISA proposal. > > > > >=20 > > > > > Also see this relevant delvingbitcoin thread [1] for more sources= . > > > > >=20 > > > > > regards, > > > > > conduition > > > > >=20 > > > > > [0]: https://conduition.io/code/fast-slh-dsa-verification/ > > > > > [1]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-= 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 th= ink it=E2=80=99s an important issue that=E2=80=99s worth discussing. > > > > > > > > > > >=20 > > > > > > In particular, what I usually see is various competing proposal= s without a clear winner. > > > > > > > > > > >=20 > > > > > > So I=E2=80=99d like to bring everyone=E2=80=99s attention to th= is new post from Blockstream: > > > > > > https://blog.blockstream.com/schnorr-but-with-vectors-lattice-b= ased-signatures-explained/ > > > > > > > > > > >=20 > > > > > > This post is interesting because unlike a lot of PQC discussion= s, it actually includes a comparison table of various approaches, where lat= tices seem to come out ahead. > > > > > > > > > > >=20 > > > > > > This raises a few questions. > > > > > > > > > > >=20 > > > > > > Since lattices are not a new topic in cryptography, why has Blo= ckstream 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 lattic= es actually the current most likely candidate for a PQC implementation? > > > > > > If so, should the community effort be focused on lattices inste= ad 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 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. > > > > > > To view this discussion visit https://groups.google.com/d/msgid= /bitcoindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%40app.fastmail.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, s= end an email to bitcoindev+...@googlegroups.com. > > >=20 > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/ce98d232-4f6b-456b-ac3e-a1df12fa91ecn%40googlegroups.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/= 01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6I= XOsdqhszyDcz_F6AU0nzsYHh7_N70jkA%3D%40proton.me. -----------------------4ac8235c3acd92ee146fbb87df3e3bbb Content-Type: multipart/related;boundary=---------------------e70fa96480dfe5fa418cfda6b2c2ec83 -----------------------e70fa96480dfe5fa418cfda6b2c2ec83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Isabel,

=
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 impleme= nting different signatures at different times less practical? In other word= s, does it still make sense to implement something like SHRINCS before a la= ttice-based signature =E2=80=94 if we're ultimately hoping to implement a s= ingle 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, tec= hnically if we wanted to maximize security and reduce misuse, we could do i= t. 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 uncompet= itive after Q-day. It would inflate witness sizes by around 100 bytes per i= nput, and complicate signer code for no good reason (except arguably to mit= igate statefulness risks). A hybrid scheme would create a technical de= bt we'd have to pay off later by migrating everyone to a pure PQC scheme, m= aybe 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-fork the ECC c= omponent of a hybrid-scheme out later without the need to migrate everyone.= Or we can bind individual schemes together into a hybrid scheme using feat= ure flags (e.g. each pubkey starts with a flag byte, where bit 0 turns on B= IP340, 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 s= ecurity by hiding ke= ys for classical and PQ schemes in two different P2MR script leaves, which = was an OG defining use-case of P2MR.

Or you can get almost exactly the same security, if y= ou use both schemes in the same script leaf: Anyone who wants the sec= urity of a hybrid BIP340+SHRINCS scheme is free to implement it, and we cou= ld even write wallet standards for it. But to require everyone= to use a hybrid scheme seems overkill to me, especially if we're talking a= bout 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 <isabe= l.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,<= br>
So glad you enjoyed the interv= iew! I'm thrilled Dan is speaking on quantum-issues more publicly these= days :)

Noted about th= reshold signatures and other features potentially being only theoretical an= d not truly practical with Lattice based signatures. I will bring this up w= ith 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 is advocating for a hybrid scheme and I'm w= ondering if this would render the strategy of implementing different signat= ures at different times less practical? In other words, does it still make = sense to implement something like SHRINCS before a lattice-based sig= nature =E2=80=94 if we're ultimately hoping to implement a single hybrid sc= heme as Dan proposes here<= /a>?

thanks for all your hard work on this

Warmly,
Isabel Foxen Duke

On Thursday, Ma= y 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 question about the mysterious "restrictions" g= oogle was under (hello NSA).

Dan is right that lattice-based crypto offers the promise o= f algebraic structure, whereas hash-based crypto offers 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 mater= ialized 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 fro= m where they are now, but until proven otherwise we should make choices about consensus ba= sed on what we have, not what we hope we will have someday.

Also, in the interview Dan acted as thou= gh deploying hash-based signatures would preclude the deployment of lattice= crypto later. It doesn't. If we deploy a more cutting-edge cryptosy= stem 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 a= ssumptions (or implementations) are busted.

regards,
conduition
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)

He primar= ily cites algebraic structure as allowing greater functionality - and is co= ncerned that features like threshold signature schemes will be much harder = to implement with hash-based signatures.

-Isabel Foxen Duke

=
On Tuesda= y, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 conduition wrote:
Hey Nikita, thanks for broaching th= e 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]: https://delvingbitcoin.org/t/pos= t-quantum-hd-wallets-silent-payments-key-aggregation-and-threshold-signatur= es/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://b= log.blockstream.com/schnorr-but-with-vectors-lattice-based-signatures-expla= ined/
>

> 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/ms= gid/bitcoindev/ffa56d63-32c6-4fc3-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+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ce98d232-4f6b-456b-ac3= e-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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/01s-bZ= es3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqh= szyDcz_F6AU0nzsYHh7_N70jkA%3D%40proton.me.
-----------------------e70fa96480dfe5fa418cfda6b2c2ec83-- -----------------------4ac8235c3acd92ee146fbb87df3e3bbb-- -----------------------6f5c956aff593a3ea481e1ad901a12ae 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== -----------------------6f5c956aff593a3ea481e1ad901a12ae-- --------4788b17f7e7a625feb9e72c16be49ebedc3f679ca564f1dbd14a22a97ac1d903 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmoRyeQJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfTP8Sx2UN9piDxRpVUGcsUWIFqPfeIBJrSYDVa aFHvEhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAChiAD+P9+3YYEgn8dmOyO6 t1JcbIcIotOkvNfJJ4JL2fPteHMBAJBP98/GV0xNdxSThrZajSfPWL2Nd5rd lx2md0pZ+f8N =4C19 -----END PGP SIGNATURE----- --------4788b17f7e7a625feb9e72c16be49ebedc3f679ca564f1dbd14a22a97ac1d903--