From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 09 Feb 2026 07:40:56 -0800 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vpTNe-0000fL-Mb for bitcoindev@gnusha.org; Mon, 09 Feb 2026 07:40:55 -0800 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-40951019a1dsf12880893fac.1 for ; Mon, 09 Feb 2026 07:40:54 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770651648; cv=pass; d=google.com; s=arc-20240605; b=gbng6Rlx7KlM7JyLTZTGwgqxpFiZWbMrMCd9AIK7iOOFFIup3grZyqcPk+4e/a/QJ9 9UTx1EtrFJRcbXVEm6IE+q9sBDEqc5PkrjKMgpg0NDjxOuX9wdpcmYr05c+P4SkMq71q 7VF5+GayAACi7JPTpTVvd7m3O7mDBnJrdMLGF8VuKrcfyNiQQ1rEjAQGEVrgsODkeb0b TlsZwFE/GLlm5kDRTLYJOjsjsY/UOLxWVCExqADd/hTsveM0g16j07B+koD2MLH5udZG RKOwxT9/xhv07zLkKXdH7wrYRR2PvJV27+RZshmYZCYQ+2dFl5Nq2/5sd9b8owPcfr2b HPng== 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:to:subject:message-id:date:from :mime-version:sender:dkim-signature:dkim-signature; bh=ZuwYtm5GZGaRCkW3KQwEh3xYOhfk+WB0zdwCGtb+2+I=; fh=Eku3a1Q2psu5nGeqoCWDeX39f7FaauOzwSz37MmD3AU=; b=REy2S+d+rOiV77aCaIsBXHA+lczRcGM0drsgpx0doj30g8Vme9fHKlE+Uqrc66U4Zm gx9WCjHsPQQhxp65A93g5tuZiqoEA8u24ec07iiLkE4twoJ457/yG7eOSyW6EizWjfq7 Kr37Iy07KnzRtxbMCcptBV19GEO/1w0LmoVBqMulaQZggMw1eXthrrE5xaoQ4BXD4KrK dU4AlHOWM0lxj4SJKNzHI1XAvP3hMsY5/zU6klPJSPmpj3iTL8hj3vxNPaqdYROXNSqC uVgApo3Po750PF7Jvu0eSEUns8gghZjk8nP35WFcJ1nhmuov5ukYKZBA67iUrtIytxIs KZMA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=eqk15j9E; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1035 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=1770651648; x=1771256448; 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:to:subject:message-id:date:from:mime-version :sender:from:to:cc:subject:date:message-id:reply-to; bh=ZuwYtm5GZGaRCkW3KQwEh3xYOhfk+WB0zdwCGtb+2+I=; b=hKVRISBQgI/UkFSIiSG0a7df2yi/NqWpzengcFUkkje39dwH99FuqjpU8y7SBZEvjd kHYpdUbwQ0fa6DKoqyXJfVwAO15/A/Y7piwqHOtBaeUaDUoPzgrByIWnVA9lzVP+eKck pKq0kWd1ugsfOVJVhFsy072VULWxv5Sq/iH7Ckdf/EI185g94xLtN7RucmZKLR3DWgPN nt2DrqRWDkEyZ0CCV6ef0Kta2hCRDmD5RdMAP7X4P0SU+/OdAnjQOhPHz4dGKU9AQAB7 26i74CYwmaL2TOIc6NspFzHKp06rtL0GpMveOrWuPt7E6aAZ6E5HKA+S4o/sYLJbMUBr NlVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770651648; x=1771256448; 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:to:subject:message-id:date:from:mime-version:from :to:cc:subject:date:message-id:reply-to; bh=ZuwYtm5GZGaRCkW3KQwEh3xYOhfk+WB0zdwCGtb+2+I=; b=SrQDnwJiRXtrpbFQ2AfvQXpkhCeMraMY20Ni67nwwq8IOe3kzfNA4wmYn8fYWD5CL2 c5rwduEwqZq+e9wPzIBoaVO3l/DGsWxJHK53WskDu4L7KI916FWNuk5zQ5rx+3h1H5VU hndQss6hZV23VRpWdoACuK+5qYTF5B2ZFboIAJkzZ5biB7wsDAuJmZa8d16qeIoxlDbG EwjOKSnFRDe1qUs29fr2B/ktOrL8/2DmLHj+84NgLvHlax6DPGsa/8ehuKK+TPAe0Ynf ZkUdzseuuAMVu6bI0M6LiFQxH5z+S+emNxNrc7pvCzXYCEZsQswKX2bEKKSJ5tkt4+az Jw+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770651648; x=1771256448; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:mime-version :x-gm-gg:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=ZuwYtm5GZGaRCkW3KQwEh3xYOhfk+WB0zdwCGtb+2+I=; b=WaXOjSVcTB/m6adne3THLv2lyuRxpsQqngNz30vryQx+Ln0Avvaq3OZLORHldNmZK5 L8oewoAbv3sqK3HBnyLimTlxD5qLJf98Lluj1/4lwP6Z5oGoz/9SFKyhkhexnliYI5mk CyxYM6PE5Hz36+N6QVRInMLzeYlmi1tfBIIdS0dv+vtFjDCH2MtCrkVx1kM9UWVLMBjV oH9yaRrAwVHBf5fzstcPQm8kKRtlNa0uDAluYHtni+YENAoMzuyt0dwGA/z2syaXkjq+ FQb0R9OJwa48mM4/nejLw6iFlcovWC5mY4W/DYiXoRlmg02GsynBKZ3uENqUVtpFouxK VROw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCW4g2besbcJ3GnHdFnqes4jwHeYr7PJSHr9808wXcdjTKMxoRxADMjcRCtqgOfl1auS+EBoFEfo1GAk@gnusha.org X-Gm-Message-State: AOJu0Yz0ezZMH0CU4G5Zjt3NTZgf+PjwuRUR4DVXVIsQ0rISCJP63J15 EjrT5NC15GPviEGi/LDSkQT2M2yeRAPotyMDEMe3xj0WXA0j+ANJOt5T X-Received: by 2002:a05:6870:7185:b0:409:52d2:8125 with SMTP id 586e51a60fabf-40a96d79157mr5522590fac.13.1770651647890; Mon, 09 Feb 2026 07:40:47 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HVYEEB934yTZ5H1ZvDXkPMUNOM4HVFX3Ddq/kPxZ8nQQ==" Received: by 2002:a05:6871:515:b0:409:4c04:fab5 with SMTP id 586e51a60fabf-40a74e8dc2bls3598219fac.2.-pod-prod-05-us; Mon, 09 Feb 2026 07:40:42 -0800 (PST) X-Received: by 2002:a05:6808:3c4f:b0:450:18a:da41 with SMTP id 5614622812f47-462fca8070bmr6151825b6e.15.1770651642571; Mon, 09 Feb 2026 07:40:42 -0800 (PST) Received: by 2002:a05:6808:a582:10b0:44f:fe66:38a2 with SMTP id 5614622812f47-462fc22be42msb6e; Mon, 9 Feb 2026 06:21:03 -0800 (PST) X-Received: by 2002:a05:6808:1507:b0:45e:a555:4f1e with SMTP id 5614622812f47-462fcb5eeb8mr5588142b6e.38.1770646862393; Mon, 09 Feb 2026 06:21:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770646862; cv=pass; d=google.com; s=arc-20240605; b=hseBO7CzWwEZK+6Nr7Qi9kdjSwHReuQYF6on1py/b/9qXJHuCFHGtvBPTXYQPO7MLJ SzFQEN2TIHwvW6HyNwpp6UySqn1umuFSaneGj0YGDLgbTI5oHLk2+fYzNkoECfsKWQIo WbwOpBw/ihmIv3k9vONyx294fqspSiqcQBBSguuQR7+Dvf9qCJsZQn90ChmabYRPLjTC dawf+Xjz+8BAGLGFWNdZUn23EehayyMAMsnYpMU9pu0WkKp+FZXhe6uV9IOCuLJcpKqA 9Cxkn8w82TTkgUq37jE+cwO1mBGqsbExvaZlIUROqmnhtF2UhHCxQxE9CWGvCvGwD4j7 80fw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=kcWZrxgJm4aKNr+u5UFsLaNTeaBJBJJp+3AV6YmqqY8=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=AiYG9xP6BKHoAfjZX/rVLfFE0pCsu86sg5a8rpF16qoXHlFLS9lxdSI40UWJjJSjpf xJBBWVqA23uSzVxRIwsiyanht5jgSdpOAEpv3+AU2p/7HGaukjBTs6bUiK+0STlqsTtE 8u8vsWar65Yqi4n5/JBgCRmZsmi+aLFh2mOFNGYgxoYIU7zZooXLWd8IItjqXMgS4ZX7 jyyVhc5UrJD9keME7pOG1lxzipaEU4YJ4Xm3IiZhmAHd2/zPdI1Zyz396lvAuKR9nuwX rIKajrYY3WItCL1CJL4gmB/14JA3teA+lqjEENJXeWuSGVPqKvTL1HYoC1bPBw81z8EM IhGA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=eqk15j9E; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1035 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-x1035.google.com (mail-pj1-x1035.google.com. [2607:f8b0:4864:20::1035]) by gmr-mx.google.com with ESMTPS id 5614622812f47-46325fd2047si170139b6e.2.2026.02.09.06.21.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Feb 2026 06:21:02 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1035 as permitted sender) client-ip=2607:f8b0:4864:20::1035; Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-3545d66bb3aso1406560a91.0 for ; Mon, 09 Feb 2026 06:21:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770646861; cv=none; d=google.com; s=arc-20240605; b=YSMD5ccmsmk5bhhQT0pFqzO0frLdZoQmYy5dScQxB2I8g3E/HxzE8HnsHzEtsJULQb FeOG6PxplT2Gzurgp8TpgbNk+AB3iQlLXxZYyJCcvhuMFloT8yok8hbfJGMNsXLWZzhO xIlz/uF6S8Z4+oVGLb2MKr6RBb7A3ibaqI4d/16qdQLe8Nwclx3xiLHYWYBO/zjg5KQv 8iH3UXDgMOpDWhe49sv6KQ9KON+OeYoxfMfo7rdhrRb5AyA8WcA9p5snbVCJOPNGCypO GXlrF62SREdcaPaNuqmJZhXBvvq0PbD4JZenIOr24MwQun7oOyTQ46OS+Se+a85luOCN PUFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=kcWZrxgJm4aKNr+u5UFsLaNTeaBJBJJp+3AV6YmqqY8=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=VhXITyb11GyKecsPDvPb5cJPIC46iJYiiHuhlBDE4ThC+/c6NyNcp10ISgsK+enaBv NIaqb4ACEO5dU6wedQrbXmqfc9EDJhhtP/ZQfh7zu86GRbx1yWmILTdoI9qiopNGB+ss UFNYrKDcOguujNgLiXN5n04D4bAgp/Udc8Xwg9RZhz3oM8bKlss4blY9xleYqvsRgdUj WZlYZjUrr2IGMt9AqgFTso+LsGt5kXF0VXwKfGJtvHUla4g9/iBXGw62a4qFZeIlA8e9 AqPllo5pXqr+a+GqBxEucEYdOG45sap60HSsOlLxBFrwef2IbkxN/b/+bDSK4l738ATR ZTRQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aKYa4Lvmx/nmaUQbPjcM2R3oOrxHUlxYgB96ZQn1pn0rSSEQvxBVDJmnrEHxHQ 4rlXzH5Eoi3O4hVnY5KaZ82o/ugcKIRQ9ho4V/mFbl0OICKKI3Rllc3u18jA2KT3O2tnJ5kSHKe fAc7j1whrLVKzgu0Aq95Q8cSqd+KVKzuXWot8md2CYhPcoP3cRLcwXgBOpT9mrQDnULbFnMoEu+ ej6VMLR2ocUGerdw9BGu8RAiIi5Cl5AM6XNgKicihJpulIjE+wNdZANkPUH22j7pSSroGAUIYgd b0XI1bO2UHku97u968cqbN/+A7aPxeCiWnyjl7/48l7dZbYzKB74Ty5Wv6myEPqQrRPDlWVhWn1 SQ4puCcAhYUjHlwlfE3gwXr1Tdo1bAbFb4XP8EX8c8oRhZ4rXv1Sck1kD5BwBkHixgwd7YGhN+M B4Rud5pFy2oYuimLdqV6dXECZF X-Received: by 2002:a17:90b:3ccd:b0:356:2132:67bf with SMTP id 98e67ed59e1d1-35621326930mr5350983a91.18.1770646860805; Mon, 09 Feb 2026 06:21:00 -0800 (PST) MIME-Version: 1.0 From: Ethan Heilman Date: Mon, 9 Feb 2026 09:20:24 -0500 X-Gm-Features: AZwV_QiB6aP2x7G81l7ul1ayPX-Hr8UOoF9NsdhhegskRdgPIjWxZi0TXdiTYSs Message-ID: Subject: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000293800064a64d915" 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=eqk15j9E; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1035 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 (/) --000000000000293800064a64d915 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 mechanis= ms 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 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 create outputs that =E2=80=9Cfailsafe=E2=80=9D even against an unexpected break in a sign= ature 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 s= ignature 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 alg= orithms 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 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 used for everyday signatures 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 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 safe even if they don=E2=80=99t transition from DSA1 to DSA3 and since DSA2 is s= till 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 concrete 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 long 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 security 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 form 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 if 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 alternatives= 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 CHECKSI= G opcode for SLH_DSA. Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot instead an= d 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 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 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/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. All errors are my own. Thanks, Ethan --=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%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0AwyOkaR%3Dz0Cw%40mail.gmail.= com. --000000000000293800064a64d915 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Howdy list, I want to share my thoughts on increasing the security of Bitcoin to long t= erm threats such as quantum and classical breaks in Bitcoin=E2=80=99s signa= ture algorithms by adding algorithm agility mechanisms to Bitcoin. To quote= RFC 7696: Guidelines for Cryptographic = Algorithm Agility:

