From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 10 Feb 2026 15:25:47 -0800 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 1vpx73-00036v-O4 for bitcoindev@gnusha.org; Tue, 10 Feb 2026 15:25:47 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-40ad1c724dasf11379516fac.3 for ; Tue, 10 Feb 2026 15:25:45 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770765940; cv=pass; d=google.com; s=arc-20240605; b=k/po6g6D/roqDmm9yQmveTD8ShuZNT1Ni0QURoDnrmcSBahAby4Im91Y+hnjvdJ6RG WiJGaeeNdekO1t0NfJO/k7wNgLuRfKd4neYUsh5UBJoW+WucGf0CQYpDf+luiMl4BZo5 zhqWxBHYAmJNaFRwwKTF/0zOxr0a7iNOUC8mDRAbPmpPXSbfA8TqzPd7YrF8ldEkLrSR 0I4FwfSvh0x55K4BkoT8Sv6mRidU4YTz9/SrSjqxDeMlyl+f1irvYr3m/EvcmR2V9Y30 G4BiDBSYGbDJqB5WtvIowUIE9qg8n/XIfZM9LxRysJQQ1+FYMIneSeXueaBM/Xlhwf1l j0tQ== 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=r0OiLu5JkhrIiFh8+m6VCCmcJVmM9n3+bXTUHipoaww=; fh=svzH+PnjNR4be/jcnV3IGstHG3u9raOfSaaWdTHF7sE=; b=PtCk82BXK1JJQTfY/LbQNaZ2wsq3XF3HWkf7zno8ejXoGKqWYZhbQcdWmMkZBHu7Vv hIZ4jMB8JKb8cGTmyYKy3UPGCwCQdb3eSDi91WHPLmheMubSuVKDp7kjvBuoFg7ddMRI ZblejF+jIOgcMyOU+uTfYZRV2ypClFGpFR7OvH0zrI55Kki0M1MQGHzCMr4lEesSQdg3 2Z5Fl5/K7ddbvO4gFnCer1WwFyl1S4xyE8/Dc0irxH6oAIi/D7sxUp2bxLflyZoUWeP2 RFq2mK0ecJ/3wr1jUEX2uv9yJ0OPKnkqFTAycuUMKNmPLBSwJpUEqgkhPjmHpQ7YWuNR CxKQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d7sEHbDN; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 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=1770765940; x=1771370740; 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=r0OiLu5JkhrIiFh8+m6VCCmcJVmM9n3+bXTUHipoaww=; b=Z5FbtQLtm43vt7dEwtrSLj+2R18bD1IIsGGhm5bpIW1q1oBI7yjT6qJ4fArVGhg8f/ 0SVubhKM1fzXIlgznsmPLECwrf5Pxjk3rK1mNRMXkJo56/H1nsx9XrK4Di6mJrEWas0F W8hK82TK0y3PtkkOtLOz75MaKS9r6JX/QQ2AQWnETMe993t8CJunjPROHyWVDN/d9gE3 XNSLbwDv3nAWNTrPFbfHw1mCXDQS1iZ13ykZgBdePN5ocycGHOiRaJXdAWUGkjyMAFP9 wLQnL/6zc4N28PVjJQ9JtYeqZoDRtqTdqygd7WqvtaXc7REMTBk1DwlMXE4z5SSaehgS uo7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770765940; x=1771370740; 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=r0OiLu5JkhrIiFh8+m6VCCmcJVmM9n3+bXTUHipoaww=; b=j/svILkMHZQYIobVQeHjNRAttA64DrakAgzm8LvAx9Drhh/4PKfgPTajD5O+yH0xPV NFsSLMFaBqxOEVDlXVp0HFpR1c8hi+yTvpLTqZgn3YLyvPbAO75RJLHEJG9LWblUmOxi a01M7or6Bh7j+y3mBcuPDFfO7Mwc0hhry3Jgar9iJtA6oLRrqXPJhfAgAd71z0PSZBkP 6sKdapLu1LLSbWQBcoVjDItaBZyN17Fb+CCukvtNe0rf9zuyHkmsjqQFTzrX156o1Qk/ wcFmUzgF2Mic0xY+9GmtwOyxdeum9bDUDqRZ2pD5KOFFnUfejRx2QcGpHrEpydsD9/YZ pVdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770765940; x=1771370740; 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=r0OiLu5JkhrIiFh8+m6VCCmcJVmM9n3+bXTUHipoaww=; b=j2JakT78W0ftXTgAyV5TvRn1RDYegihnt7BnV5wVRqC+accu3bKnv8cHG0nOL8EYGx DD6rsSHi8Wr9WxT5Xz2w+J9nMOV8r2QMtFRNKxgrzvhE0GPDlrx7OLow7wjXBnedb/ZI GkU6+Uy7l+/jm3aOn7YL7E/UClgWkt8TtTbOf/YIqO2RiAFoSn5v12SN5rKM9+4aJyP0 MLD/rgRFCgG3ssO6fmcmEwZ3TZxMtrkzk4pPWcS26u+8Q8l7tXAb8saareVTeZRGZFwi BHNx/strSZFdXp8zlOqyVQJJEXHJzrVhV9i5caEJI+aP6KXT3Q35ug1FSXpuqJLlkczb GQyA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCWW4lOUkTqYpOSr4gIRvmKFD20mtVuJlfv25rAiEQ3Ft7ztP+ZLIjB8B+ApzLH/5UBJhxY0PwV4pFf6@gnusha.org X-Gm-Message-State: AOJu0YwbeycCokcZ9k6z0mFqNqOnEj3d2/Ukq1V0QZi8Neh5qRFZwZZF rv4FzNXLw0gYQ5nCGOMhqw3uZ16r0EMf9boI7I1XmZtMVvPJyKrej75D X-Received: by 2002:a05:6870:84c8:b0:409:6877:ca77 with SMTP id 586e51a60fabf-40eaf7119dbmr25206fac.19.1770765939243; Tue, 10 Feb 2026 15:25:39 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FWQnAfstw0emuNt0vp0Do9qKMLyAQD08vpe6W1qvv9yA==" Received: by 2002:a05:6870:e9a1:b0:40a:60d4:63ab with SMTP id 586e51a60fabf-40a74be496cls4613120fac.2.-pod-prod-01-us; Tue, 10 Feb 2026 15:25:35 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUzybT1krLUySb/MCwzkbDcfA340Rbn4/0u1nKclA5zIWoEtsr8Jzf3LayxmRu1Ac+CxedwnkVDKb1j@googlegroups.com X-Received: by 2002:a05:6808:c40c:b0:450:cfd3:cfba with SMTP id 5614622812f47-4636950de93mr175863b6e.57.1770765935688; Tue, 10 Feb 2026 15:25:35 -0800 (PST) Received: by 2002:a05:620a:1b98:b0:892:e292:65ef with SMTP id af79cd13be357-8cace8d312bms85a; Tue, 10 Feb 2026 15:13:57 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCV1cdQHw0h5plZ48/JaDOcqQ5oS8gES4hM0SMNHziptTiHxOhrzvM7B3UHJYws7HZVnXu0+pQjNZ8+I@googlegroups.com X-Received: by 2002:a05:6102:3047:b0:5f7:2474:eb9 with SMTP id ada2fe7eead31-5fde9406b6emr1518137.21.1770765236163; Tue, 10 Feb 2026 15:13:56 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770765236; cv=pass; d=google.com; s=arc-20240605; b=NIdXfvvGEM4/fNRr5l34ZhaxDKEfeHnhtdytEgbK8Kxq0JPfPkmDELWjR9lhpg829X roAQ8OKbikbJyLBlnwklPm+5qtgO7LmscJMWtDwQIYfeGIkJ8czZKG+VxEhz0OQ/ImI7 Qd5Fg8QoAJObav6gmVfbRhbw+wmA1+EVHs0PupyfbGzKCPvi2IxZzewZrMf+0VIVKnyP yRZLlS39P3G+AZc1oKjFfCor9/8Q0pxwLfOlAWvOlTvOCJVSZUhvD2CL5y1TNAJyp4pG haBnF5d7N7cyu7QeP4iXc1g1zScuKy1YKs4e9mTa+Ksf5IP4nZk9VkTRbmBge1s7lyvC CWiA== 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=hZet+vWrMHIXv/qs7ExdFam0NcuVch5MOCifU2VjHnM=; fh=0tQknHQTuINuNDzmaP3l6oNF1bxnq2oDmCHwymD7r3Q=; b=DRNAeURfezcykwr0QTr8TFMh4siD9fClULnWD+iFhpIfGjnBZwH2cq4dMEp5u12pqY Hykxcp/hIC70aR3d3ZTtHmfF23YqgVIbExRM32zL45+ivlY2sWCiN/LwcdD224VF3A55 856IaHJ4M7C5PCIfyhnmBtFpSCCRgXFa8vlrYvbFdtTcgel8UJ+lncHHErop8GcgsBB0 tVBoMnw3YokMDwOvXpVqrfjtqZxud5lmBhbY9U9wE/L/eW81AREnyAgIEdvL0sD96XSY jh5oz0BCi8OGHzRb6+RsrCkbKp/5T1Nx4R2dmXuLJJloGM2aDGkd5ohovMdFld6DMOUr 6iHg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=d7sEHbDN; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 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-x1033.google.com (mail-pj1-x1033.google.com. [2607:f8b0:4864:20::1033]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-94afd1d94f8si10388241.2.2026.02.10.15.13.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Feb 2026 15:13:56 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) client-ip=2607:f8b0:4864:20::1033; Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-352ccc61658so2955944a91.0 for ; Tue, 10 Feb 2026 15:13:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770765235; cv=none; d=google.com; s=arc-20240605; b=Pmf/Mz4LxL9QpBlF/MGJ1LVEfeLvU4HL1yMZVsm3v06yut+CVZSmbKlpBKwfcUfRO7 e29+7g7mu5l5voQfWnFQfJ7Il/fCRWPNZne60olQSJctzIpjUQ47iMPKga3kqN3yIVkI Set8QxReTHxGu0sYuCAxfZkrxruQzPqMdCbOLR6BAKjMPonmiXmco/fnOv+DiBFbLGHE tSaUzWwvapN4+JKsVzZvpiJkdtz4bgjDfp9MzJvfsOklNGn/NFtawaHNtf0ECsN4OcQ7 tyEgc3x0mbr+rwRbiEVD3J5oRgTN0d8wb4MSRLm8EChseVbsJpG4LD9YWucX08fN/o2d 4gtA== 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=hZet+vWrMHIXv/qs7ExdFam0NcuVch5MOCifU2VjHnM=; fh=0tQknHQTuINuNDzmaP3l6oNF1bxnq2oDmCHwymD7r3Q=; b=GwVxSuYjfRbwVAUFI0SoYpIvfmU7EWHyo8B+TfZ6M2YFz1atTBFEq4euzFx/x+CA+x 57jWjvsW8XsOECyeX7HHqFUzNqsnTH0XJnQMXdmSA0EGLj6cmjL3+hc2/FceHH9MwFkJ rYB4zuWzhF1qyns4K4fzpV4RVz/v8oaMLkTQW21mIDJ4E6GNJCEhk0ii4W3rGL8tOVZP IfRuZQStt/ogYc7tZChYecFp15foV0zYqdyXyqAC8f5GU57INkmpo9dQfzol09EmLEKm YHJ/RGbT5Nk0qXGKqKT2ZFtFFTE7ZFcHDs4uGaBX9nl4a57cGtV2aTKHrETsPEmHHg5m pJKw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCUO4Egadc3mQEvXycCZHWFq+mi2Gln6Hi5CgyzQAz6fVnmdKjJblQ//CjX8ZbVi1J8ADRTjQxgHyom+@googlegroups.com X-Gm-Gg: AZuq6aJyMJ8138EdrdTc0j5rOzkX309y3G5gZamb0rebOyXePZ9j6YKWRLqrt6pZTeF 5YKM59FfgqqOu0ROe8qdga3wjyYmfSVxkCccbcjvI+KuOtn2a38fvJQTzEDufrWIG6Lw1fMUlHo U1kOyEEq21ypexZUtZ6y+PvUru/g86DwWYTuPKAozkorr7EE5765j3MER6jJK9vAMZf9TI7RDg+ 4+uD/BbscYivRejl4gRHvOdM1h6xHOVGWVeCpp+xBLaNnses576UI4KwIeP4ogzvobb+qk2EfgK u9PqwbYu20Qbidtw+eCcFMSmi+J/vHgRCz3OuyzkOMGcj1zH5JWXZ6VVk9K4Nj81g3ajY2svNrO m2ExdFq4zFEBTfM7158JBUhdDbakOzVzBrCPU2gHB4BpLwmmW9M5Q0Ifb3FE0d5z2aQrKm3Pg7O 1q1/sNINKobbHPHPxoZ0/YAyG2lw== X-Received: by 2002:a17:90b:4f84:b0:356:2eff:deff with SMTP id 98e67ed59e1d1-3562effe224mr8447563a91.15.1770765235041; Tue, 10 Feb 2026 15:13:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Tue, 10 Feb 2026 18:13:19 -0500 X-Gm-Features: AZwV_QjSpIcBKp2llqkWgDPMPoS13UCjury4LC-Z1ucXQX_l4J7Zr3wAlXhS7l8 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: Erik Aronesty Cc: Jonas Nick , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000d0b7d5064a8068e9" 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=d7sEHbDN; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 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 (/) --000000000000d0b7d5064a8068e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > or we can just allow on-chain covenants (txhash) that can trivially make secret-reveal scheme paths secure without signatures You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript, and the only available tapscript supporting output type, P2TR, isn't quantum safe. I'm going to assume: - you mean to use this commit-reveal for migrating between signature algorithms, not for everyday use, - TXHASH is being used because you are waiting for the commitment to be confirmed on-chain rather than lifeboat's out-of-band commitment system The main disadvantages of using commit-reveal in this manner are: Once you post your commit-txn, but before it confirms, other parties can post competing commit-txns that double spend your output. If one of malicious transactions confirm, you must now wait for a timelock to expire and then try to post your transaction. They can block you again. Each time they burn some of you coins in fees. Miners get the fees, so they might be incentivized to do this. Thus, we must trust miners not to do this. Lifeboat doesn't have this issue since it uses out-of-band commitments, but out-of-band commitments have their own issues. Miners are now trusted more, since reorgs can steal funds. I prefer SLH_DSA over commit-reveal as it preserves Bitcoin's trust assumptions and user expectations. I see commit-reveal as valuable for the case where our signature algorithms weaken rapidly and we don't have time to push through a more complex solution. On Tue, Feb 10, 2026 at 5:06=E2=80=AFPM Erik Aronesty wrote: > or we can just allow on-chain covenants (txhash) that can trivially make > secret-reveal scheme paths secure without signatures > > adding a flag that opts-in to path disablement on "q day" is nice because > 99% chance it will never be needed, but is a good safety valve > > > > On Tue, Feb 10, 2026 at 12:49=E2=80=AFPM Ethan Heilman = wrote: > >> Appreciate your feedback on this proposal, Jonas >> >> > I agree that reusing an already standardized scheme like SLH-DSA has >> the real benefit of building on an existing ecosystem and allowing for >> faster deployment. The downside is that SLH-DSA is less efficient for >> Bitcoin than alternative hash-based signatures. >> >> I want to introduce some new terminology here: >> >> Everyday signature algorithms: These are the signature algorithms users >> employ for daily transactions. >> Backup signature algorithms: These are signature algorithms used to >> migrate from a broken everyday signature algorithm to new everyday >> signature algorithm. >> >> I agree that for the everyday signatures we need something much smaller >> than SLH_DSA's 8kb signature. If we expect everyday signature algorithms= to >> weaken at a rate requiring replacement every 40 years, backup signatures >> will represent a very small fraction of Bitcoin signatures, making their >> size less important. Even then, if a break in a everyday signature >> algorithm is not unexpected, we can use everyday signatures to make the >> transition to the new everyday signature algorithm. >> >> The most likely use for backup signatures is for someone who stored thei= r >> BTC in an output for 50 years, didn't move their coins when the everyday >> signature algorithm was weakened, and then didn't move their coins when = it >> was completely broken. Say someone who put their coins in a safety depos= it >> box, got sick, died and their estate now wants to safely move the coins. >> They would use the backup signature to move to a new output because ther= e >> is no other safe option. >> >> > Those costs are therefore a more binding design constraint >> than ecosystem support, which can be built up over time through focused >> effort. >> >> I agree with you here, as long as we constrain ourselves to everyday >> signature algorithms. Backup signatures should optimize for security and >> standardness. >> >> > If Bitcoin disables Taproot key path spends before Q-day, then doing >> this via Taproot instead of BIP 360 would be preferable. >> >> I worry about making the transition to quantum-safe outputs depend on a >> contentious debate over a confiscatory soft fork. Uncertainty over wheth= er >> the soft fork would be released and if released would be activated means >> that wallets and custodians are unlikely to have invested the resources >> into upgrading to support script only P2TR. >> >> The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that it >> avoids this controversy by being opt-in and non-confiscatory. This also >> means that BIP 360 + SLH_DSA is likely to activated early, allowing >> wallets and custodians ample time to build support after activation. >> >> > We could define a new SegWit version that is a copy of Taproot. The >> new version number simply signals that the owner consents to a future >> deactivation of key path spends. Unlike BIP 360, this >> approach would still require actually disabling the key path before >> Q-day, but it is not confiscatory and allows using Taproot's benefits un= til >> then (with a privacy hit from having two versions of Taproot in parallel= ). >> >> Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved fro= m >> this P2TRD idea, to minimize the following hazards in P2TRD. >> >> 1. P2TRD requires a soft fork that depends on accurately predicting >> Q-day or when EC Schnorr is classically broken. We must not only predict >> Q-day but also convince the community that the prediction is correct. If= we >> mess up the timing, Bitcoin is significantly harmed. This means that peo= ple >> will constantly be yelling that we are messing up the timing. It will ma= ke >> quantum FUD worse not better. >> >> 2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users must >> create a script spend that replicates their key spend, But users and >> wallets are likely to screw this up and not create script spends. The is= no >> way to see if a wallet is actually creating the script spend on the >> blockchain. >> >> 3. To be safe from long-exposure attacks P2TRD can't use the same public >> key for the script spend as the key spend. Since wallets will prefer the >> key spend to the script spend, a user might not realize if they lost the >> keying material for their script spend until after activation. >> >> Hazard 2 and 3 make harzard 1 worse by making the Q-day soft-fork to >> disable key spends in P2TRD more controversial. Imagine a giant custodia= n >> finds out all their coins are burned after the soft fork activates, they >> might bribe miners to unactivate the soft fork to give a chance to move = the >> coins. That probably won't happen but why take the risk? Signaling a >> willingness to take unnecessary risks could also harm Bitcoin's credibil= ity. >> >> Additionally, by only having script path spends in BIP 360, wallets who >> want to claim to use BIP 360 support must actually build script spend >> support. Users will know that their script spends work because they are >> actively using them. >> >> BIP 360 +SLH_DSA solves problem 1 by never allowing key path spends in >> BIP 360 outputs. This allows us to reach quantum safety without having t= o >> predict Q-Day. This also allows Bitcoin to demonstrate it is quantum saf= e, >> rather than the hopes of quantum-safety depend on an uncertain future >> soft fork. This settles the safety issue early, removing the risk of a >> Q-day soft fork disaster and calming fears about such an event. >> >> >> >> >> >> >> >> On Tue, Feb 10, 2026 at 4:11=E2=80=AFAM Jonas Nick wrote: >> >>> Hi Ethan, >>> >>> Thanks for the thoughts. A few comments on the specifics follow. >>> >>> > I prefer SLH_DSA because it is likely to be well supported outside o= f >>> Bitcoin >>> > and Bitcoin can benefit from this ecosystem of support in the form o= f >>> HSMs, >>> > hardware acceleration and software liberties. >>> >>> I agree that reusing an already standardized scheme like SLH-DSA has th= e >>> real >>> benefit of building on an existing ecosystem and allowing for faster >>> deployment. >>> The downside is that SLH-DSA is less efficient for Bitcoin than >>> alternative >>> hash-based signatures. >>> >>> If this is not intended to be a short-term solution, efficiency >>> considerations >>> (e.g., ~50% smaller signatures) likely outweigh the benefits of an >>> established >>> ecosystem. While the Bitcoin space does have the ability to standardize >>> new >>> efficient schemes and invest in software libraries and custom HSM >>> support, the >>> verification resource constraints of the entire Bitcoin network are muc= h >>> harder >>> to influence. Those costs are therefore a more binding design constrain= t >>> than >>> ecosystem support, which can be built up over time through focused >>> effort. >>> >>> > 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 outputs. >>> >>> If Bitcoin disables Taproot key path spends before Q-day, then doing >>> this via >>> Taproot instead of BIP 360 would be preferable. It would allow users to >>> benefit >>> from Taproot's efficiency and privacy properties until key path spends >>> are >>> disabled. >>> >>> There's also an alternative that Matt Corallo mentioned to me recently >>> which I >>> haven't seen discussed on the mailing list. We could define a new SegWi= t >>> version >>> that is a copy of Taproot. The new version number simply signals that >>> the owner >>> consents to a future deactivation of key path spends. Unlike BIP 360, >>> this >>> approach would still require actually disabling the key path before >>> Q-day, but >>> it is not confiscatory and allows using Taproot's benefits until then >>> (with a >>> privacy hit from having two versions of Taproot in parallel). >>> >>> -- >>> 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/ea3a12db-e3fd-44b2-a22c-b9= 60ed7ec6d3%40gmail.com >>> . >>> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BU_PV7dA5Azr7D4Rn= r40QaHKUrxdLmx0zPPjYoE-HZ%3DHw%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%2BWdPbjVH24Bhb9pJGFoHe0k7%3DJRwG9VU49%2B7ZeCip0Csg%40mail.gmail.co= m. --000000000000d0b7d5064a8068e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0=C2=A0 or we can just allow on-chain covenants (txhash) that can trivially make se= cret-reveal scheme paths secure without signatures

