From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 26 Mar 2026 15:53:20 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w5tZm-0003pE-Uq for bitcoindev@gnusha.org; Thu, 26 Mar 2026 15:53:20 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-67df5748f75sf5007985eaf.1 for ; Thu, 26 Mar 2026 15:53:18 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1774565593; cv=pass; d=google.com; s=arc-20240605; b=hv962uqJDEmfU4Awg/lwDyeRW27g7bhsakELlNTWdzF5oaRWPXR65hf/DWLrzfjucR 6nZfFmL4NsqbTf2EwcgPyyIrfz/SuMfHMXuC2NHZ4jFm5W/HdRocpwmrHt2kMPp1vALP mAzR3G4WSag7Lq/sDkis3JY9KCpVzZg1eB4QMOV6cSBVslhwHumPf8Vw5eKk6uZGhNvs JRy8UrwR25WZmxvnwACvijbf0+dS2/TJkEt/ITAI/0gBM+gBrrtjd/OdDuj/mLa4mnWv 25w8ucUFli0SezRhAPtbMTkNhB7u1QuZiOdruLpm0G56BrAlHk1MVahFJX8IZ9kuUNa8 mx0A== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=CtpHVEoAH+H9ZADQ4r0n4PmkLbLG+QDcY48GNGHM5Pk=; fh=ptDnPgCtqAH2m7ETz46teAF+MwOHs79TW5G+xPf85iw=; b=ELKyF/CP+k14/2VS3rFXDEP+6WgcFPF0QaFNaTS3LRHwiNyHjBV7cHfL7UE5S0Er4/ RzxPdgwPPsE/f4m2rb4J1pRiriI4mhFqiL+r9YPdbTtRgTRUE4In9vXGsRidSk8kRXPs uQIALSyZUhuDHjtlpE6F/UpbAa1KRltPHRGQcqnBzJ0J94KR3N3rcyybQLN5cjiWFY7l 5ZhKSdLltZNhiRiCCsWV8+Gb5Lzace+5S1DknlKj+eibNf3UG4EvK4eEjQJkzG/JhD1e at2YtDOVAm+HDYl/NuetasoigkOJNvwGEd9VVcVDvri6ysGHlsdNWuJiHPjIw5hYmPlr 4wlw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=YKJw++2W; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) smtp.mailfrom=eth3rs@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=1774565593; x=1775170393; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=CtpHVEoAH+H9ZADQ4r0n4PmkLbLG+QDcY48GNGHM5Pk=; b=I+YA+ySZs2QvdmcWnPvd0f0ANx+egV92fpuzAEZ1PWw4VRvQiQhruR89iS9Z2QzDrn +63JKr6KCEL4SBmyh/bOSvksvReu4+OqTxwjZ1o0TV3S8yray3P06IEk2S+Hi3QcoC0S kq4ofQrlzFNsNgqYIHL5XcEQ2tJI1D14dCSwW/fXEW5BRMRkbPN0CggOjpo9t2thF+67 K6xsLx21X3nhStvv6+lSIsq/V+geJVDicWVrQUiU59UvL2prMFropGipmIOw5uqDlmNw /Ga0EShK4EHCn5FQt+FXb0BKw9TaO5uFJziXJ+bHRraUefHmtVUAY+dSOcBQp470BLWw r3bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774565593; x=1775170393; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CtpHVEoAH+H9ZADQ4r0n4PmkLbLG+QDcY48GNGHM5Pk=; b=oIIjIg2+pUBWhy5vELnO8NuG1qCozrhiuhXgB+4yNK4tgIsb5yiTtdP9qpv8/PiGcA XZHZ4hOJ1/Tl7allKbtXk6N/eTaESpRpguiyo3jQc9OAj4Sl13sdsX0fz5WdbvWjBJ6J IqaqON9BT12P4/AgQgNuX9tUbCalEGQvSSGG1NW+TBDu73NT42cFIqKA9cDOS7hHn2E5 rH08nRfEZMjUeCLCrO+JLXfHh6VE/7q3Wu1gm9/0I2JX/MNyGwbqMnq37mMfhJdjvJRy j8qDUP+6g3Ab0Xzkp75ikhVyqMk6hpjay6aJFb9NwarnDxKLXxtWwk9Z0yR7Q0YXCmkS xmhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774565593; x=1775170393; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender: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=CtpHVEoAH+H9ZADQ4r0n4PmkLbLG+QDcY48GNGHM5Pk=; b=Y+X0vu8E+B6cLJUnt5kHq8S7bIHIdkyx6GMymr8hIWqW7nDEBL0KXMvxn9RlmXR7iu NPL7PM/zzMyHcLIsV9Ij6jATpQinx298ySoDpVHJPRLakTGpUjkP2wfVGTCdhodoPPh5 L0i3OX8LzkLUFPilmSWSLeFgD0M84BxZI5cewqtGABzlXTlVyH99SbDE63AB/4bdivm+ ynQNtA68AnlMEJq28pcvu8URc9Aj2o7k1Nw310/3lETlte/yS9CgP3plDqMZLIMhjJMz fIfk5Kc0YhDjJ8koVY47OWjYBQyxXPj7WXKrqWvRe0hxT45eDwlZAnBl/K/J6exBy/Xl Jagw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCVg3CisaM541rR190efL6nKFUCP4sOR8EOC4Wm1toydZkvA5wIizjLcVC8PBVuBmjBUu2wcrLj8q+WV@gnusha.org X-Gm-Message-State: AOJu0YxfHbYHwC+qgY3+3pfS7ogfb6pOEab1PsUcw0IZZ+lBP1MzeRPy 7IsT+RCvRaOeyZdwdzCf5HroNOxLTniQii0punw2MkOsXl/oykFv1OXZ X-Received: by 2002:a05:6820:162b:b0:67b:c4bd:2a8e with SMTP id 006d021491bc7-67e186ec844mr248380eaf.33.1774565592507; Thu, 26 Mar 2026 15:53:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIsV1gCthqF2UgWi+HDef9HVhShDg6H+GUZmWKo6O1fVw==" Received: by 2002:a05:6870:41cc:b0:417:5927:12e9 with SMTP id 586e51a60fabf-41cc8ff5a8bls675984fac.2.-pod-prod-01-us; Thu, 26 Mar 2026 15:53:06 -0700 (PDT) X-Received: by 2002:a05:6808:c175:b0:463:ab56:9ec5 with SMTP id 5614622812f47-46a8a3e70a3mr125311b6e.16.1774565586374; Thu, 26 Mar 2026 15:53:06 -0700 (PDT) Received: by 2002:a05:6808:1d32:b0:467:52e4:df4a with SMTP id 5614622812f47-46a85b1ef32msb6e; Thu, 26 Mar 2026 15:08:59 -0700 (PDT) X-Received: by 2002:a05:6808:4fcd:b0:468:6a2:8c1 with SMTP id 5614622812f47-46a8a390cc1mr63044b6e.11.1774562938531; Thu, 26 Mar 2026 15:08:58 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1774562938; cv=pass; d=google.com; s=arc-20240605; b=gFWCLE/rPdHVQJR7Qd67Gn1vBvieP2WR91Ak2iT6Mu1sID4S3YdvR3tGFwqSmajXfC 71VjjWrPSkJ3iAhJjKEjsMKxMACvkrVp23e0j2z+7cJa6GgL2Rjofk/c1vTxxAzP+6os VlXVRZ2RQKHM/ScozVmjZMknFgEfyTB+e3UYMCMuVVskwwFqMYOjd5P6BIZeGv8f+9DY XiaitmCK6Xtqb1tVIL2kVltSBUQZr3aI7KtCCT2pOB4ZcpZj9jhfzF/85R3LzeXZB6gQ +WYWeuKveZRGpnGP8uHHEY9SU1nJg13z9iQNMcL/i2tKnsat13pFLCiiyBV7cxsLUdBW mz0g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ILEQ9A9G42zS/XNedF66YrwsekeDQ4xV1Nr5wZdVRB8=; fh=QY5L8tL49i3fI06Bz5MX5IUm+Byyfp6LTijCthLNvdI=; b=PiIEkLtXzxjF5Gsy7eIYaKZv9wGdOEkQhmURwGzzGOlVUCAFhCIv9gYId3RMgam7me QX2JQrupe2PUq9lzcDXBNCnS6KTvg2YJ9My5473EhULnAyZhNtJG0L9TyqnKRgFQTFQM kYfYmM6a+3CUYkUcMvGl7r1KeZSBQzZf6PIxz9i35IIUDNO0uUpgsYvH0skbdXtdQPj8 UEgIaZnojmegR4shVB+/bqCZqaOdvuNjVYY7fP47DD53pGt5xJXlPRnfIlXQLLrlL5Q+ 2TgYKe9JfwNaSzaUrwjlY/xlUbmxkzkXH6AfVWQDXXIULnWZdLDmva4/7NznxqIiFmCO x5IA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=YKJw++2W; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com. [2607:f8b0:4864:20::62d]) by gmr-mx.google.com with ESMTPS id 5614622812f47-46a74f89778si101003b6e.4.2026.03.26.15.08.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Mar 2026 15:08:58 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) client-ip=2607:f8b0:4864:20::62d; Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-2aecc6b0861so9297185ad.2 for ; Thu, 26 Mar 2026 15:08:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774562938; cv=none; d=google.com; s=arc-20240605; b=RZBKVoKfNjUSYEMju1yHqhqQshJw62qia7Yp1uxpHR+rWuoEZWpOLAcRk84GNi6bAW /mube1CydFIdSPa84XcfxEmV0sqKt4+dveFsZfkolct2JlVJAg1/7cx9Lyqs4zfb5Eg8 7CwZsk3KNOKPV60EhU/M1jJfxiifvnU7VJt5/j9+IJ0OEaZ0N3Z43NNXpXvXabO+A+sk n0VSYMFYmRk/WVpJ/gDcVVyw9f8I+hSzEfMyeBTcdx5ETMObtsyxniQIWyRC2ViutY3Q Q/lctmR+yZK5uyhImVTVPyBe1VrL9rCkZIaGhbBDwOFdKjPwf85BN11njEaQ6lS35bHG k9tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ILEQ9A9G42zS/XNedF66YrwsekeDQ4xV1Nr5wZdVRB8=; fh=QY5L8tL49i3fI06Bz5MX5IUm+Byyfp6LTijCthLNvdI=; b=QLL1C00BAR2Ik128PqF5LQEIAef6F4noz9sUQy9QTquGoIJa1sywE+1RQYc95ivoml 0V830i29Ht02Enzdv7ZlFaqttYhDhGK2QgNHFdEW4YYhvMNq8FMbElCWYT8yfSlL5TnI YY4wg/O/Y0Rsn6e8B+5fgYQz4QE8mBMH/eVQ/MSWbt+C6uLrvm4Lb/b5sM7rUWGi0bxR sAYl/watAFLZ+x0m++Pomsv4kl/X4dEA8AcTo3UPO89iLayMDyDY75qe+qE7uG5Mxdh+ PF275RmITUrtijN2vE1ZZOO2RBDSWXm/s5kYhjvF2vifUVbW1nRLX+P4YLcljMYjMLpt oP+g==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: ATEYQzzaeWYil+fwSWc1J2Akh2JkIAnNNUhuHnB8CJlq9QMYSea8vMy/IWNAtRSHB4j i8aq6YIhEsEL5RlegeZBV9eNl47/dNMRY2MssFzrKYtVSWsMc5EtjLVeZm3IFU89SV2wxHX4JQK sT0umCOzeKld8HJg64K0ehiXv1JruGiHfwHlPPkTvEKFHKlWX3mSQU0Fltz3IkxBkJPlWEj8cGH FuKWSY5+3HpDWJ0ImZXlsBtoXj9Eb+lT80oF27TtdKIFLSdPhguRu+aRg2G2WOzuxJkEyaQS0XI B4CeuV6S7J1ZTDfYa4kn0MuAfn3ciXT1V5D3vLiRDqEryRcfcqhE1DpsdHtMNE1H59ABhXU+hkH AFH2N/c+lvNyyIMpvwq2M1gQ0J1+hOg23ys8xECyr6YDJa2TnwuZc0Yjsf5qbxV3ujBzWzp/vgW N7mKC31dNZhvXPFPWfMmgHjNdLvNBp/7Kocy1NAiM6nEk9r8GcWy6VPMNxpCqFZAg3PqrUtvDkp 2/SFIhM7w== X-Received: by 2002:a17:903:22d2:b0:2ae:fc60:2650 with SMTP id d9443c01a7336-2b0cdcef360mr2189685ad.39.1774562937560; Thu, 26 Mar 2026 15:08:57 -0700 (PDT) MIME-Version: 1.0 References: <7bUEt19esY1Q1IUZKjgVtFuvgIi5i6K0p4fHO3ud4Xh03AUKuCChAD8l8x_HmlWJreemZTL-KeJW3uw9Yz5f1TBWDmNTdL6pnN8aTn8VD18=@protonmail.com> In-Reply-To: <7bUEt19esY1Q1IUZKjgVtFuvgIi5i6K0p4fHO3ud4Xh03AUKuCChAD8l8x_HmlWJreemZTL-KeJW3uw9Yz5f1TBWDmNTdL6pnN8aTn8VD18=@protonmail.com> From: Ethan Heilman Date: Thu, 26 Mar 2026 18:08:20 -0400 X-Gm-Features: AQROBzCkel1c-EXORhL6OgUUr3Ll-FRaZQO7XetdqHWUkUW9c1nXCvN8QL0RNuQ Message-ID: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: moonsettler Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000008661aa064df4a176" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=YKJw++2W; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::62d as permitted sender) smtp.mailfrom=eth3rs@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 (/) --0000000000008661aa064df4a176 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Moonsettler, The algorithm agility approach does allow having an output constrained by ECC AND PQC in addition to ECC OR PQC. That said, the propose does that discuss this case because I am making the assumption that at time at which an output is spent, the wallet is aware if an ECC OR PQC spend is secure. The wallet then spends using only the secure method algorithm. Leaf1: ECC_PUBKEY, CHECKSIG_ECC Leaf2: PQC_PUBKEY, CHECKSIG_PQC This gets us a best of both worlds, since we can keep using ECC until it becomes secure. This reduces the cost of adopting PQC, because you only pay for it, once you need it. If you wanted to protect against cases where either: (a). short exposure attacks on ECC are practical and no one is aware of it or (b). short exposure attacks on PQC are practical and no one is aware of it, you could just have one leaf: Leaf1: ECC_PUBKEY, ECC_PUBKEY, CHECKSIG_ECC, PQC_PUBKEY, CHECKSIG_PQC I worry such an approach, as the default, might slow adoption by making transactions 3x larger prior to a CRQC being practical. If there is strong interest for this, then users can do it. Thanks, Ethan On Thu, Mar 26, 2026 at 1:28=E2=80=AFPM moonsettler wrote: > Hi Ethan and List, > > We should stop talking about cryptographic systems in exclusive terms! > > It's not that you have to either use ECC or PQC, the obvious best approac= h > for the migration period is signing an EC signature with a PQ signature > scheme as standard / best practice ^1. Even if a quantum computer finds t= he > private key to an exposed EC pubkey, to forge a new EC signature for a > different SIGHASH is still quantum hard. > > Benefits: > - Introduction of new cryptography ^2 provably does not degrade the > security of they bitcoin system if stacked with ECC. > - Optionality is key, EC only spends should be supported throughout the > migration era! ^3 > - Until ECC is trivially broken, the EC sig protects from a lot of > foot-guns especially regarding key reuse. > - Compact hash based signatures are uniquely suited for the migration era= . > ^4 > > > Eras for Bitcoin: > 1. Pre-quantum: ECC only, not possible to lock coins with PQ scripts. > 2. Migration period: EC/PQ hybrid signatures and covenants provide > adequate defense, small UTXOs may keep using EC only throughout. > 3. Post-quantum: EC is trivially broken and pointless to add as it does > not provide additional security. > > Seems obvious to me, that right now we should be preparing for the 2nd > era, not the 3rd, since there is a great deal of uncertainty about > when/if/how a CRQC will actually emerge. Safe and orderly quantum migrati= on > requires UTXOs to be locked up in long-range resistant addresses with spe= nd > time optionality to spend in a short-range protected way. > > > Notes: > ^1 Would work like CSFS, coupled with some covenant opcode like CTV/TH/TX > ECC can be obviated > ^2 Q-day may never come, but ECC can break in other ways. > ^3 We have no idea what the economics of bitcoin transactional amounts an= d > quantum computer hours will look like. Yet small value UTXOs would be > especially impacted by a forced migration to some NIST approved designed > for web monstrosity. > ^4 Compact hash based schemes like WOTS+C have serious key reuse / > statefulness issues and the mitigation is costly. > > BR, > moonsettler > > On Monday, February 9th, 2026 at 4:40 PM, Ethan Heilman > wrote: > > > Howdy list, I want to share my thoughts on increasing the security of > Bitcoin to long term threats such as quantum and classical breaks in > Bitcoin=E2=80=99s signature algorithms by adding algorithm agility mechan= isms to > Bitcoin. To quote RFC 7696: Guidelines for Cryptographic Algorithm Agilit= y: > > > > =E2=80=9CProtocol designers need to assume that advances in computing p= ower or > advances in cryptoanalytic techniques will eventually make any algorithm > obsolete. For this reason, protocols need mechanisms to migrate from one > algorithm suite to another over time. > > > > > > Algorithm agility is achieved when a protocol can easily migrate from > one algorithm suite to another more desirable one, over time.=E2=80=9D > > > > > > I propose introducing a very secure post-quantum signature algorithm to > be used alongside the current algorithms. This signature algorithm can be > very expensive in txn fees and block space since it is for emergency > migrations only. This enables Bitcoin holders to cheaply and easily creat= e > outputs that =E2=80=9Cfailsafe=E2=80=9D even against an unexpected break = in a signature > algorithm. > > > > Motivation > > =3D=3D=3D=3D > > > > Bitcoin should enable a person to self-custody coins for at least one > human lifetime, ~75 years. Someone should be able to bury an HD Seed in a > coffee can and then dig it up in 75 years and spend those coins. No store > of value can promise complete safety on long timescales, but the trust we > build by demonstrating that Bitcoin is serious about mitigating long-term > low probability risks. Trust and credibility is built when the risk we > defended against never happens. > > > > > > The main risk I will be considering here is the loss of the ability to > authenticate ownership of coins resulting from a break in a digital > signature algorithm used by Bitcoin. Such risks are extremely unlikely in > the short term (1 to 5 years), but become more likely on 5 to 75 year > timescales. Most of the focus in the wider cryptocurrency world has been = on > mitigating the quantum threat, but I take a less narrow view of the > problem. We should consider not just Quantum attacks on Bitcoin=E2=80=99s= signature > algorithms and also classical breaks that do not require a quantum > computer. One particular area of concern to me is an unexpected > breakthrough in Mathematics driven by AI approaches. > > To address these risks we propose the following design for protecting > holders even against an unexpected break in Bitcoin=E2=80=99s signature a= lgorithms > quantum or otherwise. > > Design > > =3D=3D=3D=3D > > > > Assume that Bitcoin supported two digital signature algorithms: DSA1 an= d > DSA2. Each signature scheme would have its own CHECKSIG opcode, > CHECKSIG_DSA1 and CHECKSIG_DSA2. > > > > Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a leaf > script for CHECKSIG_DSA2. > > > > Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1 > > Leaf2: DSA2_PUBKEY, CHECKSIG_DSA2 > > > > > > If DSA1 was broken, users could simply switch to spending the output > with DSA2 signatures by using leaf2. An attacker that could break DSA1, > wouldn=E2=80=99t be able to learn the public key for DSA1, and thus would= n=E2=80=99t be > able to spend DSA1, despite DSA1 being vulnerable. > > > > > > > > This approach makes the assumption that the user has not leaked their > public key to an attacker or reused their public keys. As a user wishing = to > hold Bitcoin in an output over long periods of time generate a fresh set = of > public keys for that output. > > > > > > Our approach does not defend against the case where DSA1 and DSA2 are > broken at the same time. For this reason, DSA1 and DSA2 should use > different cryptographic assumptions. Additionally DSA2 should use a > signature scheme that trades off efficiency for additional security and > robustness. This way, we can get the best of both worlds, DSA1 can be use= d > for everyday signatures and if DSA1 is broken, DSA2 can be used to migrat= e > to a new signature scheme, say DSA3. Even if DSA3, chosen in haste to > replace DSA1, is also found to be weak, holders are still protected. This > is because DSA2 is unbroken, allowing us to replace DSA3 with DSA4. > > > > DSA1 - Efficient, low cost to use, should support nice-to-have features > such as aggregation. > > > > DSA2 - Expensive, extreme levels of security, only used to transition t= o > new signature schemes. > > > > > > A person with an HD seed buried in a coffee can for 75 years is still > safe even if they don=E2=80=99t transition from DSA1 to DSA3 and since DS= A2 is > still safe. When they dig it up, they can use DSA2 to move the output to > DSA3+DSA2. > > > > > > > > Given this framework, let=E2=80=99s think about DSA1 and DSA2 with conc= rete > algorithms: > > > > - DSA1 is Schnorr, the currently supported Schnorr signature algorithmi= n > Bitcoin. > > > > - DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based > signature algorithm. Hash based signatures are the most likely secure lon= g > term. > > > > If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holders > could hedge against a classical or quantum attack against Schnorr, while > still using Schnorr. > > > > > > Our approach mitigates the main drawback of the size of SLH-DSA > signatures, their size. SLH-DSA signatures are 8 KB in size, while [0] > explores methods for reducing the size of these signatures to 3 KB, 3 KB = is > still huge. Because SLH-DSA signatures would not have any additional > discount, they would be very expensive in transaction fees, and only > economically worthwhile to migrate from Schnorr to a new signature scheme= . > In all other cases the addition of SLH-DSA would exist as unused leaf > scripts in the output, which increases the witness by 32 bytes. > > > > An additional benefit to this approach of using BIP 360 and SLH-DSA > would be to buy time for non-hash based PQ signature schemes to mature. W= e > are seeing rapid advances in research on post-quantum signature schemes a= nd > waiting a little long might buy us a lot. SLH-DSA would provide an > effective hedge against this risk, while delaying the decision of what PQ > signature scheme should replace Schnorr in the event of Schnorr's securit= y > being weakened. > > > > Q & A > > =3D=3D=3D=3D > > > > Q: Could these signatures be abused to store JPEGs on the blockchain? > > A: No because they would have no additional discount. This means they > would have no advantage for JPEGs over what is currently possible. > > > > Q: Why not use XMSS or Lamport signatures instead of SLH_DSA? > > A: I prefer SLH_DSA because it is likely to be well supported outside o= f > Bitcoin and Bitcoin can benefit from this ecosystem of support in the for= m > of HSMs, hardware acceleration and software liberties. That said, it is > reasonable to consider stateful hash based signature schemes like XMSS, > Winternitz, or Lamport signatures as the fallback signature, especially i= f > size becomes a concern. > > > > Q: What non-consensus critical changes would be needed to support this? > > A; We=E2=80=99d need to create new wallet standards to provide alternat= ives to > BIP32 xpubs. Wallet would have to write code to generate SLH-DSA keys and > create a script tree per signature alg. Wallets would also have to put in= to > place mechanisms to warn for and prevent public key reuse. > > > > Q: What consensus critical changes would be needed to support this? > > A: We=E2=80=99d need to merge something like BIP 360 and then a new CHE= CKSIG > opcode for SLH_DSA. > > > > > > Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot instea= d and > then disabling the taproot key spend path? > > A: Yes, however this would be confiscatory, since Taproot allows key > spend path only outputs. People holding key spend path-only Taproot outpu= ts > would have the coins in those outputs destroyed. BIP 360, in essence is > Taproot, without the key spend path. BIP 360 provides the same > functionality as disabling Taproot key spend paths, but rather than being > confiscatory, it is opt in. > > > > Q: Are you proposing this now because you think that the Bitcoin > signature algorithms are under threat? > > A: No, I am confident in the Bitcoin signature algorithms and I know of > no immediate threats. This effort is motivated by longtermism and thinkin= g > about how to enable Bitcoin to be safe on timescales of decades or > centuries. > > > > > > > > [0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for > Bitcoin (2025) https://eprint.iacr.org/2025/2203 > > > > > > I want to acknowledge conduition=E2=80=99s feedback and suggestions on = this > email, including the sentence about xpubs. The ideas above resulted from > conversations between myself, Hunter and Isabel. Similar ideas have been > suggested on the list before. I make no claims of originality, I am > organizing these ideas and my thoughts on them into a concrete design. Al= l > errors are my own. > > > > Thanks, > > Ethan > > > > -- > > 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/bitcoindev/CAEM%3Dy%2BWTqe8%3DuqChu2vN3= HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com > . > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAEM%3Dy%2BUi7h39jvoU_3jr_Dvyt4XaFhkXpmZaEGkmhPR0%3DooZHQ%40mail.gmail.com. --0000000000008661aa064df4a176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Moonsettler,

The algorithm agility approach does= allow having an output constrained by ECC AND PQC in addition to ECC OR PQ= C. That said, the propose does that discuss this case because I am making t= he assumption that at time at which an output is spent, the wallet is aware= if an ECC OR PQC spend is secure.=C2=A0The wallet then spends using only t= he secure method algorithm.

Leaf1: ECC_PUBKEY, CHECKSIG_ECC
Leaf2= : PQC_PUBKEY, CHECKSIG_PQC

This gets us a best of both worlds, since= we can keep using ECC until it becomes secure. This reduces the cost of ad= opting PQC, because you only pay for it, once you need it.

If you wa= nted to protect against cases where either: (a). short exposure attacks on = ECC are practical and no one is aware of it or (b).=C2=A0short exposure att= acks on PQC are practical and no one is aware of it, you could just have on= e leaf:

Leaf1:=C2=A0 ECC_PUBKEY,=C2=A0 ECC_PUBKEY, CHECKSIG_ECC,=C2=A0 PQC_PUBKEY, CHECKSIG_PQC

I worry such an approach, as the default, m= ight slow adoption by making transactions 3x larger prior to a CRQC being p= ractical. If there is strong interest for this, then users can do it.
Thanks,
Ethan




On Thu, Mar 26, 202= 6 at 1:28=E2=80=AFPM moonsettler <moonsettler@protonmail.com> wrote:
Hi Ethan and List,

We should stop talking about cryptographic systems in exclusive terms!

It's not that you have to either use ECC or PQC, the obvious best appro= ach for the migration period is signing an EC signature with a PQ signature= scheme as standard / best practice ^1. Even if a quantum computer finds th= e private key to an exposed EC pubkey, to forge a new EC signature for a di= fferent SIGHASH is still quantum hard.

Benefits:
- Introduction of new cryptography ^2 provably does not degrade the securit= y of they bitcoin system if stacked with ECC.
- Optionality is key, EC only spends should be supported throughout the mig= ration era! ^3
- Until ECC is trivially broken, the EC sig protects from a lot of foot-gun= s especially regarding key reuse.
- Compact hash based signatures are uniquely suited for the migration era. = ^4


Eras for Bitcoin:
1. Pre-quantum: ECC only, not possible to lock coins with PQ scripts.
2. Migration period: EC/PQ hybrid signatures and covenants provide adequate= defense, small UTXOs may keep using EC only throughout.
3. Post-quantum: EC is trivially broken and pointless to add as it does not= provide additional security.

Seems obvious to me, that right now we should be preparing for the 2nd era,= not the 3rd, since there is a great deal of uncertainty about when/if/how = a CRQC will actually emerge. Safe and orderly quantum migration requires UT= XOs to be locked up in long-range resistant addresses with spend time optio= nality to spend in a short-range protected way.


Notes:
^1 Would work like CSFS, coupled with some covenant opcode like CTV/TH/TX E= CC can be obviated
^2 Q-day may never come, but ECC can break in other ways.
^3 We have no idea what the economics of bitcoin transactional amounts and = quantum computer hours will look like. Yet small value UTXOs would be espec= ially impacted by a forced migration to some NIST approved designed for web= monstrosity.
^4 Compact hash based schemes like WOTS+C have serious key reuse / stateful= ness issues and the mitigation is costly.

BR,
moonsettler

On Monday, February 9th, 2026 at 4:40 PM, Ethan Heilman <eth3rs@gmail.com> wrote:

> Howdy list, I want to share my thoughts on increasing the security of = Bitcoin to long term threats such as quantum and classical breaks in Bitcoi= n=E2=80=99s signature algorithms by adding algorithm agility mechanisms to = Bitcoin. To quote RFC 7696: Guidelines for Cryptographic Algorithm Agility:=
>
> =E2=80=9CProtocol designers need to assume that advances in computing = power or advances in cryptoanalytic techniques will eventually make any alg= orithm obsolete. For this reason, protocols need mechanisms to migrate from= one algorithm suite to another over time.
>
>
> Algorithm agility is achieved when a protocol can easily migrate from = one algorithm suite to another more desirable one, over time.=E2=80=9D
>
>
> I propose introducing a very secure post-quantum signature algorithm t= o be used alongside the current algorithms. This signature algorithm can be= very expensive in txn fees and block space since it is for emergency migra= tions only. This enables Bitcoin holders to cheaply and easily create outpu= ts that =E2=80=9Cfailsafe=E2=80=9D even against an unexpected break in a si= gnature algorithm.
>
> Motivation
> =3D=3D=3D=3D
>
> Bitcoin should enable a person to self-custody coins for at least one = human lifetime, ~75 years. Someone should be able to bury an HD Seed in a c= offee can and then dig it up in 75 years and spend those coins. No store of= value can promise complete safety on long timescales, but the trust we bui= ld by demonstrating that Bitcoin is serious about mitigating long-term low = probability risks. Trust and credibility is built when the risk we defended= against never happens.
>
>
> The main risk I will be considering here is the loss of the ability to= authenticate ownership of coins resulting from a break in a digital signat= ure algorithm used by Bitcoin. Such risks are extremely unlikely in the sho= rt term (1 to 5 years), but become more likely on 5 to 75 year timescales. = Most of the focus in the wider cryptocurrency world has been on mitigating = the quantum threat, but I take a less narrow view of the problem. We should= consider not just Quantum attacks on Bitcoin=E2=80=99s signature algorithm= s and also classical breaks that do not require a quantum computer. One par= ticular area of concern to me is an unexpected breakthrough in Mathematics = driven by AI approaches.
> To address these risks we propose the following design for protecting = holders even against an unexpected break in Bitcoin=E2=80=99s signature alg= orithms quantum or otherwise.
> Design
> =3D=3D=3D=3D
>
> Assume that Bitcoin supported two digital signature algorithms: DSA1 a= nd DSA2. Each signature scheme would have its own CHECKSIG opcode, CHECKSIG= _DSA1 and CHECKSIG_DSA2.
>
> Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a lea= f script for CHECKSIG_DSA2.
>
> Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1
> Leaf2: DSA2_PUBKEY, CHECKSIG_DSA2
>
>
> If DSA1 was broken, users could simply switch to spending the output w= ith DSA2 signatures by using leaf2. An attacker that could break DSA1, woul= dn=E2=80=99t be able to learn the public key for DSA1, and thus wouldn=E2= =80=99t be able to spend DSA1, despite DSA1 being vulnerable.
>
>
>
> This approach makes the assumption that the user has not leaked their = public key to an attacker or reused their public keys. As a user wishing to= hold Bitcoin in an output over long periods of time generate a fresh set o= f public keys for that output.
>
>
> Our approach does not defend against the case where DSA1 and DSA2 are = broken at the same time. For this reason, DSA1 and DSA2 should use differen= t cryptographic assumptions. Additionally DSA2 should use a signature schem= e that trades off efficiency for additional security and robustness. This w= ay, we can get the best of both worlds, DSA1 can be used for everyday signa= tures and if DSA1 is broken, DSA2 can be used to migrate to a new signature= scheme, say DSA3. Even if DSA3, chosen in haste to replace DSA1, is also f= ound to be weak, holders are still protected. This is because DSA2 is unbro= ken, allowing us to replace DSA3 with DSA4.
>
> DSA1 - Efficient, low cost to use, should support nice-to-have feature= s such as aggregation.
>
> DSA2 - Expensive, extreme levels of security, only used to transition = to new signature schemes.
>
>
> A person with an HD seed buried in a coffee can for 75 years is still = safe even if they don=E2=80=99t transition from DSA1 to DSA3 and since DSA2= is still safe. When they dig it up, they can use DSA2 to move the output t= o DSA3+DSA2.
>
>
>
> Given this framework, let=E2=80=99s think about DSA1 and DSA2 with con= crete algorithms:
>
> - DSA1 is Schnorr, the currently supported Schnorr signature algorithm= in Bitcoin.
>
> - DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash base= d signature algorithm. Hash based signatures are the most likely secure lon= g term.
>
> If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holder= s could hedge against a classical or quantum attack against Schnorr, while = still using Schnorr.
>
>
> Our approach mitigates the main drawback of the size of SLH-DSA signat= ures, their size. SLH-DSA signatures are 8 KB in size, while [0] explores m= ethods for reducing the size of these signatures to 3 KB, 3 KB is still hug= e. Because SLH-DSA signatures would not have any additional discount, they = would be very expensive in transaction fees, and only economically worthwhi= le to migrate from Schnorr to a new signature scheme. In all other cases th= e addition of SLH-DSA would exist as unused leaf scripts in the output, whi= ch increases the witness by 32 bytes.
>
> An additional benefit to this approach of using BIP 360 and SLH-DSA wo= uld be to buy time for non-hash based PQ signature schemes to mature. We ar= e seeing rapid advances in research on post-quantum signature schemes and w= aiting a little long might buy us a lot. SLH-DSA would provide an effective= hedge against this risk, while delaying the decision of what PQ signature = scheme should replace Schnorr in the event of Schnorr's security being = weakened.
>
> Q & A
> =3D=3D=3D=3D
>
> Q: Could these signatures be abused to store JPEGs on the blockchain?<= br> > A: No because they would have no additional discount. This means they = would have no advantage for JPEGs over what is currently possible.
>
> Q: Why not use XMSS or Lamport signatures instead of SLH_DSA?
> A: I prefer SLH_DSA because it is likely to be well supported outside = of Bitcoin and Bitcoin can benefit from this ecosystem of support in the fo= rm of HSMs, hardware acceleration and software liberties. That said, it is = reasonable to consider stateful hash based signature schemes like XMSS, Win= ternitz, or Lamport signatures as the fallback signature, especially if siz= e becomes a concern.
>
> Q: What non-consensus critical changes would be needed to support this= ?
> A; We=E2=80=99d need to create new wallet standards to provide alterna= tives to BIP32 xpubs. Wallet would have to write code to generate SLH-DSA k= eys and create a script tree per signature alg. Wallets would also have to = put into place mechanisms to warn for and prevent public key reuse.
>
> Q: What consensus critical changes would be needed to support this? > A: We=E2=80=99d need to merge something like BIP 360 and then a new CH= ECKSIG opcode for SLH_DSA.
>
>
> Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot inste= ad and then disabling the taproot key spend path?
> A: Yes, however this would be confiscatory, since Taproot allows key s= pend path only outputs. People holding key spend path-only Taproot outputs = would have the coins in those outputs destroyed. BIP 360, in essence is Tap= root, without the key spend path. BIP 360 provides the same functionality a= s disabling Taproot key spend paths, but rather than being confiscatory, it= is opt in.
>
> Q: Are you proposing this now because you think that the Bitcoin signa= ture algorithms are under threat?
> A: No, I am confident in the Bitcoin signature algorithms and I know o= f no immediate threats. This effort is motivated by longtermism and thinkin= g about how to enable Bitcoin to be safe on timescales of decades or centur= ies.
>
>
>
> [0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bit= coin (2025) https://eprint.iacr.org/2025/2203
>
>
> I want to acknowledge conduition=E2=80=99s feedback and suggestions on= this email, including the sentence about xpubs. The ideas above resulted f= rom conversations between myself, Hunter and Isabel. Similar ideas have bee= n suggested on the list before. I make no claims of originality, I am organ= izing these ideas and my thoughts on them into a concrete design. All error= s are my own.
>
> Thanks,
> Ethan
>
> --
> 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.go= ogle.com/d/msgid/bitcoindev/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0= AwyOkaR%3Dz0Cw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.co= m/d/msgid/bitcoindev/CAEM%3Dy%2BUi7h39jvoU_3jr_Dvyt4XaFhkXpmZaEGkmhPR0%3Doo= ZHQ%40mail.gmail.com.
--0000000000008661aa064df4a176--