From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 10 Feb 2026 15:23:03 -0800 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 1vpx4Q-00031D-4m for bitcoindev@gnusha.org; Tue, 10 Feb 2026 15:23:03 -0800 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-4097bb790e5sf1976520fac.1 for ; Tue, 10 Feb 2026 15:23:01 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770765776; cv=pass; d=google.com; s=arc-20240605; b=K/V5rEfkTc/i7j9kb5jMAfGZtweQf0UvHuQxjnqQqny2j0Kfn+xLMRLLyWGRwS+5qt FJfqNqDApc4KHARVApANQsjDKI0Mb8Mgw4lDpQlRgCgSSMsy0xUALtYTwk/7WqFomS6x SaBe+fo4AzEsSCk2DKZN9b+scFLBcpmgLB4qZJPcWxahSl5ucF5j1TUwPESQvR+Wf5t4 KZbEK2KSTROJXk+ZpoUK+LPYikJQw8Wr0x6BfTqVu9//yKfi78SdY4xxEIlD5Wx7xKGH tnFAU/8bLq3y9jmKkEHy3g5t7qAhM1EeDPomiOY24BznE3TOENWCQX8U1fjk9kqxoTOd +B/Q== 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=941yfaFSj32/LZl4v4lUC+U/PlufLOQb7XJjEuzhiX4=; fh=2njyarksNc+/YZ4EeQL6+U7X6IzFS4uFxo4T/7sL6OQ=; b=hVNqRAkiLLgTIavHzi8Xk10BH4qiP/hcr6fXrfIZL8wh97NEjiFO9t0ihOX+JAWl/3 4tGpdv00Cbz8Ua3/XLdCEDlPUr+cH0aZRIGwVw/ybtJKiWmdNwgSwHlGGVA6EL09dsjP 344X/CKa3/pzub5CcVQx+5bT/K6XNtIBPljRcwecjekLLIXlXnoQVbUJEkcRZ6WJSUT8 OX83UwXQ33ess/n9Rylus9jY0TwRYxWRQ5KS0eSY6pGNRN4KYODxdgyZqjGNQQeJkO/r 4EZG/mARgt5d8JutlxIXXR0YIFRi89ViwWIS3yu5PCRK2Z28gx49t3UUItMaz/K3YMxj 0GXw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UdToH7i5; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1034 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=20230601; t=1770765776; x=1771370576; 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=941yfaFSj32/LZl4v4lUC+U/PlufLOQb7XJjEuzhiX4=; b=l1hnvKQ+zSLGApaI1+zam0hfAnH/A7vkiHpF57G2Qx7IwsezViIV/t4929L37wOzpf mrfxBJbYCAwLgdo3VFxPWi4/8kCiGVMeia7u/i6QDG1qua4YwXr1E83+YzP5HbxoCYBr 9wJblPX5FS3iynoni+CszMIcz7qsQNMzU05IYcfd/CDrw0lKjFEL45XioiqI8zjV5l9X 0Cs4CpbTlnmjf7blGdrp1RxadVt1EqqmW7yP5bdIokWfK62WvpRikEbv/5EhU7IW5qT7 vWbY6DogS032E870TLnbA7izcwzucePviCQVumCsD0TWMhBheQmnk4l9Wm65IjRc8NsJ W0DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770765776; x=1771370576; 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=941yfaFSj32/LZl4v4lUC+U/PlufLOQb7XJjEuzhiX4=; b=Ng12c4D0ZDleWZkb0Gxzb1wFKSXQBPhumd1n6ZpdkHUE41THNpaGpoejmYwPmoqQ+G V7Rerm6vM5taogSah19Bp2KYUGaNpSElXhAw5WGYAZmpPjMVERk2lAdGbFkLkkVf0qEn NqAw5Sp+Ggiz6xLy0g6IPHIxVsH4iErhI5u42qqzeNy0gysFvzLljuWewBwDPwaYsnIm r4JiZTGqekT+erlZll1WnFcNkf2iymP4na0ZwxcoxYSmhw7qbM41lB0pLprZUgkO/pTN dWOkBPZ8qsmwP5aJl7XNU2x6ApZXu9OMCkNRjiJ0JtyxoVG+S+4zD04Gg5a3+66FXmyP joXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770765776; x=1771370576; 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=941yfaFSj32/LZl4v4lUC+U/PlufLOQb7XJjEuzhiX4=; b=hc15rGqvWAYHrX8d4tAt3QjewK0iNegB+cCk3/gx0CpwbM5lQlla5KX54bD6wpGkef slXvnxOoFqecy4BKdGCwceX79HhyV7+Hc4k1eBKbBS/L3Q9eadhUXf1LW8JlD/rPPljm 1WG1JnQGbjhrPcxH8n9603/K64tCg+OWDZnWg3XnI0p/P/ndbovkwE/Dm+9VAJXF6SbU GU/AoG5kR5FulsOQB6D+jpE/h3UhLzCPzdjLNMsJ1g4beq4A9s2THShuNrUTe2Ry6j7v pby6N1DdDD56KDvnNTg6nPMUGd27hxWUH2vkvrxXXloUHTCBRxHLFw8V6ET99RWUyK8c hQgg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUaJdbIbJ/EFWApRQo8DbrRNm3GutuyMwKoe0JJL6SWfImoueq58gCLD6YdBxGqOvODJ5nS8RRM2MRj@gnusha.org X-Gm-Message-State: AOJu0YwADk7E1/bIaHYxIg6+gdOd/z8oPwLQ7rRfxHb6idGHmDPgpizO SQdo7irpe04+gKFRXhSLoqNK+1Rjorj+FIOsu+NpIoSgHTiRHwzMVjUP X-Received: by 2002:a05:6820:808:b0:659:9a49:8ee4 with SMTP id 006d021491bc7-672ebaa89d5mr2122268eaf.24.1770765775401; Tue, 10 Feb 2026 15:22:55 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+E0K9Shqi5coPFftY6nYqxT3NspphRo3gpWUxsPLux34g==" Received: by 2002:a05:6870:13d7:b0:3f5:cf8c:7f65 with SMTP id 586e51a60fabf-40ea8e070e9ls67705fac.2.-pod-prod-00-us-canary; Tue, 10 Feb 2026 15:22:49 -0800 (PST) X-Received: by 2002:a05:6808:10d4:b0:45f:156c:e5a6 with SMTP id 5614622812f47-46352a93fabmr2119533b6e.14.1770765769654; Tue, 10 Feb 2026 15:22:49 -0800 (PST) Received: by 2002:a05:620a:1b98:b0:892:e292:65ef with SMTP id af79cd13be357-8cace8d312bms85a; Tue, 10 Feb 2026 14:20:04 -0800 (PST) X-Received: by 2002:a05:6122:3b17:b0:567:fb8:c7ea with SMTP id 71dfb90a1353d-5673befa105mr1141706e0c.8.1770762003843; Tue, 10 Feb 2026 14:20:03 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770762003; cv=pass; d=google.com; s=arc-20240605; b=TbrHkLdbug8Sml/A4gUa/F7/Eww82bgNfKmzeeffEHgo5xh3qhM1yD6l6FkxL9+4U6 0bexAMqSzYxu+JCoCGppHxqYo37pbHvOT0Gtfp1WbRvmaDPFJRMAWyVy7sAvxJGxhxZW 1Z0sR/tbom2YNBd1DMYPkhEQzIx4FRnG2BL6gHd5lm63XE+52Kuwrp8ZVMKIzf4+lPaI cegCjB5AAuPA7jh4C8V3vsPMXlRZGof/jcijyu+ZB++5SUH/0yuKwQJxKAEvoxFs3pM5 Hm4egBF7sIyknU5QiCpKXsOCcsK5+/pNPDv0IQmGoOhlFTVc1xJeFWQDJv68jYCl9Gbq yTAw== 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=ujfRcfJB5JHAuvgN+ensoykVP+VVKAWMbpZQEaiR/xI=; fh=49LxTRfugmXp9tdpDCv6NEYajFEs6KBGnZ8qa/kxIF8=; b=A5a64FP6z23nppRgsbB2DvhASAEG+BXrJP6bIB/LGR8vozjrVGDHZsBAExYS5dY50V Bp6kz4uBPrLXby3PP7pdZ+F4G5kJdD+7ozJpbCI/jP0xeXQqmGhSQaeXymDO4Wyw0fIG 97XZj+32Q4X9SsuCtmMGZ3/t/eC4j/2+pacRWuydKYo2sgPYTtb3SfEOCi4WJRm0upbz E1IhjSMsRWlHRmy5FVzHxhgyt2i69oJjj+MehAtHK1lzLmirgSEYexLIdHFhQbOziNAG Rh869AXtmOtNS/t1rIDIWBTb/d+v89HysQnybak7vSsNNP9rD9I2bphxJoDvywgAR5JC xv6Q==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UdToH7i5; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1034 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-pj1-x1034.google.com (mail-pj1-x1034.google.com. [2607:f8b0:4864:20::1034]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-94afd230df6si6061241.3.2026.02.10.14.20.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Feb 2026 14:20:03 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1034 as permitted sender) client-ip=2607:f8b0:4864:20::1034; Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-35480b0827bso190632a91.0 for ; Tue, 10 Feb 2026 14:20:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770762003; cv=none; d=google.com; s=arc-20240605; b=BzjnyedDBxNDbEVTrwFDaanmGXO/EspakBa5S9ZB4IrwyYm461bsm1Taa3I6vtnK6r RluvXUdNtZzHtgz1Ft/DfHdja2KBSR7w+SzeVSd1mnVbHzOcJMZNM26uWBpGmDkOwfPK f5kiXayfsirN2X+SE8pnR2epAOtUMU0gGmXHL2LFNgeXKl2lth/uYH3WXi1VxeBPNV2q iCcNpDDSJf/xvajs33wcI3C1AQ4/kBb972nnmqgevy2IW9Bt4w9No3L2MLGx09zFPK8P FVnL8RwlajnpYkHm81l+U2yR/LikBEUxf8/abdzQIIu9Q3blj4UXVzsALtI/mUoW/yIk zyJg== 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=ujfRcfJB5JHAuvgN+ensoykVP+VVKAWMbpZQEaiR/xI=; fh=49LxTRfugmXp9tdpDCv6NEYajFEs6KBGnZ8qa/kxIF8=; b=RLEFRSu+o9xQEJr8UbHirAAjK5L1ghD+tcgxQY2TKrbJPIAcyp7gH72QM90+uaIqw8 cdh5zI8IuYedZqqxXZNuF1O4GeHxtlcPyPMwSWBO9avOr22De8Saotj7IN28ZLD0zVn7 kA8MdqPE5Epe0wvOM69zkZGh5Gvbmri39M9mrJzB59q7u9UDovWz2a9kPMuYS432waU+ veMarABh7kBjnfaEUvG2RxhKNQwgZDbMWGikhamr+oo2Op1VkNl4XqpQs5cWSK48E+ez SJOefI4oSVNFf7mhv3fA++MtEyqTX+cpqeJeNuZAOEubDSXU06f1De4QqlMI4cisJLDJ Eyqg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aIabv9MS0ZexbXtOXhCtbHsAN2zIO2uwEMZwHJGDBVqlBeXtUJyBaiHehKOCGz ecgThJ7rOZA7ODr+FK1vDJBEoCSEe5QRA7MMFoXtHch0IcRgbuQFGLenjmqd1Fl1SYnoSCvIod7 882MWfocCaeKZjXXNxrH4qc1rWF2WwENHQANmHbkCykB8lhG6gXyjFMALo3cSPpu6o8q+IRb11k Jvvxvqms80p9ZYR7oGTdGgWdMoDSuFLjXZRww99siApJgZ64B94cdN1ZbNvnxXSACHH7UeqQj0u fy9Q7wELLctwgGNK2POQHzNOimODKrIsyIRjcgXPHC3PSGJLo9FRqCxRueN6tvXxZeZAeKSGezZ 31cxRlG0lxvte0bf0KE5SIe8pCOtOiR+AyiHjRfvr4xV0Q4v9732fwtyaAc69rScvKg1VRYk7Jv z/1HEN48v7kZAB+uQ4/wvrO1+jOg== X-Received: by 2002:a17:90a:c2c8:b0:356:26c5:aaa9 with SMTP id 98e67ed59e1d1-3566615404amr2933049a91.2.1770762002045; Tue, 10 Feb 2026 14:20:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Tue, 10 Feb 2026 17:19:26 -0500 X-Gm-Features: AZwV_Qi-burFLaApa1eQzpLllRJptM0O0Wf3ITdRI4ywT_rzW7zAF7hv2bjYV60 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: Brandon Black Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000001d2232064a7fa8da" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=UdToH7i5; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1034 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 (/) --0000000000001d2232064a7fa8da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no objection to GSR based post quantum signatures and this approach is compatible with the proposal outlined above. I really like the idea that we could transition from algorithm to algorithm without having to soft fork= . Even for DSA2, we would probably want a vetted ecosystem. Imagine you are hired to recover coins inherited by an estate. DSA1 is broken, so to safely spend the coins you need to use DSA2. If you can reconstruct the spend script for DSA2 using only the HD seed, you are going to have a good day. If you have to guess the particular signature algorithm used from a large set of variants, you might not be able to recover the coins. My goal is to have a standardized way for wallets to transition to new algorithms. If this was done with GSR, you'd still want a BIP for a new signature algorithm (DSA2, DSA3, DSA4, ...), you spend all the time on security reviews and getting buy in from wallets and custodians. My main concern with GSR, and the reason it isn't included in the proposal, is if there is consensus to activate it. On Tue, Feb 10, 2026 at 4:51=E2=80=AFPM Brandon Black wrote: > Thanks for posting this. > > What are your thoughts on the alternative mechanism of deploying GSR or > similar in BIP360 and then letting folks build their own DSA2 which can > then change over time without additional forks. Most of these would never > be spent from anyway, and this seems like a dominant approach for DSA2. > > Sipa pointed out to me on an Optech podcast that this approach is > inappropriate for DSA1/3 because there are strictly need a vetted ecosyst= em > for regular spends, lightning, aggregation, etc. > > Best, > --Brandon, sent by an Android > > Feb 9, 2026 07:40:47 Ethan Heilman : > > 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 pow= er or > advances in cryptoanalytic techniques will eventually make any algorithm > 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 migration= s > 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 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 > 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 and > 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 wouldn=E2=80=99t be ab= le 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 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 > DSA3+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 > 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. We are > 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 > 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 of > 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 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 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 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 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 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 > about 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 > 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%2BUS1-QRgAXStAZ2tsJiPBeQtm7%3D_q7LrQdDHR%3DVAci%2BvA%40mail.gmail.= com. --0000000000001d2232064a7fa8da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have no objection to GSR based post quantum signatures a= nd this approach is compatible with the proposal outlined above. I really l= ike the idea that we could transition from algorithm to algorithm without h= aving to soft fork.