You'd still n= eed=C2=A0 BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript, and the only avail= able tapscript supporting output type, P2TR, isn't quantum safe.
I'm going to assume:
- you mean to use this commit-reveal for migr= ating between signature algorithms, not for everyday use,
- TXHASH is be= ing used because you are waiting for the commitment to be confirmed on-chai= n rather than lifeboat's out-of-band commitment system

=C2=A0The= main disadvantages of using commit-reveal in this manner are:

= Once you post your commit-txn, but before it confirms, other parties can po= st competing commit-txns that double spend your output. If one of malicious= transactions confirm, you must now wait for a timelock to expire and then = try to post your transaction. They can block you again. Each time they burn= some of you coins in fees. Miners get the fees, so they might be incentivi= zed to do this. Thus, we must trust miners not to do this. Lifeboat doesn&#= 39;t have this issue since it uses out-of-band commitments, but out-of-band= commitments have their own issues.

Miners are now trusted more, sin= ce reorgs can steal funds.

I prefer SLH_DSA over commit-reveal as it= preserves Bitcoin's trust assumptions and user expectations. I see com= mit-reveal as valuable for the case where our signature algorithms weaken r= apidly and we don't have time to push through a more complex solution.<= /div>

On Tue, Feb 10, 2026 at 5:06=E2=80=AFPM Erik Aro= nesty <erik@q32.com> wrote:
or w= e can just allow on-chain covenants (txhash) that can trivially make secret= -reveal scheme paths secure without signatures