=E2=80=9CProtocol designers need to a= ssume that advances in computing power or advances in cryptoanalytic techni= ques will eventually make any algorithm obsolete.=C2=A0 For this reason, pr= otocols need mechanisms=C2=A0 to migrate from one algorithm suite to anothe= r over time.


Algorithm agility is achieved when a protocol can e= asily 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 signa= ture algorithm can be very expensive in txn fees and block space since it i= s for emergency migrations only. This enables Bitcoin holders to cheaply an= d easily create outputs 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-cust= ody coins for at least one human lifetime, ~75 years. Someone should be abl= e to bury an HD Seed in a coffee can and then dig it up in 75 years and spe= nd those coins. No store of value can promise complete safety on long times= cales, but the trust we build by demonstrating that Bitcoin is serious abou= t mitigating long-term low probability risks. Trust and credibility is buil= t 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 fo= cus in the wider cryptocurrency world has been on mitigating the quantum th= reat, 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 cla= ssical breaks that do not require a quantum computer. One particular area o= f concern to me is an unexpected breakthrough in Mathematics driven by AI a= pproaches.
 To address these risks we propose the following des= ign for protecting holders even against an unexpected break in Bitcoin=E2= =80=99s signature algorithms 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, C= HECKSIG_DSA1 and CHECKSIG_DSA2.

