From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 26 Mar 2026 11:07:40 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w5p7L-00083V-9Y for bitcoindev@gnusha.org; Thu, 26 Mar 2026 11:07:40 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-417120d5378sf2053596fac.1 for ; Thu, 26 Mar 2026 11:07:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1774548453; cv=pass; d=google.com; s=arc-20240605; b=MxTQS+hpThQsWvcz1cDIhteCuUVZ4q/pg9c++TzFm7ed27VjXg2MIV01bodxDYWrrc Hwm6w8q/0aixjBq9UZLQdUxZuGie3VVC5Qzb2ZpqkI6N2XCyuMRh+dzUfCnH/AvO9Z3P n+ouV9Yua15DWwa3JgHGQXEfQsy7fmlQqZQE5dkaLEd1iZNKqDOFXrabAxmZp10jh4yi TK4jskcwpjTnRYF9QwMGfxyilrXjpgoKFkxmSuqWKwwab8lzz+9LPc2PFtx+7ogtn7Ck iZXwgbnSxHUTwaZ9eg38I3t14CzFdn3rqOJAFwxvikJQA5mYR7bEFD2ckN1bXYWRI9cd L0nA== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=YpqLKLR7XYAwo8WvpjDnzD4zfFw2Bep9iWxBHPJs1Dg=; fh=WJjgu64rBYNBkGMH7K1s5D1g/bYNsiXHwCpYYp4zMA4=; b=lAS4iEQAQ39lrJWA0DGfQNJ+DpW1p/m8xVTV2EYZQC/D7nD2bFrS33tGakUprT7gLE Sg7bjMn+HC4Fg8IGSbmQdbQy4fS6g+0Q+VV13MQbcqjNV8C3/TtbCs1x12xE66hqczY1 2mmOX49uNhZrepRp2ocOx3MXh7NlhBQ8/9sZqTB50x9CW5D+CqkUKOv40gGEFsMJuDB9 FlRIt5cZLiOOeJr0OwFW5mz/79ad7F+7dHEPRNyEwSud+hz8ZXNvx5xKJMzBcRe6OMOk c2oFqMxjMsfCtn6AQaeAUBtm1TEyv8Oc+MqTz5dqyrG2mfMRnODvYO3vMZ9ChPaqO2TX 6VGA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=EvM2lXG8; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1774548453; x=1775153253; 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 :content-transfer-encoding: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=YpqLKLR7XYAwo8WvpjDnzD4zfFw2Bep9iWxBHPJs1Dg=; b=PLGcA1DuHHsiKGHoeXYSjdCAdrQYuVyKa2yqgtc5MGxzwbUsVRv2vy3B39aFVtgh3c qmA0zgGABZCpGY59gnnDuPx86bnuOIIkvpYjp+MsDdvTiHgBM6OlsVt0lIe4cfbrKHo0 j9VEATPNcTpZR6zMUhD+HyrQAWgjIuYemilSJzrXjew1eFzBTtsHAKn+jWtiEOahIMi7 /ntU/+okLob6j57mAQQTDYxy8GfAqNf/m9+44Tuq8hkf24iRu+dAz+Y06eokppbHX39x oU/pUHPVFGeec5i3z0W8pUzf/1R5soI87SgvA4UlBqKfpOAxCA/EmSLU2eUUrELiwVlQ 00Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774548453; x=1775153253; 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 :content-transfer-encoding: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=YpqLKLR7XYAwo8WvpjDnzD4zfFw2Bep9iWxBHPJs1Dg=; b=B1igU6gylGP1Tnza7JqbSUdEHTEKUDXEELx+i9Z+6w0jcfTJpcjJX4rs7BAgjK6bfv idEHeCKX1/GEGXbBLd7WZnc1OJHufEi+FBlvQBWXedFjKP3KVZyi8jgQKoyjpdmpIQGN WwoSbxrL52R2zBJDKWcjuwI2V9E7kAg3EjdzkRDj0/M8fdXPK141OVnjnEP3eNIfRk6s G8Q7FxjjTNB8J9U1JDRlWfDCGwASqJbOCsghDcXQZwpXQYQvfFmoyA5+V2GQivzsRK5A rH8miMYAOci+24+EMQCLu9xmQM6MLAc0aLwPz4FAO5HWX5aZYD2uspZYR88ZoBkw2lzb aVmw== X-Forwarded-Encrypted: i=2; AJvYcCVcVJyHAuK0IfnRk8r+4oIkFlAvknRngEHi2V5IrtNqx0cp+YCUacd+m8NP0MMyRP1xlTVJ2Qsd5wvn@gnusha.org X-Gm-Message-State: AOJu0YzEsM1fT8+BFaqkzW775W07LDN3LZO0kibi9WKq1cbDCYhYpBC6 nHfmFvqJJyydncdPdtlXPUSToF2vzt+BAdqwZyeMQN+sTeKscrIo4ApQ X-Received: by 2002:a05:6870:d892:b0:409:95c6:f2d2 with SMTP id 586e51a60fabf-41ca6fd38a5mr4387258fac.30.1774548453058; Thu, 26 Mar 2026 11:07:33 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKHZ+dkhpQHJanoQT13izN7H4Ag6hC+IIUWxk31p66HiA==" Received: by 2002:a05:6870:e12b:b0:41c:64c3:46be with SMTP id 586e51a60fabf-41cc8f71813ls636142fac.1.-pod-prod-07-us; Thu, 26 Mar 2026 11:07:28 -0700 (PDT) X-Received: by 2002:a05:6808:150d:b0:46a:5b76:1dbb with SMTP id 5614622812f47-46a5c5d64d0mr4397080b6e.25.1774548448045; Thu, 26 Mar 2026 11:07:28 -0700 (PDT) Received: by 2002:a05:6402:370b:b0:669:cbab:ff4a with SMTP id 4fb4d7f45d1cf-66b19c3794dmsa12; Thu, 26 Mar 2026 10:28:31 -0700 (PDT) X-Received: by 2002:a17:907:c15:b0:b98:d58:f75e with SMTP id a640c23a62f3a-b9a3f148d44mr633419166b.2.1774546109903; Thu, 26 Mar 2026 10:28:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774546109; cv=none; d=google.com; s=arc-20240605; b=lOFqUVvI/JXYvdHU8pW5Exi8GW0KGDg0xvJUAkRwAoxo69UBvVm9k/TyMiSbuKlssI wLpH1GCQk3tApbb6VSexhF12mE/fuk0GrX280P5qm8tA+1O8EDa1gC29W8CXok5XE7oN NF4YUIc96Fdzs6+e/SD//AxpCOPwf5aowDH0rXdvSvGOsVgI8/ZTzerWHYtpEmqG61bb w5g3QQQhw0ocHxdicA8/oVNapimUwI9r/X5rCk4XT+ngXQxG7LTrPi5CLU6xiMETU6rQ qBSB0L3r3crxQna8pW4ZasEGs3MdjQ7W0OPlCSarIoiPykr6kyu+UnehZDwOPlw8tW14 vhwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=qWMUta84+7p75XTl9fUzqWp5zOPO2j7vvMxbwkxWLYk=; fh=MhNL3lrwfbsRO5DJHn9ZZ/LeA3+mAuX0vCziGEghh6s=; b=h5ECWRRx50XY9wIKAybh0hBu+QjVWW17V5YcIBfLUmTj4xKC8u7RSiw3UyB0GMpisM dRdgKLjG2PyViBshvmFzOHt8BiGUyYUUpwc7fRIqXghHlKgYSUawrtAszonhuIRB4oda wrkYZk+L6Nz1Lgt1RLfgwOOdigPppY3QIJLtaBSwANo7PiJQfh7orNKZ7FzVruAIUZTI xDhmn2Yk6w1T0JbefoIe4ZHrAY2nsE/bvNezFJuQdGWSZyDJdH1UkROXwfNEaxPPo585 fnIO+mlJ/1KVr+HMLLg/49hEr0qg0+HLPY18X+IhjGOEmFiVPaO3Fo3F/vPmFRKdMGiF z2/A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=EvM2lXG8; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch. [185.70.43.19]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-b9b20448f5esi4882766b.2.2026.03.26.10.28.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 10:28:29 -0700 (PDT) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) client-ip=185.70.43.19; Date: Thu, 26 Mar 2026 17:28:25 +0000 To: Ethan Heilman From: "'moonsettler' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Message-ID: <7bUEt19esY1Q1IUZKjgVtFuvgIi5i6K0p4fHO3ud4Xh03AUKuCChAD8l8x_HmlWJreemZTL-KeJW3uw9Yz5f1TBWDmNTdL6pnN8aTn8VD18=@protonmail.com> In-Reply-To: References: Feedback-ID: 38540639:user:proton X-Pm-Message-ID: 88dcda412e9f481c67196234d0022ff24b0a5312 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: moonsettler@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=EvM2lXG8; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: moonsettler Reply-To: moonsettler 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 (-) 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 approach = for the migration period is signing an EC signature with a PQ signature sch= eme as standard / best practice ^1. Even if a quantum computer finds the pr= ivate key to an exposed EC pubkey, to forge a new EC signature for a differ= ent 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 = wrote: > Howdy list, I want to share my thoughts on increasing the security of Bit= coin to long term threats such as quantum and classical breaks in Bitcoin= =E2=80=99s signature algorithms by adding algorithm agility mechanisms to B= itcoin. To quote RFC 7696: Guidelines for Cryptographic Algorithm Agility: > > =E2=80=9CProtocol designers need to assume that advances in computing pow= er or advances in cryptoanalytic techniques will eventually make any algori= thm obsolete. For this reason, protocols need mechanisms to migrate from on= e 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 b= e used alongside the current algorithms. This signature algorithm can be ve= ry expensive in txn fees and block space since it is for emergency migratio= ns only. This enables Bitcoin holders to cheaply and easily create outputs = that =E2=80=9Cfailsafe=E2=80=9D even against an unexpected break in a signa= ture algorithm. > > Motivation > =3D=3D=3D=3D > > Bitcoin should enable a person to self-custody coins for at least one hum= an lifetime, ~75 years. Someone should be able to bury an HD Seed in a coff= ee can and then dig it up in 75 years and spend those coins. No store of va= lue can promise complete safety on long timescales, but the trust we build = by demonstrating that Bitcoin is serious about mitigating long-term low pro= bability risks. Trust and credibility is built when the risk we defended ag= ainst never happens. > > > The main risk I will be considering here is the loss of the ability to au= thenticate 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. Mos= t 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 co= nsider not just Quantum attacks on Bitcoin=E2=80=99s signature algorithms a= nd also classical breaks that do not require a quantum computer. One partic= ular area of concern to me is an unexpected breakthrough in Mathematics dri= ven by AI approaches. > To address these risks we propose the following design for protecting hol= ders even against an unexpected break in Bitcoin=E2=80=99s signature algori= thms quantum or otherwise. > Design > =3D=3D=3D=3D > > Assume that Bitcoin supported two digital signature algorithms: DSA1 and = DSA2. Each signature scheme would have its own CHECKSIG opcode, CHECKSIG_DS= A1 and CHECKSIG_DSA2. > > Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a leaf s= cript 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 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 pub= lic key to an attacker or reused their public keys. As a user wishing to ho= ld Bitcoin in an output over long periods of time generate a fresh set of p= ublic keys for that output. > > > Our approach does not defend against the case where DSA1 and DSA2 are bro= ken at the same time. For this reason, DSA1 and DSA2 should use different c= ryptographic assumptions. Additionally DSA2 should use a signature scheme t= hat trades off efficiency for additional security and robustness. This way,= we can get the best of both worlds, DSA1 can be used for everyday signatur= es and if DSA1 is broken, DSA2 can be used to migrate to a new signature sc= heme, say DSA3. Even if DSA3, chosen in haste to replace DSA1, is also foun= d 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 s= uch 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 saf= e 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 to D= SA3+DSA2. > > > > Given this framework, let=E2=80=99s think about DSA1 and DSA2 with concre= te algorithms: > > - DSA1 is Schnorr, the currently supported Schnorr signature algorithmin = Bitcoin. > > - DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based s= ignature algorithm. Hash based signatures are the most likely secure long t= erm. > > If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holders c= ould hedge against a classical or quantum attack against Schnorr, while sti= ll using Schnorr. > > > Our approach mitigates the main drawback of the size of SLH-DSA signature= s, their size. SLH-DSA signatures are 8 KB in size, while [0] explores meth= ods 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 wou= ld be very expensive in transaction fees, and only economically worthwhile = to migrate from Schnorr to a new signature scheme. In all other cases the a= ddition 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. We are s= eeing rapid advances in research on post-quantum signature schemes and wait= ing a little long might buy us a lot. SLH-DSA would provide an effective he= dge against this risk, while delaying the decision of what PQ signature sch= eme should replace Schnorr in the event of Schnorr's security being weakene= d. > > 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 wou= ld 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 form = of HSMs, hardware acceleration and software liberties. That said, it is rea= sonable to consider stateful hash based signature schemes like XMSS, Winter= nitz, or Lamport signatures as the fallback signature, especially if size b= ecomes 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 alternativ= es 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= 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 CHECK= SIG opcode for SLH_DSA. > > > Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot instead = and then disabling the taproot key spend path? > A: Yes, however this would be confiscatory, since Taproot allows key spen= d path only outputs. People holding key spend path-only Taproot outputs wou= ld have the coins in those outputs destroyed. BIP 360, in essence is Taproo= t, without the key spend path. BIP 360 provides the same functionality as d= isabling 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 signatur= e algorithms are under threat? > A: No, I am confident in the Bitcoin signature algorithms and I know of n= o immediate threats. This effort is motivated by longtermism and thinking a= bout how to enable Bitcoin to be safe on timescales of decades or centuries= . > > > > [0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bitcoi= n (2025) https://eprint.iacr.org/2025/2203 > > > I want to acknowledge conduition=E2=80=99s feedback and suggestions on th= is email, including the sentence about xpubs. The ideas above resulted from= conversations between myself, Hunter and Isabel. Similar ideas have been s= uggested on the list before. I make no claims of originality, I am organizi= ng these ideas and my thoughts on them into a concrete design. All errors a= re 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/bitcoinde= v/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmai= l.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/= 7bUEt19esY1Q1IUZKjgVtFuvgIi5i6K0p4fHO3ud4Xh03AUKuCChAD8l8x_HmlWJreemZTL-KeJ= W3uw9Yz5f1TBWDmNTdL6pnN8aTn8VD18%3D%40protonmail.com.