adding a flag that op= ts-in to path disablement on "q day" is nice because 99% chance i= t will never be needed, but is a good safety valve



On= Tue, Feb 10, 2026 at 12:49=E2=80=AFPM Ethan Heilman <eth3rs@gmail.com> wrote:
Apprec= iate your feedback on this proposal, Jonas

>=C2=A0 I agree that reusing an already standardized scheme like SLH-DSA has the re= al benefit of building on an existing ecosystem and allowing for faster dep= loyment.=C2=A0The downside is that SLH-DSA is less efficient for Bitcoin th= an alternative=C2=A0hash-based signatures.

I want to introduce some = new terminology here:

Everyday signature algorithms: These are the s= ignature algorithms users employ for daily transactions.
Backup signatur= e algorithms: These are signature algorithms used to migrate from a broken = everyday signature algorithm to new everyday signature algorithm.

I = agree that for the everyday signatures we need something much smaller than = SLH_DSA's 8kb signature. If we expect everyday signature algorithms to = weaken at a rate requiring replacement every 40 years, backup signatures wi= ll represent a very small fraction of Bitcoin signatures, making their size= less important. Even then, if a break in a everyday signature algorithm is= not unexpected, we can use everyday signatures to make the transition to t= he new everyday signature algorithm.

The most likely use for backup= signatures is for someone who stored their BTC in an output for 50 years, = didn't move their coins when the everyday signature algorithm was weake= ned, and then didn't move their coins when it was completely broken. Sa= y someone who put their coins in a safety deposit box, got sick, died and t= heir estate now wants to safely move the coins. They would use the backup s= ignature to move to a new output because there is no other safe option.
=
>=C2=A0 Those costs are therefore a more binding design constraint than=C2=A0ecosys= tem support, which can be built up over time through focused effort.
I agree with you here, as long as we constrain ourselves to everyday signa= ture algorithms. Backup signatures should optimize for security and standar= dness.

