From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 27 May 2026 13:29:35 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wSKsf-000222-RS for bitcoindev@gnusha.org; Wed, 27 May 2026 13:29:35 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-43b5c0e6ff6sf6462398fac.3 for ; Wed, 27 May 2026 13:29:33 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779913767; cv=pass; d=google.com; s=arc-20240605; b=dJjzGlWhWup9kEWufY6muRfgtVyICPb4FUQFm+VJUOXwcjuV9lyDibNtSp2C4VJebB NV7t60hevV2SrABG0SxIyq6iEmcDoieXNrRgnbQv/DAUphGD4mU+Vq4rqwzJhJhXSEb+ xgxyqX+6dFymKxQDC1FT7/ascCYS5CTucOgHjNCyLsVtdwTVbSX62ODnkF+dMAMyISnn Kl/w+6I2IeW/3l0kZTfBBuA4KOW3RmySnNoDmWbO36obRbo9Rcmhrz8FutYKXiMskSoe l9RasK7rUCeuKuCRFhLfHFG+j6KCKDwpqAXbyZuZM0S8Li1YTBEyo7zaUCAq+rtfkstp LSPA== 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=5S/J0gzfYQw2aIr6dlZiHHz50TgfzHgnSFx/jhv6YBk=; fh=gWNsgqqQy96hHl6h1sBIwfK1K9RzfOPxtcTLhRHBEGk=; b=DkVC7hlq19nsYfKfmyymBUksf5SXLPBMW6eXqmvjHez4AxVhS/NHyDWBrjHBY7IdNX v6YA13mAPlQCX+dTNeF/wOnXkiwImms36+Y2phxqhccfxL19Sx+9fAARO9zALkTXncTY 3FaGLv+FSaN6DjDt+4DgAMwLHbffMGv8NeWnT9LD6hYxOI+drG6bPESViSXWrsz8yM7G W6Dde/sSM6vleBOux4bY/A58MZLiIBOp8FZNX7KE21wSbqlzqdf/ynwv968dTMiwdPCp D6WirZeuE01LAtLKDdATeuoGtPc3/FaskmpkYEP+aFicwpYIlsWpYOxrkcB3BM5l7y2T XDGw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=QULDV8NR; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.29 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=1779913767; x=1780518567; 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=5S/J0gzfYQw2aIr6dlZiHHz50TgfzHgnSFx/jhv6YBk=; b=vJvx+0bruPZ0//EUzp0FG6u4nKg3lfiuMbU0VApKwbz757IiLKjOV56QJHXEpuqusP 3UJTZAWmmlsuSzDXS8M2/Ju61OK0oFyoxm0wQk3twNDU3pU5wi4KTJwR8yKBbQsgm78W MHkVeC9zzP4yijQTkTS4nABaPLG/9UHCKs1lDmylEgrEU/noL6bR9dOuu1LZoUrkeg92 /XDUqEzlPbbakgivh+mIIIClU9WiK0Cu3D9UE4aKj7h8KZVz7VsJ2gViOj0TexSCMtU3 WhoiO1IYOTFA1RpjlzA8Hml8Z3pNytYPCjrVomwh9gqllXmXEd5ED2wn4UZ/lD08GFDy 5hKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779913767; x=1780518567; 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=5S/J0gzfYQw2aIr6dlZiHHz50TgfzHgnSFx/jhv6YBk=; b=ahpIZ8ZqfGKYu5k8wGLMuZ0nAzqTO+fBSL3SezuBjs/CDqHhVBVBPjBIUMyNAfJbUy j7lINiEWUo+gf19I2wywWOfQ5ayUd8z9YoOf2Sdz+LTAVtjirbjDCK994Mpz3yMdJxbp selU+4Qh+bGc1tOBJ19cMuaz4QdfyuBCeYdjooVkk5jiD4GEDVttbX3+p1TAadr3xpSS 6lnnBuAR4Y2eT52DSBMmsCbgfkFfKmU++FEqSYjSVYsJ5dyAxUiCyNMcHINMSBy60CHp EUGuK4vrWyzuHDmAzW4c1z4x732qhuEf97JVchb5rgb7gLydjip3q6mNsptDFxce+Sx7 qt1A== X-Forwarded-Encrypted: i=2; AFNElJ8SjgCS4quDormDu2/AA8rOy2m0EznMI0HAAjn9UlbD5ocOmcTPNIdbXhf8NiDIRtiO2SDk+AAGU8LG@gnusha.org X-Gm-Message-State: AOJu0YxIFCH6CAFZNMBAMFM2/H8cNbQevMF1b34d4RP6E8fvkSYgojnE nkz0deBmYyPLUhnlYeQ45ZjNqrV8u9qOHFlcshj9Mi+Rghog9fRhzS5W X-Received: by 2002:a05:6870:d292:b0:43b:4cd4:8fd4 with SMTP id 586e51a60fabf-43b5ae66425mr14297793fac.32.1779913767111; Wed, 27 May 2026 13:29:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMON8xrbjggJAmgi09fzPMDAKsFm3fwQBxO93PVc6FWfbA==" Received: by 2002:a05:6871:cfcc:10b0:43b:4306:c32b with SMTP id 586e51a60fabf-43c51bccd89ls160142fac.2.-pod-prod-09-us; Wed, 27 May 2026 13:29:21 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8NTlJtfnqykMsM0L6WpRwBmhsvHnX851n3Uu8R5zbwvkp9pebOa2OnhpMI7gqkbQRuRyQDWS48fAIb@googlegroups.com X-Received: by 2002:a05:6808:c1cb:b0:479:ff59:dcec with SMTP id 5614622812f47-4854a4502bbmr15563202b6e.32.1779913761860; Wed, 27 May 2026 13:29:21 -0700 (PDT) Received: by 2002:a05:620a:1009:b0:910:3059:7be4 with SMTP id af79cd13be357-91506198e37ms85a; Wed, 27 May 2026 11:55:59 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+DNNpB1oSS92Tapv+RXVak9ulJMUFdkesS7qZM9rRwG9TBkpUVErUFJVQO8g9aLepawqoqJJfnqR9Z@googlegroups.com X-Received: by 2002:a05:6122:4891:b0:57d:801b:f8b8 with SMTP id 71dfb90a1353d-58662dace0amr14082701e0c.9.1779908159141; Wed, 27 May 2026 11:55:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779908159; cv=none; d=google.com; s=arc-20240605; b=OMEbENBfIkSusz77bZnOY6wPfTe1/Rujmig4Ut3yAUXXi8xzR1XJn8UUFal8mS2Aj1 E/+ImkZ299zz8qeERgJeNCEhz0V5/rgyf9bZW/ki5cFyTciRjcwSrTlXiEaMS1uKp/pu IW4bPSlThbITThMbbrMuYJ3OYkrgfVJG5rEtjPIphBV8PxnNyHiAtcrYq6MnQ1Y1+j4T 40EY3OKm8GVr1Z0rhT9SPs6PW659eZ2+y3taNZTISHzklFUysEQG6uaKgDgrJCEcZDrL Xn3KZvBllHLZrSMSMCN8uwP4QMIPBeP9ot9pbgAAB277BlJYRZlZqbeVMa7CqdveDibS lwLw== 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=RDp5PGb+eWUSs+4uJtVYLdROlbcFOJQQXXTEBsiLAW8=; fh=RuN1qbOKjQltksb6rw6n28LL5im77IkZAijoxdDd2Kc=; b=dEoHd3IoTWkgjr+/i2o37a3SYVJ3n7N65w7fB6i0AlxraVzmbbHxQ27rmJnzSgtr+q +FtyAVOR77XODW7BBDIGXt+lGW6zwihosadJalCd7lDdit/Pe5PHsoGUTn1Uy22Du4Bf 0nsvZGnIAdC+xzlGtLSzBXYUgidSe5xOa7/RIMHg5sTjEFGfYJD5gWJI5qUX3WNaPTkC qHaWSUinWVMnv8/neu6LoVqk7r9Jdj930MRrtBfsuDrGcqoKWstyayOpEhr0GY6JdMM+ ZFFvpgKeVTCSvLOP+9cTdWy/YeRnzhIxEz3ttev1fKJnX8UTt8zI3JsfSofFwBdUV0kr H59w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=QULDV8NR; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.29 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24429.protonmail.ch (mail-24429.protonmail.ch. [109.224.244.29]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-586f7b0dee9si589077e0c.3.2026.05.27.11.55.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 11:55:58 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.29 as permitted sender) client-ip=109.224.244.29; Date: Wed, 27 May 2026 18:55:54 +0000 To: Nagaev Boris From: "'conduition' via Bitcoin Development Mailing List" Cc: Jesse Posner , 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: 769043543248cfe016bd9034d70235025dab6cca MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------e3a81ebb22da4b634db7057ed121403a19dddd271f1e39bfcaceae2e8afb5053"; 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=QULDV8NR; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.29 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) --------e3a81ebb22da4b634db7057ed121403a19dddd271f1e39bfcaceae2e8afb5053 Content-Type: multipart/mixed;boundary=---------------------6ae82473ef88e1afcce9c31c9e6aef1f -----------------------6ae82473ef88e1afcce9c31c9e6aef1f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" That's a very neat idea Boris! However I'm pretty sure using a recoverable pubkey scheme will lead to loss= of some security for the EC scheme. For instance, Schnorr with pubkey reco= very precludes key-prefixing, which is necessary to avoid related-key attac= ks on BIP32. From BIP340: > Key prefixing Using the verification rule above directly makes Schnorr si= gnatures vulnerable to "related-key attacks" in which a third party can con= vert a signature (R, s) for public key P into a signature (R, s + a=E2=8B= =85hash(R || m)) for public key P + a=E2=8B=85G and the same message m, for= any given additive tweak a to the signing key. This would render signature= s insecure when keys are generated using BIP32's unhardened derivation and = other methods that rely on additive tweaks to existing keys such as Taproot= . Maybe ECDSA would be a viable option though, due to its non-linearity? But = then we give up the nice linear properties of Schnorr of course. Clever idea to reuse the EC nonce as the SHRINCS randomizer. For security, = the SHRINCS randomizer needs to be sampled from a PRF that ingests `SK.prf`= and the message to sign. A straightforward approach would be to simply reu= se the same PRF to generate a scalar nonce `r`, then use `xonly(r*G)` as th= e randomizer. Even if a CRQC can factor and find `r`, the randomizer `r*G` = is still randomly distributed among the secp256k1 curve, so no security is = lost there on the SHRINCS side I think. I will note the SHRINCS randomizer is actually being shrunk from 32 bytes t= o 16 bytes, to better align with SLH-DSA and XMSS standards, so reusing the= EC nonce only saves 16 bytes, not 32 bytes, but still pretty cool. regards, conduition On Wednesday, May 27th, 2026 at 2:17 AM, Nagaev Boris w= rote: > Note that if the hybrid scheme is implemented as a single > construction, we can optimize its total footprint. Let's assume we do > the SHRINCS + EC hybrid scheme. We can apply the following > optimizations to get the same footprint as SHRINCS itself, plus 32 > bytes. >=20 > 1. Use an EC signature with a recoverable public key. It could be > ECDSA or a Schnorr with a public key recovery option (not exactly > BIP-340). >=20 > Then we can put the EC pubkey into the hybrid key commitment - no > additional space! The verifier recovers the EC public key from the > signature and message, then checks that it matches the hybrid key > commitment. Then they just use the recovered EC pubkey as well as PQ > pubkey to recompute the hybrid public-key commitment. No need to store > EC pubkey separately. >=20 > 2. We can also save 32 bytes of the total 64 bytes in the signature if > we reuse the encoding of the EC signature's public nonce R to serve as > the randomization field R of SHRINCS. >=20 > So the total signature is just 32 bytes larger than a SHRINCS > signature and the pubkey is of the same size - EC pubkey does not add > to total pubkey size. >=20 > However if the same policy is expressed as two consecutive Bitcoin > Script opcodes, for example: >=20 > OP_CHECKSIGVERIFY OP_CHECKSHRINCSSIG >=20 > then the EC public key must appear in the revealed script/witness for > a Taproot script-path spend, and the two independent signatures cannot > share the public nonce/randomization field. That loses both > optimizations. >=20 > On Tue, May 26, 2026 at 4:41=E2=80=AFPM 'conduition' via Bitcoin Developm= ent > Mailing List wrote: > > > > We can also do that with script. > > > > OP_CHECKSIGVERIFY OP_CHECKDILITHIUMS= IG > > > > Note this is an opt-in construction. The main argument in favor of a un= ified hybrid scheme is it prevents people from using a PQC CHECKSIG operati= on independently - which is presumed risky because the new scheme or implem= entation could have bugs. > > > > However that same restriction used for safety will eventually become de= ad weight after enough time has passed, so we need a way to relax it later. > > > > regards, > > conduition > > > > On Tuesday, May 26th, 2026 at 3:29 PM, Jesse Posner wrote: > > > > I'm not suggesting this is the right approach, but I believe the ration= ale for a hybrid scheme would be to enable lattice signatures with their su= perior 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 Develo= pment 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 th= e strategy of implementing different signatures at different times less pra= ctical? In other words, does it still make sense to implement something lik= e SHRINCS before a lattice-based signature =E2=80=94 if we're ultimately ho= ping 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 o= n one-hand, yes, technically if we wanted to maximize security and reduce m= isuse, we could do it. For example, SHRINCS+BIP340 in a single unified sche= me. Or HAWK+BIP340. This would be strictly more secure than any of these in= dividual 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 by= tes per input, and complicate signer code for no good reason (except arguab= ly to mitigate statefulness risks). A hybrid scheme would create a technica= 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 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 any of this engineering complexity is = necessary when you can achieve comparable security by hiding keys for class= ical and PQ schemes in two different P2MR script leaves, which was an OG de= fining use-case of P2MR. > >> > >> Or you can get almost exactly the same security, if you use both schem= es in the same script leaf: Anyone 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. But to require everyone to use a hybrid scheme seems overki= ll to me, especially if we're talking about hash-based sigs which are argua= bly more classically secure than ECC (modulo the risks of stateful schemes)= . > >> > >> regards, > >> conduition > >> On Saturday, May 23rd, 2026 at 6:49 AM, Isabel Foxen Duke wrote: > >> > >> Hi Conduition, > >> > >> Nevermind on the hybrid scheme question -- Jonas explained in this thr= ead 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 - th= anks again for all your help! > >> > >> x Isabel > >> > >> > >> > >> On Friday, 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 qu= antum-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 he h= as 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 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? > >>> > >>> 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 wro= te: > >>>> > >>>> Hey Isabel, I watched the interview, very cool stuff. I loved seeing= Dan dodge your question about the mysterious "restrictions" google was und= er (hello NSA). > >>>> > >>>> Dan is right that lattice-based crypto offers the promise of algebra= ic structure, whereas hash-based crypto offers none. Having open research a= venues towards goals like threshold signatures is a great thing. Yet the pr= omise of the algebraic structure in lattices hasn't materialized into anyth= ing 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 k= ey-rerandomization schemes will likely improve from where they are now, but= until proven otherwise we should make choices about consensus based on wha= t we have, not what we hope we will have someday. > >>>> > >>>> Also, in the interview Dan acted as though deploying hash-based sign= atures would preclude the deployment of lattice crypto later. It doesn't. I= f 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 wrote: > >>>> > >>>> FWIW =E2=80=94 > >>>> > >>>> "I would actually like to push for lattice-based signatures..." says= Dan Boneh in new interview out this morning (1:11:00) > >>>> > >>>> He primarily cites algebraic structure as allowing greater functiona= lity - 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 wrot= e: > >>>>> > >>>>> 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.= They rely on strictly weaker assumptions than what we already depend on fo= r other things. No other family of signatures can claim this property, and = for something as inflexible-yet-sensitive as Bitcoin, conservativism is app= ealing. > >>>>> > >>>>> 2. Simplicity. Hash-based signatures are easier to grasp, simpler t= o prove secure, and easier to implement compared to almost anything else (e= ven simpler than ECC). We Bitcoiners tend to clutch our pearls in fear of t= rusting flawed assumptions... but in reality most vulnerabilities are not c= ryptographic in nature: Most are implementation failures. Hash-based sigs a= re harder (but not impossible) to screw up. An experienced engineer can imp= lement FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This simplic= ity 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 statefu= lness bullet, hash-based sigs can even be compact (and still fast). There r= emains some hope we might be able to use them as a daily driver if CRQCs ap= pear faster than anticipated. This efficiency comes at a price of course, b= ut that price is paid by the signer implementation while verifiers remain s= lim, 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 it see= ms more likely we could rely on them to fulfill a long-term fallback role. = We will likely someday need to deploy a new cryptosystem to replace ECC as = a daily driver if ECDLP is broken, whether classically or by a CRQC. When/i= f this 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 assumptions (or mo= re 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 Blockst= ream funding this important work. I view hash-based sigs as the first episo= de of a decades-long saga, but unfortunately we lack enough knowledge to kn= ow what should come next. Maybe that is lattices? maybe something else. Wit= h 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 be= en done [1], but AFAIK it is impossible without massively expanding the siz= es 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 w= hy it should be impossible. > >>>>> - [ ] integer-only arithmetic. Falcon keys and sigs are smaller tha= n ML-DSA, but it comes at the expense of complex floating point arithmetic = 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 poor per= formance, it might make the whole scheme way more palatable, in tandem with= a CISA proposal. > >>>>> > >>>>> Also see this relevant delvingbitcoin thread [1] for more sources. > >>>>> > >>>>> regards, > >>>>> conduition > >>>>> > >>>>> [0]: https://conduition.io/code/fast-slh-dsa-verification/ > >>>>> [1]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-pa= yments-key-aggregation-and-threshold-signatures/1854/ > >>>>> > >>>>> On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov wrote: > >>>>> > >>>>> > Dear list, > >>>>> > > >>>>> > >>>>> > I hate to contribute to the recent flood of PQC posts, but I thin= k 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= new post from Blockstream: > >>>>> > https://blog.blockstream.com/schnorr-but-with-vectors-lattice-bas= ed-signatures-explained/ > >>>>> > > >>>>> > >>>>> > This post is interesting because unlike a lot of PQC discussions,= it actually includes a comparison table of various approaches, where latti= ces seem to come out ahead. > >>>>> > > >>>>> > >>>>> > This raises a few questions. > >>>>> > > >>>>> > >>>>> > Since lattices are not a new topic in cryptography, why has Block= stream 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 Googl= e 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/b= itcoindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%40app.fastmail.com. > >>>>> > > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the Google G= roups "Bitcoin Development Mailing List" group. > >>>> To unsubscribe from this group and stop receiving emails from it, se= nd an email to bitcoindev+...@googlegroups.com. > >>>> > >>>> To view this discussion visit https://groups.google.com/d/msgid/bitc= oindev/42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.com. > >>>> > >>>> > >> -- > >> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group. > >> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+unsubscribe@googlegroups.com. > >> To view this discussion visit https://groups.google.com/d/msgid/bitcoi= ndev/ce98d232-4f6b-456b-ac3e-a1df12fa91ecn%40googlegroups.com. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group. > >> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+unsubscribe@googlegroups.com. > >> To view this discussion visit https://groups.google.com/d/msgid/bitcoi= ndev/01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZ= BIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA%3D%40proton.me. > > > > -- > > 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/CAL3ujSqcOhwga_edaYs3WfEFOLYS%2BBfMj1rG2%3D%3D%2BfydxPczd-g%40mail.gmai= l.com. > > > > > > -- > > 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/BEYEntuP_982nSOJVg_e4oIDBg0XQWyhLtMSSdB31ue1iAvMLtksMiuJS0wF-QJGKIKGuWe= SWCtOZnDxz__yQgTagnUSDfcwicYQ-QHjvko%3D%40proton.me. >=20 >=20 >=20 > -- > Best regards, > Boris Nagaev >=20 --=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/= i6AhbPWFLhGBLEbaWlHepHwVSRg0Goa0ZOvHRs4RjZQGhMTwpXfWbyo23xVEkC8TMGsrU7P7hmz= 9hXYx5nKLj_NhPXfib_-hLE1jnDYTm9w%3D%40proton.me. -----------------------6ae82473ef88e1afcce9c31c9e6aef1f 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== -----------------------6ae82473ef88e1afcce9c31c9e6aef1f-- --------e3a81ebb22da4b634db7057ed121403a19dddd271f1e39bfcaceae2e8afb5053 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmoXPiwJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmffQCqMUa6Y3e5ZUBtVRK5Ui479ZK3o3kvtR4Yu 2wI/6xYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAARpQD/VE9XtMIES1WlQNQC FFK5/zbUHVHUJvepkHXEKZu3eiUBAM7dSiiG2XPHCcBFrTDJklFvBgixkLWv Hj0OdQeSkvYN =95w+ -----END PGP SIGNATURE----- --------e3a81ebb22da4b634db7057ed121403a19dddd271f1e39bfcaceae2e8afb5053--