Even for DSA2, we would probably want a vetted e= cosystem. Imagine you=C2=A0are hired to recover coins inherited by an estat= e. DSA1 is broken, so to safely spend the coins you need to use DSA2. If yo= u can reconstruct the spend script for DSA2 using only the HD seed, you are= going to have a good day. If you have to guess the particular signature al= gorithm used from a large set of variants, you might not be able to recover= the coins.

My goal is to have a standardized way for wallets to tra= nsition to new algorithms. If this was done with GSR, you'd still want = a BIP for a new signature algorithm (DSA2, DSA3, DSA4, ...), you spend all = the time on security reviews and getting buy in from wallets and custodians= .

My main concern with GSR, and the reason it isn't included in = the proposal, is if there is consensus to=C2=A0activate it.



On Tue, Feb 10, 2026 at 4:51=E2=80=AFPM Brandon Black <= ;freedom@reardencode.com>= wrote:
=20 =20 =20
Thanks for p= osting this.

What are= your thoughts on the alternative mechanism of deploying GSR or similar in = BIP360 and then letting folks build their own DSA2 which can then change ov= er time without additional forks. Most of these would never be spent from a= nyway, and this seems like a dominant approach for DSA2.

Sipa poi= nted out to me on an Optech podcast that this approach is inappropriate for= DSA1/3 because there are strictly need a vetted ecosystem for regular spen= ds, lightning, aggregation, etc.