>=C2=A0 If Bitcoin disables Taproot key path spends before Q-day, then doing this v= ia=C2=A0Taproot instead of BIP 360 would be preferable.

I worry abou= t making the transition to quantum-safe outputs depend on a contentious deb= ate over a confiscatory soft fork. Uncertainty over whether the soft fork w= ould be released and if released would be activated means that wallets and = custodians are unlikely to have invested the resources into upgrading to su= pport script only P2TR.

The benefit of BIP 360's P2MR (Pay-to-Me= rkle-Root)=C2=A0+ SLH_DSA is that it avoids this controversy by being opt-i= n and non-confiscatory. This also means that BIP 360=C2=A0 + SLH_DSA is likely to activated early, allowing wallets and custodians amp= le time to build support after activation.

>=C2=A0 We could define a new SegWit version that is a copy of Taproot. The new ver= sion number simply signals that the owner=C2=A0consents to a future deactiv= ation of key path spends. Unlike BIP 360, this
approach would still requ= ire actually disabling the key path before Q-day, but=C2=A0it is not confis= catory and allows using Taproot's benefits until then (with a=C2=A0priv= acy hit from having two versions of Taproot in parallel).

Let's = call this=C2=A0 P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved from this P2TRD idea, t= o minimize the following hazards in P2TRD.

