From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 02 Apr 2026 04:52:15 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.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 1w8Gas-00067U-Ma for bitcoindev@gnusha.org; Thu, 02 Apr 2026 04:52:15 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-40a4d2264absf1843206fac.2 for ; Thu, 02 Apr 2026 04:52:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775130728; cv=pass; d=google.com; s=arc-20240605; b=DtWZMU2+0y3F/mpfm5gs/mpwl8v7fYlIFU5gEHH8kTHxaPqj7Xqi1o0LlSHF578IqY UgObClfuH3LyAKELbQSyo95ypOwvSz2DNLU0agv14Vztm8/eAK2f6d7IVR0TXinVIidK ONz/HgaZo4T1mvLC/BieELmdQKeVRr7AYuHUNp+6aq8MW2EWREvihBVxMUO/FvjqjO3q H/PUK3fAOdykij2wFT71vsp2LTHZY+sgZY9rjvcdICkDFRI3SOegmslw4Z0CBuhPT/K3 DLyxHW6QP0qNYFAD88z1tc93Xb0qJ+UXQgrGw56Hz+NwNza72zwPbvwIxWCoes7TUgnj HChw== 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=k0HpU/pHCQAqqeYMWe8EB/umGizzD/Ogs0e9Lqo/REw=; fh=PJ0LsD2bewgveefm4NIcv9yCduHTcoAvoVuOnIGi/nU=; b=i3E5rGMx0glvJJ4PvDXeeuV0jfSjHhxKBwYnbqdlouZvdNMMHoLDJDaWKsQg0XTt1Y Eki9x9mu+xLbDqy7Rf2PWkXo7RCr23I6FiU+hBuQaG+yvnXLNWCLsQXn/WNvvp2Zax4J Kv243AQ16qUI4RrTrnNy2E4T2XnuAJ4i9efE/kIm5JjpTMkSq9AtoGpjCbzFhRkxbwKD i8Li/rxqIfOb+Z8d7UrH+1Sa6dVoQk1/t4y5kxLgEdmoyH2Gm7P2FW1yWseWYYTfkJ4/ oB34NVkzQP8rHicIuwOE9WZQMSdwtzuyLuLbUf7sVHvQrY3T8W8lOPT26apcKnhHcLGo yi8A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=n907oKnC; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.166 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=1775130728; x=1775735528; 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=k0HpU/pHCQAqqeYMWe8EB/umGizzD/Ogs0e9Lqo/REw=; b=LKdyNe8LHUimahbfiDeVFuo2D4DJTNmLoeiPqgYRB7CSihrZuYPuctpLnFUtFnL5sY ORtA+bhEm3frI7S/Xt/UcHag+1w/Ko5I6q6QsPvdtsK05p8rvnVuUyqPnHYnndHoyPj5 ix6SU9WQZhqdt2pER3RJhLrpesfElNIQJu9yN8e4dy9QOetuifutySnay5FjVPuVvC9j 5BshmE0fFr0qHAPEkebIYDq9s+s7NK/S0RNzdSjQMfi6Y+vlCJHe3LqpzNR1lcTF+2yj clnstYRlDcBNfBqxuw1y5eSfsIJ4Rz67wTPxN1CMfI0Xyd6ygjqtGQbPuIPoHv0OV8rg EMvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775130728; x=1775735528; 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=k0HpU/pHCQAqqeYMWe8EB/umGizzD/Ogs0e9Lqo/REw=; b=CnQn5fxmLNS26H8Dhrmkl66Y6Q+5nwI0h53Fe/MzP6Dou8fgwbey2K6fLW5viuNQQY eA88tEAlY7nctN9EIheYU4x84CZljSF/DxbfqyDrWIN2twvpFzedlwfDdf38sjNQrXBA y3HGyRBjjh6qUjPc/WkBwYPykibE5s+cIPQ7EsT3gmLkS9Q7esxdzybuWwsZVv9DpJgv /8Ym9vC7Mgq4iY8PIyA3WOAbvtYC5rfrn/bh0rjknEYO68FLZTNX5xB6zijQ8N4mr/+v apkbK84+F4IyYohnPBNjsWYXPx036/+quMjCXW6WwVXjs7BLT5rsIpJtrVHhRqpMuV0Q pvYA== X-Forwarded-Encrypted: i=2; AJvYcCW0UBeXYPFSqWT49D+8bVF3YH7mmlLSmbAgJAMjIGaxEbDKiXGCkwHr1gF7RnL1UUfFCyVTZrgcZO9V@gnusha.org X-Gm-Message-State: AOJu0Yw/4jVA1eNFdRw72vmPtxkh4vaKHgk94q92zbjEFQiNst2kEpR1 bK37lmi/TrrB/pU918j4bRcp6TpjbgET1Y8MmKybOMhbM8X6m7pyMf2T X-Received: by 2002:a05:6870:f113:b0:41c:8723:cc0f with SMTP id 586e51a60fabf-422ec9362bcmr1674523fac.38.1775130728354; Thu, 02 Apr 2026 04:52:08 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIhCAwP3npkT4YV1a66/u22FayLSAy/WuHgH+2EmrGVMA==" Received: by 2002:a05:6870:70a7:b0:41c:65ea:68a1 with SMTP id 586e51a60fabf-422ee040a5dls361231fac.0.-pod-prod-03-us; Thu, 02 Apr 2026 04:52:02 -0700 (PDT) X-Received: by 2002:a05:6808:152b:b0:44f:fd6e:41cc with SMTP id 5614622812f47-46d8a589f82mr1574590b6e.54.1775130722249; Thu, 02 Apr 2026 04:52:02 -0700 (PDT) Received: by 2002:aa7:c883:0:b0:662:a537:9327 with SMTP id 4fb4d7f45d1cf-66dd11db28dmsa12; Thu, 2 Apr 2026 01:49:59 -0700 (PDT) X-Received: by 2002:a17:907:3d87:b0:b98:2b20:6680 with SMTP id a640c23a62f3a-b9c133ad8b2mr463894466b.0.1775119797834; Thu, 02 Apr 2026 01:49:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775119797; cv=none; d=google.com; s=arc-20240605; b=hdwycw0Yl18wh0XwXiGklB6ZrKetxYp7VHHzHV3uBwNdxalyOhnRJ+B2WjxQyEEyQ9 +A1O4WEar74rfPCdFlnR3ATZb4NEh/Qq4OIk9iN1RX/o2NGS/LKgdTPw6CoVKIyaK9yq erVdq/+ptlx/Wnm6ad936MbGS8xUg5i9CN8Aqw8QFbmk/sUGAGYkSjIbgTuUepG5aqbY TbjKTK5NDAqtLNP0PK3a3eRvZnrPw61PQQyzlyAozW8z76k/3/oOn/vabTWtSF6f8RE8 bKuw2OULX0FoTSESjaT4WPEwiQ5GnAo0J234aIcHJYvPWqih2T3GcKSqnkWVCl0VF/Gm bL3A== 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=/tCUnx5HVFSSstP4Sw869KyvWl1UAWTY5eTIUBk9LJc=; fh=MhNL3lrwfbsRO5DJHn9ZZ/LeA3+mAuX0vCziGEghh6s=; b=f8ohUL3APz4ppDmyYzhe4ou+RmrJu4h/S27MEmlV66ARzfINStWlcpgAibrzy3gBAM 7dpNeY85UEgmmJDyDXbTIq+ALsLNujU+iTWOohQXkSzffbc7WOVuzRbjLOiSUlDYFyk7 7VHB41XzGx+dGmB3apRj3wjSdvOP2CjcADG8K81ihkKs60UAr0GM8Ex7OW5EHxLGWgwR FQx2dUWUKdondNSDx+9rreGto3B3upwViVodHt85n5w8usC2z76+A/krOukvs3+gJ425 Ab3v9txQdW0g19P7VN5uC/0DxSvfhEfvzNp7pCSqfr9uGeM/1aJ/CzQJKkCrm1Ah/wiK dBQQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=n907oKnC; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.166 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-43166.protonmail.ch (mail-43166.protonmail.ch. [185.70.43.166]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-b9c3c5513b7si2871266b.0.2026.04.02.01.49.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 01:49:57 -0700 (PDT) Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.166 as permitted sender) client-ip=185.70.43.166; Date: Thu, 02 Apr 2026 08:49:53 +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: In-Reply-To: References: <7bUEt19esY1Q1IUZKjgVtFuvgIi5i6K0p4fHO3ud4Xh03AUKuCChAD8l8x_HmlWJreemZTL-KeJW3uw9Yz5f1TBWDmNTdL6pnN8aTn8VD18=@protonmail.com> Feedback-ID: 38540639:user:proton X-Pm-Message-ID: d6b74a898b51f5b309dc4c61c78f1fb2e0d6401e 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=n907oKnC; spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.43.166 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, > I worry such an approach, as the default, might slow adoption by making t= ransactions 3x larger prior to a CRQC being practical. If there is strong i= nterest for this, then users can do it. I don't dislike your approach, it is strictly speaking sufficient (and woul= d work for me). But there are other things to consider: - There is already FUD and resistance about bitcoin being psy-opped into ad= opting new cryptography that will turn out to be broken, less technical peo= ple are looking for "motives" instead of tradeoffs. And frankly suspicion h= as been voiced by long time bitcoin devs as well. - The footgun potential of compact PQC is significant, it's a learning curv= e. ECC adds extra cushion until it's trivially broken. This as standard pra= ctice and not something wallet devs optimize out, can save a lot of funds i= n the migration period. - There is uncertainty about who and in what capacity will first break ECC,= but it's unlikely that parties using key and signature aggregation will be= the first. ECC key and signature aggregation has barely matured, we have y= et to take full advantage of it. BR, moonsettler On Thursday, March 26th, 2026 at 11:08 PM, Ethan Heilman = wrote: > Hi Moonsettler, >=20 > 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 di= scuss 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. >=20 > Leaf1: ECC_PUBKEY, CHECKSIG_ECC > Leaf2: PQC_PUBKEY, CHECKSIG_PQC >=20 > 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. >=20 > 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 exposu= re attacks on PQC are practical and no one is aware of it, you could just h= ave one leaf: >=20 > Leaf1: ECC_PUBKEY, ECC_PUBKEY, CHECKSIG_ECC, PQC_PUBKEY, CHECKSIG_PQC >=20 > I worry such an approach, as the default, might slow adoption by making t= ransactions 3x larger prior to a CRQC being practical. If there is strong i= nterest for this, then users can do it. >=20 > Thanks, > Ethan >=20 >=20 >=20 > On Thu, Mar 26, 2026 at 1:28=E2=80=AFPM moonsettler wrote: >=20 > > Hi Ethan and List, > >=20 > > We should stop talking about cryptographic systems in exclusive terms! > >=20 > > 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. > >=20 > > Benefits: > > - Introduction of new cryptography ^2 provably does not degrade the sec= urity 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 e= ra. ^4 > >=20 > >=20 > > 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 adeq= uate 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. > >=20 > > 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 require= s UTXOs to be locked up in long-range resistant addresses with spend time o= ptionality to spend in a short-range protected way. > >=20 > >=20 > > 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 = and quantum computer hours will look like. Yet small value UTXOs would be e= specially 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 / stat= efulness issues and the mitigation is costly. > >=20 > > BR, > > moonsettler > >=20 > > On Monday, February 9th, 2026 at 4:40 PM, Ethan Heilman wrote: > >=20 > > > 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 Bitco= in=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 al= gorithm obsolete. For this reason, protocols need mechanisms to migrate fro= m 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 b= e very expensive in txn fees and block space since it is for emergency migr= ations only. This enables Bitcoin holders to cheaply and easily create outp= uts that =E2=80=9Cfailsafe=E2=80=9D even against an unexpected break in a s= ignature 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 o= f value can promise complete safety on long timescales, but the trust we bu= ild by demonstrating that Bitcoin is serious about mitigating long-term low= probability risks. Trust and credibility is built when the risk we defende= d against never happens. > > > > > > > > > The main risk I will be considering here is the loss of the ability t= o authenticate ownership of coins resulting from a break in a digital signa= ture algorithm used by Bitcoin. Such risks are extremely unlikely in the sh= ort 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 shoul= d consider not just Quantum attacks on Bitcoin=E2=80=99s signature algorith= ms and also classical breaks that do not require a quantum computer. One pa= rticular 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 al= gorithms 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, CHECKSI= G_DSA1 and CHECKSIG_DSA2. > > > > > > Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a le= af 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, wou= ldn=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 t= o 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 differe= nt cryptographic assumptions. Additionally DSA2 should use a signature sche= me that trades off efficiency for additional security and robustness. This = way, we can get the best of both worlds, DSA1 can be used for everyday sign= atures and if DSA1 is broken, DSA2 can be used to migrate to a new signatur= e 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 unbr= oken, allowing us to replace DSA3 with DSA4. > > > > > > DSA1 - Efficient, low cost to use, should support nice-to-have featur= es 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 DSA= 2 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 co= ncrete algorithms: > > > > > > - DSA1 is Schnorr, the currently supported Schnorr signature algorith= min Bitcoin. > > > > > > - DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash bas= ed signature algorithm. Hash based signatures are the most likely secure lo= ng term. > > > > > > If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holde= rs 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 signa= tures, 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 hu= ge. Because SLH-DSA signatures would not have any additional discount, they= would be very expensive in transaction fees, and only economically worthwh= ile to migrate from Schnorr to a new signature scheme. In all other cases t= he addition of SLH-DSA would exist as unused leaf scripts in the output, wh= ich increases the witness by 32 bytes. > > > > > > An additional benefit to this approach of using BIP 360 and SLH-DSA w= ould be to buy time for non-hash based PQ signature schemes to mature. We a= re seeing rapid advances in research on post-quantum signature schemes and = waiting a little long might buy us a lot. SLH-DSA would provide an effectiv= e hedge against this risk, while delaying the decision of what PQ signature= scheme should replace Schnorr in the event of Schnorr's security being wea= kened. > > > > > > 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= of Bitcoin and Bitcoin can benefit from this ecosystem of support in the f= orm of HSMs, hardware acceleration and software liberties. That said, it is= reasonable to consider stateful hash based signature schemes like XMSS, Wi= nternitz, or Lamport signatures as the fallback signature, especially if si= ze becomes a concern. > > > > > > Q: What non-consensus critical changes would be needed to support thi= s? > > > A; We=E2=80=99d need to create new wallet standards to provide altern= atives 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 C= HECKSIG opcode for SLH_DSA. > > > > > > > > > Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot inst= ead 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 outputs= would have the coins in those outputs destroyed. BIP 360, in essence is Ta= proot, without the key spend path. BIP 360 provides the same functionality = as disabling Taproot key spend paths, but rather than being confiscatory, i= t is opt in. > > > > > > Q: Are you proposing this now because you think that the Bitcoin sign= ature 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 thinki= ng about how to enable Bitcoin to be safe on timescales of decades or centu= ries. > > > > > > > > > > > > [0]: Mikhail Kudinov, Jonas Nick, Hash-based Signature Schemes for Bi= tcoin (2025) https://eprint.iacr.org/2025/2203 > > > > > > > > > I want to acknowledge conduition=E2=80=99s feedback and suggestions o= n this email, including the sentence about xpubs. The ideas above resulted = from conversations between myself, Hunter and Isabel. Similar ideas have be= en suggested on the list before. I make no claims of originality, I am orga= nizing these ideas and my thoughts on them into a concrete design. All erro= rs are my own. > > > > > > Thanks, > > > Ethan > > > > > > -- > > > 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/CAEM%3Dy%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%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/= iOcCeyNQe4dgGq-PR5L4-rQR5CCNNno8GbY5wz2wv3rTJDeA4OxUv_8ukGngIBbrjrubbDi-_Q6= D4xu5b7QOr-4GXma6vbxW3cLuOeBrXNM%3D%40protonmail.com.