Best,
--Brandon, = sent by an Android

Feb 9, 2026 07:40:47 Ethan Heilman <eth3rs@gmail.com>:

Howdy list, I want to share my thoughts on increasing the security of Bitc= oin to long term threats such as quantum and classical breaks in Bitcoin=E2= =80=99s signature algorithms by adding algorithm agility mechanisms to Bitc= oin. 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 algorithm o= bsolete.=C2=A0 For this reason, protocols need mechanisms=C2=A0 to migrate = from one algorithm suite to another over time.


Algorithm agility is achieved when a protocol can easily migrate fro= m 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 mig= rations only. This enables Bitcoin holders to cheaply and easily create out= puts that =E2=80=9Cfailsafe=E2=80=9D even against=C2=A0 an unexpected break= in a signature algorithm.

Motivation
=3D=3D=3D=3D

=C2=A0

Bitcoin should enable a person to self-custody coins for at least one huma= n lifetime, ~75 years. Someone should be able to bury an HD Seed in a coffe= e can and then dig it up in 75 years and spend those coins. No store of val= ue can promise complete safety on long timescales, but the trust we build b= y demonstrating that Bitcoin is serious about mitigating long-term low prob= ability risks. Trust and credibility is built when the risk we defended aga= inst never happens.

The main risk I will be considering here is the loss of the ability to aut= henticate ownership of coins resulting from a break in a digital signature = algorithm used by Bitcoin. Such risks are extremely unlikely in the short t= erm (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 con= sider not just Quantum attacks on Bitcoin=E2=80=99s signature algorithms an= d also classical breaks that do not require a quantum computer. One particu= lar area of concern to me is an unexpected breakthrough in Mathematics driv= en by AI approaches.
 To address these risks= we propose the following design for protecting holders even against an une= xpected break in Bitcoin=E2=80=99s signature algorithms quantum or otherwis= e.
Design
=3D=3D=3D=3D

Assume that Bitcoin supported two digital signature algorithms: DSA1 and D= SA2. Each signature scheme would have its own CHECKSIG opcode, CHECKSIG_DSA= 1 and CHECKSIG_DSA2.

Using BIP 360, we could have a leaf scrip= t for CHECKSIG_DSA1 and a leaf script for CHECKSIG_DSA2.

Leaf= 1: 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 publ= ic key to an attacker or reused their public keys. As a user wishing to hol= d Bitcoin in an output over long periods of time generate a fresh set of pu= blic keys for that output.


Our approach does not defend against the case where DSA1 and DSA2 ar= e broken at the same time. For this reason, DSA1 and DSA2 should use differ= ent cryptographic assumptions. Additionally DSA2 should use a signature sch= eme 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 sig= natures and if DSA1 is broken, DSA2 can be used to migrate to a new signatu= re 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 unb= roken, 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 to n= ew signature schemes.


A person with an HD seed buried in a coffee can for 75 years is stil= l 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 concret= e algorithms:

- DSA1 is Schnorr, the currently supported Schn= orr signature algorithmin Bitcoin.

- DSA2 is SLH-DSA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based si= gnature algorithm. Hash based signatures are the most likely secure long te= rm.

If we merged BIP 360 and support for a SLH-DSA CHECKSIG op= code, holders could hedge against a classical or quantum attack against Sch= norr, 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 metho= ds for reducing the size of these signatures to 3 KB, 3 KB is still huge. B= ecause SLH-DSA signatures would not have any additional discount, they woul= d be very expensive in transaction fees, and only economically worthwhile t= o migrate from Schnorr to a new signature scheme. In all other cases the ad= dition of SLH-DSA would exist as unused leaf scripts in the output, which i= ncreases the witness by 32 bytes.

An additional benefit to thi= s approach of using BIP 360 and SLH-DSA would be to buy time for non-hash b= ased PQ signature schemes to mature. We are seeing rapid advances in resear= ch on post-quantum signature schemes and waiting a little long might buy us= a lot. SLH-DSA would provide an effective hedge against this risk, while d= elaying the decision of what PQ signature scheme should replace Schnorr in = the event of Schnorr's security being weakened.

Q & A<= /span>
=3D=3D=3D=3D

Q: Could these signatures be abused to sto= re JPEGs on the blockchain?
A: No because they would have no additio= nal discount. This means they would have no advantage for JPEGs over what i= s currently possible.

Q: Why not use XMSS or Lamport signature= s 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 ecosys= tem of support in the form of HSMs, hardware acceleration and software libe= rties. That said, it is reasonable to consider stateful hash based signatur= e schemes like XMSS, Winternitz, or Lamport signatures as the fallback sign= ature, especially if size becomes a concern.

Q: What non-cons= ensus critical changes would be needed to support this?
A; We=E2= =80=99d need to create new wallet standards to provide alternatives to BIP3= 2 xpubs. Wallet would have to write code to generate SLH-DSA keys and creat= e a script tree per signature alg. Wallets would also have to put into plac= e 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 CHECKSIG opc= ode for SLH_DSA.


Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot ins= tead and then disabling the taproot key spend path?
A: Yes, however = this would be confiscatory, since Taproot allows key spend path only output= s. People holding key spend path-only Taproot outputs 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 k= ey spend paths, but rather than being confiscatory, it is opt in.
Q: Are you proposing this now because you think that the Bitcoin signat= ure algorithms are under threat?
A: No, I am confident in the Bitcoi= n signature algorithms and I know of no immediate threats. This effort is m= otivated by longtermism and thinking 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/20= 25/2203


I want to acknowledge conduition=E2=80=99s feedback = and suggestions on this email, including the sentence about xpubs. The idea= s above resulted from conversations between myself, Hunter and Isabel. Simi= lar ideas have been suggested on the list before. I make no claims of origi= nality, I am organizing these ideas and my thoughts on them into a concrete= design. All errors are my own.=C2=A0=C2=A0

Than= ks,
Ethan

--=20
You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group.=20
To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+unsubscribe@googlegroups.com.=20
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWTqe8%3DuqCh= u2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.com.=20

--
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.googl= e.com/d/msgid/bitcoindev/CAEM%3Dy%2BUS1-QRgAXStAZ2tsJiPBeQtm7%3D_q7LrQdDHR%= 3DVAci%2BvA%40mail.gmail.com.
--0000000000001d2232064a7fa8da--