1.=C2=A0 P2TRD requires a= =C2=A0soft fork that depends on accurately predicting Q-day or when EC Schn= orr is classically broken. We must not only predict Q-day but also convince= the community that the prediction is correct. If we mess up the timing, Bi= tcoin is significantly harmed. This means that people will constantly be ye= lling that we are messing up the timing. It will make quantum FUD worse not= better.

2.=C2=A0 P2TRD (Pay-to-Tap-Root-Disablable) to be non-confi= scatory users must create a script spend that replicates their key spend, B= ut users and wallets are likely to screw this up and not create script spen= ds. The is no way to see if a wallet is actually creating the script spend = on the blockchain.

3. To be safe from long-exposure attacks P2TRD ca= n't use the same public key for the script spend as the key spend. Sinc= e wallets will prefer the key spend to the script spend, a user might not r= ealize if they lost the keying material for their script spend until after = activation.

Hazard 2 and 3 make harzard 1 worse by making the Q-day = soft-fork to disable key spends in P2TRD more controversial. Imagine a gian= t custodian finds out all their coins are burned after the soft fork activa= tes, they might bribe miners to unactivate the soft fork to give a chance t= o move the coins.=C2=A0 That probably won't happen but why take the ris= k?=C2=A0Signaling a willingness to take unnecessary risks could also harm B= itcoin's credibility.