Using BIP 360, we could have a= leaf script for CHECKSIG_DSA1 and a leaf script for CHECKSIG_DSA2.<= span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);= background-color:transparent;font-variant-numeric:normal;font-variant-east-= asian:normal;font-variant-alternates:normal;vertical-align:baseline">
=
Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1
Leaf2: DSA2_PUBKEY, CHECKSIG= _DSA2

If DSA1 was broken, users could simply switch to spend= ing 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 t= heir public key to an attacker or reused their public keys. As a user wishi= ng 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. Addi= tionally DSA2 should use a signature scheme that trades off efficiency for = additional security and robustness. This way, we can get the best of both w= orlds, DSA1 can be used for everyday signatures 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 found to be weak, holders are stil= l protected. This is because DSA2 is unbroken, allowing us to replace DSA3 = with DSA4.

DSA1 - Efficient, low cost to use, should support n= ice-to-have features such as aggregation.

DSA2 - Expensive, extreme le= vels of security, only used to transition to new signature schemes.<= /p>

A person with an HD seed buried in a coffee can for 75 years is still s= afe 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 a= nd DSA2 with concrete algorithms:

- DSA1 is Schnorr, the curr= ently supported Schnorr signature algorithmin Bitcoin.

- DSA2 is SLH-D= SA (SPHINCS+ SLH-DSA-SHA2-128s). SLH-DSA is a hash based signature algorith= m. Hash based signatures are the most likely secure long term.
=
<= /span>If we merged BIP 360 and support for a SLH-DSA CHECKSIG opcode, holders co= uld hedge against a classical or quantum attack against Schnorr, while stil= l 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 sc= heme. 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 woul= d 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 wai= ting a little long might buy us a lot. SLH-DSA would provide an effective h= edge against this risk, while delaying the decision of what PQ signature sc= heme should replace Schnorr in the event of Schnorr's security being we= akened.

