From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 28 May 2026 00:16:18 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wSUyX-0006eR-Dy for bitcoindev@gnusha.org; Thu, 28 May 2026 00:16:18 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-43c597de0c0sf593163fac.2 for ; Thu, 28 May 2026 00:16:16 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1779952570; cv=pass; d=google.com; s=arc-20240605; b=ggdbOorI284PXWgB6+u9JL4qt7tQL31kX4LBLWQEhT/64NtO1uN+shLul5vNMuIEFX 0yjJF8jNBW1cRpOy43euoArEcz/uh2cXW3XTfoj2M5L/VoREqr8QDOyetm9LXdhPID3s 9Y8gdq6rvi/86U38tXOV9FAa0zIlWsQZp9Cx+AKQetFZmBz7Hwdw2lDkgl23LoCXQexf rREef2HkU/NyAwB54nQqhUOr98SNS4+ryet4CYheIFSUZy09J7/+LbqMECU7n444PzbY psHFE9GAgGFYaSUhNd8kNFqAsGJ+1avqG5cII6IjeRjCLumzanBsG4E/J37GxRuthbAd mk4Q== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding:cc:to :subject:message-id:date:from:in-reply-to:references:mime-version :sender:dkim-signature:dkim-signature; bh=Z4KseY2o+DYqFiELI3yYIBKFAx6QM/4d9M6I4xO6qwY=; fh=1K6l5ACPJXUTkwje+OrJwychVQQIp1EejD2IjDeY2ms=; b=FQOMyAzONGAnvUcUv3pIIxj3g649MvzakdK9HLShGkdkv3wT22ac+gyIrVRgryB4M9 ksee/aOnD0qhdEfSKeY4Bn1Gg/aNCzkAoN7xzBhWFbAGu8Z0tp04ohexwLQIR+Snt2p+ rr/MarU+Bt93aBj3NbQws7d9O7zyPkERzlUf4MDdf36ovCNjZF4WoAeKkEpZjnLgwwt7 jM/bfFWS7zqd0/+oosl8obGXTwzmy0zVGxUg45e8taNP2iahEXkBDfb2m5ZceoWIRflu V75mRXqWVYk/wn2CHaaXraKMsYRUSfN9sgN/wKND8rlRym1BdwgQcZ1D3+Gnu/J5aPqH Jzfg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=oz57NCP9; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1230 as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1779952570; x=1780557370; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:sender :from:to:cc:subject:date:message-id:reply-to; bh=Z4KseY2o+DYqFiELI3yYIBKFAx6QM/4d9M6I4xO6qwY=; b=LDsLf6+/l43Gz+7RfZ4nasIHABlJUapw+sFWykj6uOA9SymAbTUs6GgK/XePBAuIF4 LqDNWJYiLR+XmgrkZtIoq4lOfJfWz5ZcE9P91wJKq5O/KlLgJ8aM9y1zn3twoP/lXHwp +Rhmg/OSPjz/KxjFKDKZ6n3Hb4p+6T/VEbj9ay9fj3AgVC/kQ55lrdLowf53Om8Iqp5Y ninVk01PM9NVibJ/3TQURosl5zh/d0UPFI+nfjjUwURoTD42me8LG9MOo+5PPQ29Jzh0 aLIhpuzjB5z2Nz++83Ytkb6fPzkfr9fQVF7+D9ir5ADBNIhyjs0EDidgmue3Y7zM5KkG izbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779952570; x=1780557370; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=Z4KseY2o+DYqFiELI3yYIBKFAx6QM/4d9M6I4xO6qwY=; b=bJl8q9k8x+XvyUqIQsBLzFVB+2L3Zly83wSDzdMro3bFxJRtB83PELK2L5WshE8wx6 gg61lADFodu5oitvEcoQ67sRJQj1L8PFjRiPYuvFjQPtKfZqXmqdqkdL4Dh0lsFomgKT jlt53Zmh/kteMVrveOqQnpMElWlHDlKGkM4SwXZeS4rf8qdODAYMB+C+ZnXMiMSKGiXN GH/7e43b/fVTWYU5Rq0kac3Lqy5+oGcw1nqZZfZQHbrg2m2XTT2SR5CJj7/KNxtsxara lPrGwJI1x4jjWH3dTYtnD7CmnvUiEW3HjIucKT4g9k0vHv0bHWwzIwUNH9M1DaMUJ2xV sFtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779952570; x=1780557370; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:x-gm-gg :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=Z4KseY2o+DYqFiELI3yYIBKFAx6QM/4d9M6I4xO6qwY=; b=n/FLgWik6AkY3pUOy6d0jT7+g43ySwgRp3M1tn2bIx/EQ6M4l1I3KKOr9L/J+AbO/r O3fj0So6A4oTFMwMMeNvoEErIEz0LFVl5Nn+X+mZlYySS75WYPmlIK0bqkUSNDmqIe8X a2ursyCKVdE5HydemGVW5jcFgQrwwvhl8G/zyq9ts93vW5xe4wc7fdL08WSqCpiffd53 yUHgx0rA2+5fBIWOSNMFWQa6WA8M/YbuFtvqP26zgNS/JBhiONnJZLnmGsqqyoNX5QsG j43E5CXMjcu3uJsN94GzY+EO7s2aotQEnpDKBcEqp+eeespT+BDhVnpwTnT3qJySzcoj 5tjA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ8tf3dznLnNrF16K/SM+1F99hkFx6M5bdKM/tIaeNBEbBH1Hibwcczmb1MGEfLlGUpqlfYY5bOZxh0i@gnusha.org X-Gm-Message-State: AOJu0YzSg+VymxWhzpBQjOQnTNvo3h93oRmy8azl2U4Cbp8MwJbTvrnN BYKwErU0iHsYlJDWY+VRGjS64ivxkblp/EfTHtRWW1Y06MxBRj/9rKn2 X-Received: by 2002:a05:6870:d390:b0:439:ae8f:e4d1 with SMTP id 586e51a60fabf-43b5aa1b73fmr16267561fac.4.1779952569821; Thu, 28 May 2026 00:16:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOLYEHfAsKi1XtSPcJYGR9OLY4Q1d30UlBb23EC6RcANg==" Received: by 2002:a05:6870:a084:b0:43b:92b9:f770 with SMTP id 586e51a60fabf-43c5143c862ls444367fac.0.-pod-prod-07-us; Thu, 28 May 2026 00:16:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ//BjQXaTSY3hMNjrW2knIejAC6qe0qhyzqWhra2V2gwkB/5+FGaYkH2REriQZ5MFVOiqjuhMytSPqD@googlegroups.com X-Received: by 2002:a05:6808:50aa:b0:479:fbe5:3a4a with SMTP id 5614622812f47-4854a296235mr18498954b6e.46.1779952563528; Thu, 28 May 2026 00:16:03 -0700 (PDT) Received: by 2002:a05:6808:a61a:10b0:479:f465:c131 with SMTP id 5614622812f47-485cdd8c516msb6e; Wed, 27 May 2026 22:49:23 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/V4UZI3ab1XScNOcfpqnBVtvEq5Q6ZIBTr56P3xZueLZbBy06E6+NSiFZJ+asZu1CAJ8EkzSh1o/uW@googlegroups.com X-Received: by 2002:a05:6a00:18a0:b0:839:9ad:ee31 with SMTP id d2e1a72fcca58-8415f0e4390mr26237242b3a.8.1779947362831; Wed, 27 May 2026 22:49:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1779947362; cv=pass; d=google.com; s=arc-20240605; b=gJiFn0221eTROYkJXYjfCt+Yi8LEl1w10+DPRvhyw4vjrOkyyPRHLKhfhcT0iEH2FV 9hGEog4cgyKluzcdNyqBCl4yE9tOgUMOGoC1cHV6bPzuaASVokrtuuLUvWoB/qTJvI5P zIv0wHqdd1WFxjxyjU3L3LYBG/NhfAgYKp/QByyS1chb4aMe4USPKzxnVyG3pSb2FqBP l4PDp1o7gviHVZdyZiIGx5EwStDAID8HCvEfRpg4V1B3649xVXl8t6SN/hYp3tlMsk/o fvpYR27r9C0qy89OwbfioNtrGi+uFd5pDA+5/ExsiRxyBRmkkp5uEAHkFqJyGksq5nNn qFyA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LoYDv7sppuQCkXCTmAW0dRi7s+O+5YgMfcOYCo1ogaY=; fh=GfAwD+RWe4TsMGGGDk8uY7zBiLXjiOYbNAwrUboOpFE=; b=YYmcwnhXhBB/w+oGahOmqGZQBm0l3RymHwQDlRfrvsN6szmRoxkRTsiVwrM3iz3i6+ FfhIEIgvywYOcK8IqCZG0+jVV4e91mgVX5PuDzEE87WYuaGXp34+fZh1/rnL5OlFM/xT hrc45n8zK/vRrdmwLyyemvBAiasMXk2XA93rTEKs/8tKTYCiiR6SUL8GMx5l/Llm+9mO OQwx4xtorkNoORkM1LzWRE+2D80PFcKKlZ4z3gXzfIB6hutkqAQgWNTvxRyoCiMIq9wJ oRlsOgGtugcY3Tz2L7pPa0ruvfvow0///bkRyI4ay99EU+yapgqBtd+3U8AF0UlXn3bq GKvQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=oz57NCP9; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1230 as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-dl1-x1230.google.com (mail-dl1-x1230.google.com. [2607:f8b0:4864:20::1230]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-841f7913541si23333b3a.0.2026.05.27.22.49.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2026 22:49:22 -0700 (PDT) Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1230 as permitted sender) client-ip=2607:f8b0:4864:20::1230; Received: by mail-dl1-x1230.google.com with SMTP id a92af1059eb24-1370417c01cso4645120c88.1 for ; Wed, 27 May 2026 22:49:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779947362; cv=none; d=google.com; s=arc-20240605; b=L57vdqzzzIBfqP8rTUxbekTucKW0zhlAjeE6UOVD7T9kT7q9LNP/4CzVAsZAXFxIHN cSJrhWCIZ8omqfM6H5PDb9UC3uB/Lg0qWMdWs7hCFBwn5uTAmoufz6tak8m98H+azzVa w77AYQYfoB9P61pyVGBXy3S5aoSnrFkCdNUnM9QZzONchwzQ8h1gTf0Pu/6i/Qq1RYsL pv3E+KgZ2Yg4UPzAyR60vKsHGjJW8cE5Xh0IiZbgO9E0WF3XREIJNstmNp+nbbOQpmLu kzvuD6y3lRPd0ZBX0I/Xn2U14xkLqk0VutxnAjoEU+FhnC683KCdNfR9N/huDn9T5BDa L5dA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LoYDv7sppuQCkXCTmAW0dRi7s+O+5YgMfcOYCo1ogaY=; fh=GfAwD+RWe4TsMGGGDk8uY7zBiLXjiOYbNAwrUboOpFE=; b=dYmvwUNkUkyn7rx5cocxv0kXHxol8gXDkG3bjqs1rH4V9EHA2eYXAsHSKEU62mdsFK DYn1JTxOgpIyuLqlko1trv2GNYkiFG6SMy0zlzufXH/HSa2GroTVUTGbfMSk4oepEGe/ KDFDEoRvGUpJlPiMj/7KlQvEZIWsuGmpVmY+sjsrFvbuiJjtSRLYw9cWUSXYVgbM4dBd hjlLsBSDXk9bQe0qBJd70h0FGZIQvyZZpQ/wIeKT4VdNHM585pvipEcwwi1cyDaxTYFa XZxSaYGFcqSjAu7K1ZhZm+vTmCpInTwX5KsxL9PatCaS/mgO1rhMahlPHmu+H1TnmHUd sF3A==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ+5GvWaTOXRJ5/z5h6eUoqoaae4ctnWFUlrPl0G07Svx0rN6+k2bWmvhiOCK34JYSrsI0RILeSX0ouI@googlegroups.com X-Gm-Gg: Acq92OGbSVEB8ubugotXTPTmO/DUGwVrfj4CXDqNjEPKDGtTRx+Jj3QTQBWdot5VcfU il+Uy/q5FnbbUBiI9grAUpS7vAfyY+ZXmGYXsWANZ1cyyh/NtoDs/YNk/aMv37PZXzgKrgPNjjq VOy0TMW5yJNm56PKg4H9W7v+n6Gk09mJMcjTeITupUKAfIIlDlde4HIlbOL+5bzTJzwbk7UJ6Cq JCwhn3lTiXJW/XZ1qYS+8PgboB3FwyiMu73g6qrVFXqI6Nw0Np/itBSS6wAECuQxNigd2oezG4c kOSRCdxmV/Hvu2pS X-Received: by 2002:a05:7300:430f:b0:304:5b0d:489b with SMTP id 5a478bee46e88-3045b0d4dd5mr11399772eec.27.1779947361899; Wed, 27 May 2026 22:49:21 -0700 (PDT) MIME-Version: 1.0 References: <42faeb16-5d01-41ba-a192-e05936b84248n@googlegroups.com> <673BCz5V_RyCwtNI8IxXeDdauWVmQm9MTvtZ97_2ADXzWZNT9bLJsTx1fli-PEb1-cNIi4nCCS-BIsDP1GBMaldfMSWGBHDKl7bFZWf7T6U=@proton.me> <3975ff59-50f0-4001-bcfb-f1f444873d22n@googlegroups.com> <01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJCZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA=@proton.me> In-Reply-To: From: Nagaev Boris Date: Thu, 28 May 2026 00:48:43 -0500 X-Gm-Features: AVHnY4I8gDNA2QCNC0PBQvJC1HDNhexT_Z0OyTC_CI9b7gIbsyHchiN6Pli4seU Message-ID: Subject: Re: [bitcoindev] PQC: Lattice-based signatures To: conduition Cc: Jesse Posner , Isabel Foxen Duke , Bitcoin Development Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bnagaev@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=oz57NCP9; arc=pass (i=1); spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::1230 as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) On Wed, May 27, 2026 at 1:55=E2=80=AFPM conduition w= rote: > > That's a very neat idea Boris! > > However I'm pretty sure using a recoverable pubkey scheme will lead to lo= ss of some security for the EC scheme. For instance, Schnorr with pubkey re= covery precludes key-prefixing, which is necessary to avoid related-key att= acks on BIP32. From BIP340: > > > Key prefixing Using the verification rule above directly makes Schnorr = signatures vulnerable to "related-key attacks" in which a third party can c= onvert 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= . There is an approach that seems to preserve public-key recovery and Schnorr linearity while avoiding the related-key issue. Start from BIP340-style Schnorr, but prefix the challenge with the final hybrid public key rather than with the raw EC public key P: s*G =3D R + H(R || P || m)*P becomes: s*G =3D R + H(R || hybrid_pk || m)*P 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. 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. 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. 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. > Maybe ECDSA would be a viable option though, due to its non-linearity? Bu= t 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.pr= f` and the message to sign. A straightforward approach would be to simply r= euse the same PRF to generate a scalar nonce `r`, then use `xonly(r*G)` as = 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 i= s lost there on the SHRINCS side I think. > > I will note the SHRINCS randomizer is actually being shrunk from 32 bytes= to 16 bytes, to better align with SLH-DSA and XMSS standards, so reusing t= he 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 store > > EC pubkey separately. > > > > > 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. > > > > > 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_CHECKSHRINCSS= IG > > > > > 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. > > > > > On Tue, May 26, 2026 at 4:41=E2=80=AFPM 'conduition' via Bitcoin Develo= pment > > Mailing List wrote: > > > > > > We can also do that with script. > > > > > > OP_CHECKSIGVERIFY OP_CHECKDILITHIU= MSIG > > > > > > 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 opera= tion independently - which is presumed risky because the new scheme or impl= ementation could have bugs. > > > > > > However that same restriction used for safety will eventually become = dead weight after enough time has passed, so we need a way to relax it late= r. > > > > > > 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 rati= onale for a hybrid scheme would be to enable lattice signatures with their = superior functionality over hash-based schemes, while hedging against a bre= ak in lattice security using BIP340. > > > > > > On Sat, May 23, 2026 at 8:44=E2=80=AFAM 'conduition' via Bitcoin Deve= lopment Mailing List wrote: > > >> > > >> Hi Isabel, > > >> > > >> I'm curious to get your thoughts on the following: it sounds like Da= n is advocating for a hybrid scheme and I'm wondering if this would render = the strategy of implementing different signatures at different times less p= ractical? In other words, does it still make sense to implement something l= ike SHRINCS before a lattice-based signature =E2=80=94 if we're ultimately = hoping to implement a single hybrid scheme as Dan proposes here? > > >> > > >> > > >> Argh, I'm a bit torn about the idea of a unified hybrid scheme. Like= on one-hand, yes, technically if we wanted to maximize security and reduce= misuse, we could do it. For example, SHRINCS+BIP340 in a single unified sc= heme. 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 a= nd uncompetitive after Q-day. It would inflate witness sizes by around 100 = bytes per input, and complicate signer code for no good reason (except argu= ably to mitigate statefulness risks). A hybrid scheme would create a techni= cal debt we'd have to pay off later by migrating everyone to a pure PQC sch= eme, maybe even requiring another soft-fork. That kind of tech-debt is easi= er to pay off in a web2 world, but not so easy on a blockchain. > > >> > > >> Perhaps there is a way to engineer it such that we can soft-fork the= ECC component of a hybrid-scheme out later without the need to migrate eve= ryone. Or we can bind individual schemes together into a hybrid scheme usin= g feature flags (e.g. each pubkey starts with a flag byte, where bit 0 turn= s on BIP340, and bit 1 turns on SHRINCS, etc), and let users migrate on the= ir own without a follow-up soft-fork. > > >> > > >> However, I'm not convinced that any of this engineering complexity i= s necessary when you can achieve comparable security by hiding keys for cla= ssical 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 you use both sch= emes in the same script leaf: Anyone who wants the security of a hybrid BIP= 340+SHRINCS scheme is free to implement it, and we could even write wallet = standards for it. But to require everyone to use a hybrid scheme seems over= kill to me, especially if we're talking about hash-based sigs which are arg= uably more classically secure than ECC (modulo the risks of stateful scheme= s). > > >> > > >> 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 t= hread that hybrid scheme is likely something that would happen on the walle= t 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 Duk= e wrote: > > >>> > > >>> Hi Conduition, > > >>> > > >>> So glad you enjoyed the interview! I'm thrilled Dan is speaking on = quantum-issues more publicly these days :) > > >>> > > >>> Noted about threshold signatures and other features potentially bei= ng only theoretical and not truly practical with Lattice based signatures. = I will bring this up with Dan and see if he has any comment here - or if he= has updates that may affect thinking on this. > > >>> > > >>> I'm curious to get your thoughts on the following: it sounds like D= an is advocating for a hybrid scheme and I'm wondering if this would render= the strategy of implementing different signatures at different times less = practical? In other words, does it still make sense to implement something = like SHRINCS before a lattice-based signature =E2=80=94 if we're ultimately= hoping to implement a single hybrid scheme as Dan proposes here? > > >>> > > >>> 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 w= rote: > > >>>> > > >>>> Hey Isabel, I watched the interview, very cool stuff. I loved seei= ng Dan dodge your question about the mysterious "restrictions" google was u= nder (hello NSA). > > >>>> > > >>>> Dan is right that lattice-based crypto offers the promise of algeb= raic 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 materialized into any= thing usable. At least, there are no schemes - yet - which tick the boxes w= e need. At best we have hope for future developments. Lattice threshold and= key-rerandomization schemes will likely improve from where they are now, b= ut until proven otherwise we should make choices about consensus based on w= hat we have, not what we hope we will have someday. > > >>>> > > >>>> Also, in the interview Dan acted as though deploying hash-based si= gnatures would preclude the deployment of lattice crypto later. It doesn't.= If we deploy a more cutting-edge cryptosystem like HAWK or SQIsign, it wil= l be once we have a suitably flexible and compact schemes ready to build at= op it, and when that happens we will still be glad to have hash-based crypt= o as a backstop in case the cutting-edge assumptions (or implementations) a= re 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..." sa= ys Dan Boneh in new interview out this morning (1:11:00) > > >>>> > > >>>> He primarily cites algebraic structure as allowing greater functio= nality - and is concerned that features like threshold signature schemes wi= ll be much harder to implement with hash-based signatures. > > >>>> > > >>>> -Isabel Foxen Duke > > >>>> > > >>>> On Tuesday, May 19, 2026 at 8:27:40=E2=80=AFPM UTC-7 conduition wr= ote: > > >>>>> > > >>>>> Hey Nikita, thanks for broaching the idea. > > >>>>> > > >>>>> I can't speak for Blockstream, but as to the spirit of your quest= ion - 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 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. > > >>>>> > > >>>>> 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. > > >>>>> > > >>>>> 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. > > >>>>> > > >>>>> 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. > > >>>>> > > >>>>> 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. > > >>>>> > > >>>>> 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 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. > > >>>>> > > >>>>> Also see this relevant delvingbitcoin thread [1] for more sources= . > > >>>>> > > >>>>> regards, > > >>>>> conduition > > >>>>> > > >>>>> [0]: https://conduition.io/code/fast-slh-dsa-verification/ > > >>>>> [1]: https://delvingbitcoin.org/t/post-quantum-hd-wallets-silent-= payments-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 th= ink it=E2=80=99s an important issue that=E2=80=99s worth discussing. > > >>>>> > > > >>>>> > > >>>>> > In particular, what I usually see is various competing proposal= s without a clear winner. > > >>>>> > > > >>>>> > > >>>>> > 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/ > > >>>>> > > > >>>>> > > >>>>> > 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. > > >>>>> > > > >>>>> > > >>>>> > This raises a few questions. > > >>>>> > > > >>>>> > > >>>>> > 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? > > >>>>> > > > >>>>> > > >>>>> > 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? > > >>>>> > > > >>>>> > > >>>>> > I=E2=80=99d like to hear your thoughts on the topic. > > >>>>> > > > >>>>> > > >>>>> > Thanks, > > >>>>> > Nikita > > >>>>> > > > >>>>> > > >>>>> > -- > > >>>>> > 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. > > >>>>> > > > >>>> > > >>>> -- > > >>>> You received this message because you are subscribed to the Google= Groups "Bitcoin Development Mailing List" group. > > >>>> To unsubscribe from this group and stop receiving emails from it, = send an email to bitcoindev+...@googlegroups.com. > > >>>> > > >>>> To view this discussion visit https://groups.google.com/d/msgid/bi= tcoindev/42faeb16-5d01-41ba-a192-e05936b84248n%40googlegroups.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+unsubscribe@googlegroups.com. > > >> To view this discussion visit https://groups.google.com/d/msgid/bitc= oindev/ce98d232-4f6b-456b-ac3e-a1df12fa91ecn%40googlegroups.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+unsubscribe@googlegroups.com. > > >> To view this discussion visit https://groups.google.com/d/msgid/bitc= oindev/01s-bZes3N5535LMO_sAysU1tdXtsRsaFt130av-xvYrDmZiopXZ7Y0mRkwQzKV0PJJC= ZZBIx6IXOsdqhszyDcz_F6AU0nzsYHh7_N70jkA%3D%40proton.me. > > > > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/CAL3ujSqcOhwga_edaYs3WfEFOLYS%2BBfMj1rG2%3D%3D%2BfydxPczd-g%40mail.gm= ail.com. > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/BEYEntuP_982nSOJVg_e4oIDBg0XQWyhLtMSSdB31ue1iAvMLtksMiuJS0wF-QJGKIKGu= WeSWCtOZnDxz__yQgTagnUSDfcwicYQ-QHjvko%3D%40proton.me. > > > > > > > > > > > -- > > Best regards, > > Boris Nagaev > > -- Best regards, Boris Nagaev --=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/= CAFC_Vt7gAUqzyLhjEJreo%3D26n7iAqo59kZFDiqXE8aAf2mff%2Bw%40mail.gmail.com.