Additionally, by only having s= cript path spends in BIP 360, wallets who want to claim to use BIP 360 supp= ort must actually build script spend support. Users will know that their sc= ript spends work because they are actively using them.=C2=A0=C2=A0

B= IP 360 +SLH_DSA solves problem 1 by never allowing key path spends in BIP 3= 60 outputs. This allows us to reach quantum safety without having to predic= t Q-Day. This also allows Bitcoin to demonstrate it is quantum safe, rather= than the hopes of=C2=A0q= uantum-safety=C2=A0depend on an uncertain future soft fork. This set= tles the safety issue early, removing the risk of a Q-day soft fork disaste= r and calming fears about such an event.






<= /div>
O= n Tue, Feb 10, 2026 at 4:11=E2=80=AFAM Jonas Nick <jonasd.nick@gmail.com> wrote:<= br>
Hi Ethan,

Thanks for the thoughts. A few comments on the specifics follow.

=C2=A0> I prefer SLH_DSA because it is likely to be well supported outsi= de of Bitcoin
=C2=A0> and Bitcoin can benefit from this ecosystem of support in the fo= rm of HSMs,
=C2=A0> hardware acceleration and software liberties.

I agree that reusing an already standardized scheme like SLH-DSA has the re= al
benefit of building on an existing ecosystem and allowing for faster deploy= ment.
The downside is that SLH-DSA is less efficient for Bitcoin than alternative=
hash-based signatures.