Q & A
=3D=3D=3D=3D

Q: Could t= hese signatures be abused to store JPEGs on the blockchain?
A: No be= cause they would have no additional discount. This means they would have no= advantage for JPEGs over what is currently possible.

Q: Why n= ot use XMSS or Lamport signatures instead of SLH_DSA?
A: I prefer SL= H_DSA because it is likely to be well supported outside of Bitcoin and Bitc= oin can benefit from this ecosystem of support in the form of HSMs, hardwar= e acceleration and software liberties. That said, it is reasonable to consi= der stateful hash based signature schemes like XMSS, Winternitz, or Lamport= signatures as the fallback signature, especially if size becomes a concern= .

Q: What non-consensus critical changes would be needed to su= pport this?
A; We=E2=80=99d need to create new wallet standards to p= rovide alternatives to BIP32 xpubs. Wallet would have to write code to gene= rate 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 s= upport this?
A: We=E2=80=99d need to merge something like BIP 360 an= d then a new CHECKSIG opcode for SLH_DSA.


Q: Couldn=E2=80=99t yo= u do this without BIP 360 by using Taproot instead and then disabling the t= aproot key spend path?
A: Yes, however this would be confiscatory, s= ince Taproot allows key spend path only outputs. People holding key spend p= ath-only Taproot outputs would have the coins in those outputs destroyed. B= IP 360, in essence is Taproot, without the key spend path. BIP 360 provides= the same functionality as disabling Taproot key spend paths, but rather th= an being confiscatory, it is opt in.

Q: Are you proposing this= now because you think that the Bitcoin signature algorithms are under thre= at?
A: No, I am confident in the Bitcoin signature algorithms and I = know of no immediate threats. This effort is motivated by longtermism and t= hinking 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/2= 025/2203


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

Tha= nks,
Ethan

--
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%2BWTqe8%3DuqChu2vN3HruiJCvFcDMNP%2BJA0Awy= OkaR%3Dz0Cw%40mail.gmail.com.
--000000000000293800064a64d915--