From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 28 May 2026 11:39:04 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wSfdH-0003cP-9F for bitcoindev@gnusha.org; Thu, 28 May 2026 11:39:04 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-69d77a8f5casf6245477eaf.3 for ; Thu, 28 May 2026 11:39:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779993537; cv=pass; d=google.com; s=arc-20240605; b=H/0vJxmBfiEYlPg4ldo9k8p2HANyk0l+t5Vj0e5dX+RS+NuWtLXJvx1K2NeJPABF3j 65jLJI70izrcxGIGf4FeiF9oovSxjOD7Aoi5nHg2EfMQ7d0AkZxPnvGqUHN6Yx0h3vZj p0YSlsPkZHrbPWWAwXs5JsBhqQYX8iXDBaiI7Kr0/BScflIqklQK3ti1zEehsSGHta9Y KPi7gM9hpDaXWGRyQhKxxvLWTPgMsm2daLxtLd0v5mDSglAF8qxBq25EUJa83OPj2f9b RppXWq2ysyL0FpzE+DyTs56aZIzHfhpDuyxGj6kYtNU2nXe6D4DTaJot5fS1Yiwi6Ma+ mbgA== 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=MPk/rATgKVodY359grj+yjTAu/vg+NCcYRZxa974UnQ=; fh=9A4x/PrEpE2sHwmMAJKryZhTHXgvb6tPOdBJiJ8DT7A=; b=PEMC5g4FiEGbJDhBOFUFhaBXOUVk4wYoynShQzn0NWis4DOlWTFHJqbx7YNnSCxKXV HNLY1UxVs3aZLC3YuLDXp3jDCJIoYzNzsDKB7ytlFVOY2Tn/XpfofZz1FCmI6+w+FxrK dfPDZM0bebv1BDnLqjop2Fs8TZ6WuZTJ7s84/xM22tnQh7YnkQUQPNB/nf/ss3idDzM4 Mj1dVg+k6hnkaaNSTfxDSMCwRrusce//sJKmRdFz9R8u7usDGS49f30hcJ2M8yIwUgwv wCJ6gFVNW5Dlvtg/njdGQEhUOZ+geupJqLSZk+TJ1wcONwvkeqf8+hStTL2rwbFyxm77 bxNA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=WUeFeL3N; 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=1779993537; x=1780598337; 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=MPk/rATgKVodY359grj+yjTAu/vg+NCcYRZxa974UnQ=; b=d7rYN4yjpZnHwhvWzIIYoPD4Pxo0XX00uXMoqASobOczWwh1hGrvxb+eRaqUZUVMsI f7I8pXVLPsZ+cTRs42g5Hd+yX24ipyJrE96gfo7kKVv5IsyxytS/deLK8eyM3Fp1zNDJ 54wXTaGxl0PX4a1ra+DLS1E4en2BtuuIVUfAQTi2rDF12Zz8e2RKfpM5Tg/TEujP4sNm dT7yYdo7o8AQqg/FYWTvCkRacB72/uEhDZGOjhUP1NJw9+rMmchnTmjVIClqMPpMo+o1 gFuJ3O55LDYsazsJnDAYjdcw6y5HaosyzbelMR3vQWf8x7WBS3Jjaz+nrEO7kcN5sneU GQSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779993537; x=1780598337; 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=MPk/rATgKVodY359grj+yjTAu/vg+NCcYRZxa974UnQ=; b=aA1905j7VYN7BpmqKD4DmIBD3rTmdOMXZ2f/Fk15FX7+3eL92XzrO1FhHiDcQldpxj E+TDXT3n2RQqlCcQuAJTwDiEzRBBpIibtrJNp1BwpjwdP7awaivI+0p1qgSMqMUXarHS d9ir3fA9/N0IgZLN6DoC94A7M/3Q3uvhbeGNN6L6cyF8rlmAR2liYCpghpWuNmmqp0gw IzlppBPvE6uKnuAdaHoez6aY/3qA00yAmPV0sixgkQ2xa0jnW4Q/VpTlmGgZziLc9sNo URn28KTrVcPyWeDY0GKd/juFDeQn85Z5r9Q3vlNvvJJYRhZNtUWZdwrg+sMkgzRxpbmg HVOg== X-Forwarded-Encrypted: i=2; AFNElJ9/UnVoMSofCFxnfGg+rrI99q7CoOBvAMJhKkZnCylCoU+lWHwAG+x7OzW2F0CsnlLpm9lTuG4E11bG@gnusha.org X-Gm-Message-State: AOJu0YxOKKf4FB2MtVaASUzO6fJCS8VGLxY5xqOfZYOlkCXh6KssNQ0Y QpWDOjeDAo7ITviyEWi9uTZ3RgRHI4xOstuXyHi3UyE86sPKXMEYoBlt X-Received: by 2002:a05:6820:1b0f:b0:69d:d78f:e3d0 with SMTP id 006d021491bc7-69dd78ff52amr5032770eaf.44.1779993536898; Thu, 28 May 2026 11:38:56 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMtXJqZFt0B1x9UbguKfm9DFPW/OduraM1zPazD+R53qQ==" Received: by 2002:a05:6820:135:b0:69d:6be8:68a with SMTP id 006d021491bc7-69df4461ad1ls607988eaf.2.-pod-prod-02-us; Thu, 28 May 2026 11:38:52 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8Su9UX1IdMVhUTdAEZ1h8l+ZhGa4WwlTJja+3r2/aywXGzcin8bfv9FETDAjdL/eUtri+X9kC96gd3@googlegroups.com X-Received: by 2002:a05:6808:67c6:b0:484:c3b5:9b0f with SMTP id 5614622812f47-485e3f0380bmr202612b6e.23.1779993531987; Thu, 28 May 2026 11:38:51 -0700 (PDT) Received: by 2002:a05:6808:c36b:b0:47c:339e:add7 with SMTP id 5614622812f47-485cdd1dfbcmsb6e; Thu, 28 May 2026 11:37:23 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+7bny2PHoHffW3oiaswdEfcZ3nibI+ht6yd0vUc0MRQ9YZlx5fJ+QipiKhkkuDCPIKexs6oPnf5EV7@googlegroups.com X-Received: by 2002:a17:90a:e18c:b0:36b:9835:cf96 with SMTP id 98e67ed59e1d1-36bba7b5531mr248290a91.2.1779993442091; Thu, 28 May 2026 11:37:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779993442; cv=none; d=google.com; s=arc-20240605; b=JL4rfwUi0yVUTbfAsiN3aQFOfs0LFMp4Rz2EUHOSTAH/OAEVKuLQr8zVnTAmUviDc6 +Hok+s5QmPLlCpz/rBnpBBsSFAHHqEUMBa0mXG7ytEMiVNwpM95nOHWB80hqsjDtPshZ 6yJoU4Cy6Bfux9nkcJhjM1ztEZ7CR0xOP/qNmjdCa3r3V1GVzMcVQfR315+FhrMvfG0M ernT6RRnTp3TWrvEXI+zR3eqj37Qslw4x8viLsyX0CJkXmnA8M03ltPP0D43UR7K5Ekf 7VXt968XSihW0L14CU5vd4VXR3xXS3C/hrxIfMxzvzyoJyfTfa4k8srFsT1Rn1TPkMrV 4nSw== 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=65A+qTC34lxDQVq3AiA9uzobVDNMFUyY41V+o//MUZ0=; fh=RuN1qbOKjQltksb6rw6n28LL5im77IkZAijoxdDd2Kc=; b=LqHnaVnZF0LADMs8lhlW+C6PTZZs0NtTauq2t8x3MzkwGgjxMHGg3SooNrsSSmxDq5 KHpsGtQIR78DxJ4vdSFpuXei8e0f2HA4RoTaHBkT5O7Ayw/Jm6bLZ7iN1Mny85hNhEJj GLcaGVFDeIcM9Qbd6M7uwb6oNjRbV/4aYQbujyMlRl0QA1fJWGr5jEmOPy4kPqvHBVOQ Ck1VQmPbewLqnhjt/y7o/9d9cxKmA73GzUpkYl8MdglWnuCgbLdJ/4+vu3/tac+89lSu p7rnGFMLG+7A1cgu+YU6I/vk7pon9Xyok3i9QcgP0U5nL7boMbKlkgoZVHNhi+cvRKts cLTw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=WUeFeL3N; 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 98e67ed59e1d1-36bbbdb2f15si349a91.2.2026.05.28.11.37.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 11:37:22 -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: Thu, 28 May 2026 18:37:10 +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: <3975ff59-50f0-4001-bcfb-f1f444873d22n@googlegroups.com> <01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA=@proton.me> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 4d49481bac4d8356fda0eee78e4b5540bef9f0e8 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------137bca80827f7c073e41358352a1418dfaf430b8b12ec9ac1c1e4aa45bd94cfd"; 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=WUeFeL3N; 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) --------137bca80827f7c073e41358352a1418dfaf430b8b12ec9ac1c1e4aa45bd94cfd Content-Type: multipart/mixed;boundary=---------------------d9c1235c65088c52774fd766d3e01ddd -----------------------d9c1235c65088c52774fd766d3e01ddd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" So you'd essentially be computing: e =3D H(R || hybrid_pk || m) P =3D e^{-1} * (s*G - R) i.e. the same as BIP340 Schnorr, but hashing a commitment to the pubkey ins= tead of the actual pubkey. By binding the signature to a specific `hybrid_pk` you prevent any related-= key attacks, including the fact that a valid signature from `P` cannot be a= pplied to other hybrid keys - even if they commit to the same `P`. Also note that this structure prevents a CRQC from factoring P until they s= ee the first signature. Seems reasonable. This would definitely break batch verification but we're = going to have to give that up anyway in a PQ-world. Does this break xonly arithmetic? Well if P is never put on-chain explicitl= y, we don't really need to care about shaving a byte off the public key, so= the question is really whether the nonce R will let us recompute the corre= ct public key if we elide its parity byte. And this is easy to engineer: Ju= st negate R (and its discrete log) before signing if R has odd parity. Then= you can encode x(R) in the signature and challenge hash, and the recovered= pubkey is always correct. This is a very clever idea. Seems like we'd shave about 48 bytes off the wi= tness compared to a naive two-opcode script. -16 bytes by removing the SHRINCS randomizer -32 bytes by removing the Schnorr pubkey Or about 48 bytes larger than bare SHRINCS: +32 bytes for the Schnorr `s` component +32 bytes for the Schnorr `R` component -16 bytes by removing the SHRINCS randomizer I'm still not fully convinced a hybrid scheme is ideal, since I expect the = majority of users will not use hybrid scripts anyway - they'll use hybrid P= 2MR trees with one leaf per sig algo - but this is at least worthy of consi= deration when weighing options. regards, conduition On Thursday, May 28th, 2026 at 1:49 AM, Nagaev Boris wr= ote: > On Wed, May 27, 2026 at 1:55=E2=80=AFPM conduition = wrote: > > > > 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 = recovery precludes key-prefixing, which is necessary to avoid related-key a= ttacks on BIP32. From BIP340: > > > > > Key prefixing Using the verification rule above directly makes Schnor= r signatures vulnerable to "related-key attacks" in which a third party can= convert 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 signat= ures insecure when keys are generated using BIP32's unhardened derivation a= nd other methods that rely on additive tweaks to existing keys such as Tapr= oot. >=20 > There is an approach that seems to preserve public-key recovery and > Schnorr linearity while avoiding the related-key issue. >=20 > Start from BIP340-style Schnorr, but prefix the challenge with the > final hybrid public key rather than with the raw EC public key P: >=20 > s*G =3D R + H(R || P || m)*P >=20 > becomes: >=20 > s*G =3D R + H(R || hybrid_pk || m)*P >=20 > Here hybrid_pk commits to both the PQ root and P. The verifier already > knows hybrid_pk from the pkscript (which is the source of truth), so > there is no circular dependency: compute the challenge, recover P from > the Schnorr equation, reconstruct the PQ root from the PQ signature, > and check that both recompute hybrid_pk. >=20 > The related-key attack no longer works because tweaking P changes > hybrid_pk, which changes the challenge. In particular, a signature for > one BIP32-derived key cannot be converted into a valid signature for a > neighboring key in the same derivation family. >=20 > For the PQ side, the message hash should also be bound to the final > hybrid key rather than only to the standalone PQ key. This prevents > extraction of a PQ signature from a hybrid signature and reusing it > independently, so EC and PQ signatures are strongly glued together. >=20 > This is a deviation from what is currently deployed, and it would need > a formal security argument. But the Schnorr signing equation remains > linear, so the EC side should remain compatible with > MuSig2/FROST-style aggregation. >=20 >=20 > > 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 securi= ty, 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= reuse the same PRF to generate a scalar nonce `r`, then use `xonly(r*G)` a= s the 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 byt= es to 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 wrote: > > > > > Note that if the hybrid scheme is implemented as a single > > > construction, we can optimize its total footprint. Let's assume we do > > > the SHRINCS + EC hybrid scheme. We can apply the following > > > optimizations to get the same footprint as SHRINCS itself, plus 32 > > > bytes. > > > > > > > > 1. Use an EC signature with a recoverable public key. It could be > > > ECDSA or a Schnorr with a public key recovery option (not exactly > > > BIP-340). > > > > > > > > Then we can put the EC pubkey into the hybrid key commitment - no > > > additional space! The verifier recovers the EC public key from the > > > signature and message, then checks that it matches the hybrid key > > > commitment. Then they just use the recovered EC pubkey as well as PQ > > > pubkey to recompute the hybrid public-key commitment. No need to stor= e > > > EC pubkey separately. > > > > > > > > 2. We can also save 32 bytes of the total 64 bytes in the signature i= f > > > we reuse the encoding of the EC signature's public nonce R to serve a= s > > > the randomization field R of SHRINCS. > > > > > > > > So the total signature is just 32 bytes larger than a SHRINCS > > > signature and the pubkey is of the same size - EC pubkey does not add > > > to total pubkey size. > > > > > > > > However if the same policy is expressed as two consecutive Bitcoin > > > Script opcodes, for example: > > > > > > > > OP_CHECKSIGVERIFY OP_CHECKSHRINC= SSIG > > > > > > > > then the EC public key must appear in the revealed script/witness for > > > a Taproot script-path spend, and the two independent signatures canno= t > > > share the public nonce/randomization field. That loses both > > > optimizations. > > > > > > > > On Tue, May 26, 2026 at 4:41=E2=80=AFPM 'conduition' via Bitcoin Deve= lopment > > > Mailing List wrote: > > > > > > > > We can also do that with script. > > > > > > > > OP_CHECKSIGVERIFY OP_CHECKDILITH= IUMSIG > > > > > > > > Note this is an opt-in construction. The main argument in favor of = a unified hybrid scheme is it prevents people from using a PQC CHECKSIG ope= ration independently - which is presumed risky because the new scheme or im= plementation could have bugs. > > > > > > > > However that same restriction used for safety will eventually becom= e dead weight after enough time has passed, so we need a way to relax it la= ter. > > > > > > > > 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 ra= tionale for a hybrid scheme would be to enable lattice signatures with thei= r superior functionality over hash-based schemes, while hedging against a b= reak in lattice security using BIP340. > > > > > > > > On Sat, May 23, 2026 at 8:44=E2=80=AFAM 'conduition' via Bitcoin De= velopment 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 rende= r 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 ultimatel= y 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. Li= ke on one-hand, yes, technically if we wanted to maximize security and redu= ce 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 thes= e individual schemes in isolation. > > > >> > > > >> But also, a unified hybrid scheme would immediately be handicapped= and uncompetitive after Q-day. It would inflate witness sizes by around 10= 0 bytes per input, and complicate signer code for no good reason (except ar= guably to mitigate statefulness risks). A hybrid scheme would create a tech= nical debt we'd have to pay off later by migrating everyone to a pure PQC s= cheme, maybe even requiring another soft-fork. That kind of tech-debt is ea= sier 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 t= he ECC component of a hybrid-scheme out later without the need to migrate e= veryone. Or we can bind individual schemes together into a hybrid scheme us= ing feature flags (e.g. each pubkey starts with a flag byte, where bit 0 tu= rns on BIP340, and bit 1 turns on SHRINCS, etc), and let users migrate on t= heir 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 c= lassical and PQ schemes in two different P2MR script leaves, which was an O= G defining use-case of P2MR. > > > >> > > > >> Or you can get almost exactly the same security, if you use both s= chemes in the same script leaf: Anyone who wants the security of a hybrid B= IP340+SHRINCS scheme is free to implement it, and we could even write walle= t standards for it. But to require everyone to use a hybrid scheme seems ov= erkill to me, especially if we're talking about hash-based sigs which are a= rguably more classically secure than ECC (modulo the risks of stateful sche= mes). > > > >> > > > >> 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= thread that hybrid scheme is likely something that would happen on the wal= let level (not consensus/opcode level), so this is now clarified on my end = - thanks again for all your help! > > > >> > > > >> x Isabel > > > >> > > > >> > > > >> > > > >> On Friday, May 22, 2026 at 8:25:41=E2=80=AFAM UTC-7 Isabel Foxen D= uke wrote: > > > >>> > > > >>> Hi Conduition, > > > >>> > > > >>> So glad you enjoyed the interview! I'm thrilled Dan is speaking o= n quantum-issues more publicly these days :) > > > >>> > > > >>> Noted about threshold signatures and other features potentially b= eing 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. > > > >>> > > > >>> 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 rend= er the strategy of implementing different signatures at different times les= s practical? In other words, does it still make sense to implement somethin= g like SHRINCS before a lattice-based signature =E2=80=94 if we're ultimate= ly hoping to implement a single hybrid scheme as Dan proposes here? > > > >>> > > > >>> thanks for all your hard work on this > > > >>> > > > >>> Warmly, > > > >>> Isabel Foxen Duke > > > >>> > > > >>> On Thursday, May 21, 2026 at 12:29:21=E2=80=AFPM UTC-7 conduition= wrote: > > > >>>> > > > >>>> Hey Isabel, I watched the interview, very cool stuff. I loved se= eing Dan dodge your question about the mysterious "restrictions" google was= under (hello NSA). > > > >>>> > > > >>>> Dan is right that lattice-based crypto offers the promise of alg= ebraic structure, whereas hash-based crypto offers none. Having open resear= ch avenues towards goals like threshold signatures is a great thing. Yet th= e promise of the algebraic structure in lattices hasn't materialized into a= nything usable. At least, there are no schemes - yet - which tick the boxes= we need. At best we have hope for future developments. Lattice threshold a= nd 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. > > > >>>> > > > >>>> Also, in the interview Dan acted as though deploying hash-based = signatures would preclude the deployment of lattice crypto later. It doesn'= t. If we deploy a more cutting-edge cryptosystem like HAWK or SQIsign, it w= ill 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 cry= pto 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 funct= ionality - and is concerned that features like threshold signature schemes = will be much harder to implement with hash-based signatures. > > > >>>> > > > >>>> -Isabel Foxen Duke > > > >>>> > > > >>>> On Tuesday, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 conduition = wrote: > > > >>>>> > > > >>>>> Hey Nikita, thanks for broaching the idea. > > > >>>>> > > > >>>>> I can't speak for Blockstream, but as to the spirit of your que= stion - Why people are looking at hash-based sigs more than lattices - I ca= n think of four major reasons: > > > >>>>> > > > >>>>> 1. Conservatism. Hash based signatures are incredibly conservat= ive. They rely on strictly weaker assumptions than what we already depend o= n for other things. No other family of signatures can claim this property, = and for something as inflexible-yet-sensitive as Bitcoin, conservativism is= appealing. > > > >>>>> > > > >>>>> 2. Simplicity. Hash-based signatures are easier to grasp, simpl= er to prove secure, and easier to implement compared to almost anything els= e (even simpler than ECC). We Bitcoiners tend to clutch our pearls in fear = of trusting flawed assumptions... but in reality most vulnerabilities are n= ot cryptographic in nature: Most are implementation failures. Hash-based si= gs are harder (but not impossible) to screw up. An experienced engineer can= implement FIPS-205 (SPHINCS) in a weekend, or less with AI tools. This sim= plicity 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 sta= tefulness bullet, hash-based sigs can even be compact (and still fast). The= re remains some hope we might be able to use them as a daily driver if CRQC= s appear faster than anticipated. This efficiency comes at a price of cours= e, but that price is paid by the signer implementation while verifiers rema= in slim, quick, and secure. > > > >>>>> > > > >>>>> 4. Future-proofing. Because of their conservatism, hash-based s= igs 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 ro= le. 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. Wh= en/if this happens, we'll be REALLY glad we added hash-based sigs first, be= cause then we'll have something to use if the novel scheme's assumptions (o= r more likely, implementation) are broken. > > > >>>>> > > > >>>>> This is not to say we shouldn't be researching lattices. Or iso= genies, 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 Blo= ckstream funding this important work. I view hash-based sigs as the first e= pisode of a decades-long saga, but unfortunately we lack enough knowledge t= o know what should come next. Maybe that is lattices? maybe something else.= With time, effort, and (hopefully) funding, we shall find out. > > > >>>>> > > > >>>>> If I had to pen a wishlist of stuff I'd like to see from lattic= e crypto research, this would be it: > > > >>>>> > > > >>>>> - [ ] compact keys and sigs. Ideally, less than a kilobyte witn= ess size total, but I'd be happy with at least a twofold improvement over w= hat stateless hash-based sigs can offer. > > > >>>>> - [ ] rerandomization e.g. BIP32 unhardened derivation. This ha= s been done [1], but AFAIK it is impossible without massively expanding the= sizes of keys and/or signatures. > > > >>>>> - [ ] a multisignature scheme, or a threshold protocol with a D= KG. Again, never seen this without massive keys and sigs, but I see no reas= on why it should be impossible. > > > >>>>> - [ ] integer-only arithmetic. Falcon keys and sigs are smaller= than ML-DSA, but it comes at the expense of complex floating point arithme= tic 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= performance, it might make the whole scheme way more palatable, in tandem = with a CISA proposal. > > > >>>>> > > > >>>>> Also see this relevant delvingbitcoin thread [1] for more sourc= es. > > > >>>>> > > > >>>>> regards, > > > >>>>> conduition > > > >>>>> > > > >>>>> [0]: https://conduition.io/code/fast-slh-dsa-verification/ > > > >>>>> [1]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silen= t-payments-key-aggregation-and-threshold-signatures/1854/ > > > >>>>> > > > >>>>> On Tuesday, May 19th, 2026 at 9:06 PM, Nikita Karetnikov wrote: > > > >>>>> > > > >>>>> > Dear list, > > > >>>>> > > > > >>>>> > > > >>>>> > I hate to contribute to the recent flood of PQC posts, but I = think it=E2=80=99s an important issue that=E2=80=99s worth discussing. > > > >>>>> > > > > >>>>> > > > >>>>> > In particular, what I usually see is various competing propos= als 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= -based-signatures-explained/ > > > >>>>> > > > > >>>>> > > > >>>>> > This post is interesting because unlike a lot of PQC discussi= ons, it actually includes a comparison table of various approaches, where l= attices seem to come out ahead. > > > >>>>> > > > > >>>>> > > > >>>>> > This raises a few questions. > > > >>>>> > > > > >>>>> > > > >>>>> > Since lattices are not a new topic in cryptography, why has B= lockstream 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 latt= ices actually the current most likely candidate for a PQC implementation? > > > >>>>> > If so, should the community effort be focused on lattices ins= tead 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 G= oogle 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/msg= id/bitcoindev/ffa56d63-32c6-4fc3-a150-4fe62ac2e00b%40app.fastmail.com. > > > >>>>> > > > > >>>> > > > >>>> -- > > > >>>> You received this message because you are subscribed to the Goog= le Groups "Bitcoin Development Mailing List" group. > > > >>>> To unsubscribe from this group and stop receiving emails from it= , send an email to bitcoindev+...@googlegroups.com. > > > >>>> > > > >>>> To view this discussion visit https://groups.google.com/d/msgid/= bitcoindev/42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.com. > > > >>>> > > > >>>> > > > >> -- > > > >> You received this message because you are subscribed to the Google= Groups "Bitcoin Development Mailing List" group. > > > >> To unsubscribe from this group and stop receiving emails from it, = send an email to bitcoindev+unsubscribe@googlegroups.com. > > > >> To view this discussion visit https://groups.google.com/d/msgid/bi= tcoindev/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 email to bitcoindev+unsubscribe@googlegroups.com. > > > >> To view this discussion visit https://groups.google.com/d/msgid/bi= tcoindev/01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJ= JCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA%3D%40proton.me. > > > > > > > > -- > > > > You received this message because you are subscribed to the Google = Groups "Bitcoin Development Mailing List" group. > > > > To unsubscribe from this group and stop receiving emails from it, s= end an email to bitcoindev+unsubscribe@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/CAL3ujSqcOhwga_edaYs3WfEFOLYS%2BBfMj1rG2%3D%3D%2BfydxPczd-g%40mail.= gmail.com. > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google = Groups "Bitcoin Development Mailing List" group. > > > > To unsubscribe from this group and stop receiving emails from it, s= end an email to bitcoindev+unsubscribe@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/BEYEntuP_982nSOJVg_e4oIDBg0XQWyhLtMSSdB31ue1iAvMLtksMiuJS0wF-QJGKIK= GuWeSWCtOZnDxz__yQgTagnUSDfcwicYQ-QHjvko%3D%40proton.me. > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Boris Nagaev > > > >=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/= gykF8zbGCmjgSr4Je8XH-al1Uge3Uk1t7L9mrNDmLcIeJM48s6ujL84IPctqF1C8t9doEtYscjj= GGeE2s-AqK9eAl7suRdsCPs2OBAgWurU%3D%40proton.me. -----------------------d9c1235c65088c52774fd766d3e01ddd 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== -----------------------d9c1235c65088c52774fd766d3e01ddd-- --------137bca80827f7c073e41358352a1418dfaf430b8b12ec9ac1c1e4aa45bd94cfd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmoYi0gJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmeEdWKG5l92m3LRWIQt/j6iIqHcxJIXTp7vsmaL nRcmfBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABh+QEAtvCnUxf3WRWnLkFK 1EeS9ymaS8arC7Y8A9bqwmcCVccBAJPgfHiH25NnV/LM1+1+zoMp4VHJP5ac 6j5q3nopv6IP =i08i -----END PGP SIGNATURE----- --------137bca80827f7c073e41358352a1418dfaf430b8b12ec9ac1c1e4aa45bd94cfd--