If this is not intended to be a short-term solution, efficiency considerati= ons
(e.g., ~50% smaller signatures) likely outweigh the benefits of an establis= hed
ecosystem. While the Bitcoin space does have the ability to standardize new=
efficient schemes and invest in software libraries and custom HSM support, = the
verification resource constraints of the entire Bitcoin network are much ha= rder
to influence. Those costs are therefore a more binding design constraint th= an
ecosystem support, which can be built up over time through focused effort.<= br>
=C2=A0> Q: Couldn=E2=80=99t you do this without BIP 360 by using Taproot= instead and then
=C2=A0> disabling the taproot key spend path?
=C2=A0> A: Yes, however this would be confiscatory, since Taproot allows= key spend
=C2=A0> path only outputs.

If Bitcoin disables Taproot key path spends before Q-day, then doing this v= ia
Taproot instead of BIP 360 would be preferable. It would allow users to ben= efit
from Taproot's efficiency and privacy properties until key path spends = are
disabled.

There's also an alternative that Matt Corallo mentioned to me recently = which I
haven't seen discussed on the mailing list. We could define a new SegWi= t version
that is a copy of Taproot. The new version number simply signals that the o= wner
consents to a future deactivation of key path spends. Unlike BIP 360, this<= br> approach would still require actually disabling the key path before Q-day, = but
it is not confiscatory and allows using Taproot's benefits until then (= with a
privacy hit from having two versions of Taproot in parallel).

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ea3a12d= b-e3fd-44b2-a22c-b960ed7ec6d3%40gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit ht= tps://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BU_PV7dA5Azr7D4Rnr40Qa= HKUrxdLmx0zPPjYoE-HZ%3DHw%40mail.gmail.com.

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