From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 11 Feb 2026 10:43:25 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqFBM-0003xB-BE for bitcoindev@gnusha.org; Wed, 11 Feb 2026 10:43:25 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-4094f9a49a1sf10220887fac.1 for ; Wed, 11 Feb 2026 10:43:24 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1770835398; cv=pass; d=google.com; s=arc-20240605; b=B7kIk20iYF4rBltRu8d5aN+Y7hpm3Vd066F64XvcD6Ui55pUZRGKlcTZs8WFHq6jx6 3R3URLT5YoRpAHu9UyWO1904pzeCtbwZquCF5j/Y9w7lWc00Dxt7fNCZlwrYL9bllgU3 /sDobzM186PMmYlB3BMHCW4NLVKjZFtlntTLPGqNxzfuE5sFfyVRnR2W/5aVrosiRmPD Fi32BT499bklkd4aGn+ZdGUzM37BrgcyZd9XsqJqRnRFDg/d+b69iU7cIrAZ0oCMhvQr 2Q8iRPNAJdcoNwKM8Db65OsnJQeQ5OyDxD3LoihQSmZ/YHNDLU4dwpsvHhX6fg5ecvRz wLfQ== 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=RTEeDNDbcDP4zBgT4q5Cp4zD1Qe9ECPQoJKd92u/AMM=; fh=WRyH2A6hSEG8MClMNvLpKNNuKAUqVjYsuFNZNm28xWk=; b=FTECO4HSxkV2vLS0WWnZlx6CS3tTuTFjjfoGI2CN5H4cukkMVJB8tzsBnDy0gxCmaq qw5LT+gJbOyw5TZPov4hAPDl2VwxVRRdzvP7nEqsCwsUmMB+0J+n9+iQV9iG4ayEy6L+ pt3CcgBC1aaguFeeWAvHdcfqTEtGtlOTaoh2WirnTWdw6xAYPYZGS7cpxhawu1eLwfb+ 4iogFCqEgMXh8i/mSFb+F+wTq3/GTiQ9XyhVY7bJPkW/6rUlA/0G1NM6whD6gEAmW70c JPAI+wK5REd22+B8SH7QC9eCdT976pgZs/rbdyqPwlnPA/c77chDKdeu8BpbDVMeouvp iYRQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Ii7JuTbs; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1036 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=1770835398; x=1771440198; 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=RTEeDNDbcDP4zBgT4q5Cp4zD1Qe9ECPQoJKd92u/AMM=; b=uahQXMmc9cNApcEFMJQaCxch7kyz8LDHNJQNTcZhRV0bW9bu2I/DkyUrTaSSWmnn/t OTfVi8KhayaNn54CJDOXvg4IV06nJ4u5LuwkIDrGlT0/bn1NaSp/pqV0vDMiY+RNuLqk PdW7ass9xWOHT8R7Yi4Gl9Xa2QGSqz2iisxxfKTa4nb99IXfZRac50+vcRblkVRSZz+6 vD00PMF9/lmcH+M1fqqwYSqMcL47vadcDsFirg+kjERlsY7j85elVc7Iey+CwJYfGqib 4v0vomoWPP5M5H95c1Akl6LJ0XeDJmmBWfYqE5C+2Re4n3cOA2FUKTnTHrEBJjkJsNgH 1/WQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770835398; x=1771440198; 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=RTEeDNDbcDP4zBgT4q5Cp4zD1Qe9ECPQoJKd92u/AMM=; b=foxX+gY7I7QEqEVLHsgpsi+yr19bYcrNTVX6vvM7CfuoiCg0E59VrdZCZcJafMk3xU lqD5nidsmMm3cwEkNdlpurUbLasVsafOn5raLf7lsrzRH+ktOfegyxBB29H1Mt0z/rVe OSgbFAyn0ZNQ12ZnBc0L8EVDqBqbk9vvdwhN1GefUBw1saYkfNCKxX4XvxxRlR7xFmpS VYPVfCNTBf1YhMsWx5W/YWjee1EXlV0H+0t8CrQD3RUi1icvBoHYj/HdEprcNkqgRdde ge0fH2t76MtYLISpM504HTWfTJvZPhyFxdXNOzKT61YwW+OausJhprt6n/G8ZSfWV/pb gpAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770835398; x=1771440198; 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=RTEeDNDbcDP4zBgT4q5Cp4zD1Qe9ECPQoJKd92u/AMM=; b=gJQfGXF6oMkWGhyokei1570JezFX/coadTFxzG8v88vVF/w/70innVdNxp5BiqIhl4 unYl3YK/Ex2+/+Ew1Ei39KeoGdXggMqCsQsRRgw1rFPnGp5vEvsJdw90mCMhiJR0pw3v yrv3hJ0QukeOvloSG9qagJMqJLQFtP2OB3n4sxzMBq55MT1F/MKZdtudTxnvu9JqFHNU QZyzFHk6yBWq5CW4nLzVN8CLsT0PUojjYhABN294D/K7yFwHBQtr8CiKlP9vSQAiGhF1 wu1I2RMJMjfHU1PVAdVyJSy3L42VRB4BUt7xIyDo1jbwp0rI/thcR2w6SzeLvRgRP5kb 6swA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCWFGNdgFg1zvC/WUewmldM64cKx4X8UHyb8T9B3DzyEKtljJJVlqQ4DQ7jILxFo0EyXvWy3Jif0oHG6@gnusha.org X-Gm-Message-State: AOJu0YyS55xdxMOgIaPPYnpSePSwDZ4cd97kz/w3wfyolbFFb+13q7rv 5Udp3d/nPaN7RwqhAPV4/TuG1R2cW85dCEU2Kjj4KbQ0ggAZWcZow8JN X-Received: by 2002:a05:6820:1ca5:b0:663:46f:603f with SMTP id 006d021491bc7-67598f12025mr113738eaf.22.1770835398187; Wed, 11 Feb 2026 10:43:18 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HID98tccsXUZAjSuPUD0mnvyl3VgAiQO/itHqibgcfSQ==" Received: by 2002:a05:6871:e803:b0:408:8d90:8644 with SMTP id 586e51a60fabf-40a74430645ls4732102fac.0.-pod-prod-08-us; Wed, 11 Feb 2026 10:43:13 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWmNE3gTBzq5CjWt83/Nnif+DjNH86mbys6Xo3TzXO9HUBq0kKKO8eR0qQbcnTkDRJcvfntx/XlF0n3@googlegroups.com X-Received: by 2002:a05:6808:6410:b0:45c:832a:cf43 with SMTP id 5614622812f47-4637b66eefdmr179639b6e.14.1770835393608; Wed, 11 Feb 2026 10:43:13 -0800 (PST) Received: by 2002:a05:6808:31c8:b0:45f:66d:3206 with SMTP id 5614622812f47-462fc4f847bmsb6e; Wed, 11 Feb 2026 08:38:18 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXNamVIevg4R14WQK4r91XKu+VDppiTPRd0/UQdssKtxoSD4feHYRorU5Q4Zkr4TaMEDQ71GgH8QWkJ@googlegroups.com X-Received: by 2002:a05:6820:1502:b0:66a:6f80:1990 with SMTP id 006d021491bc7-66d0a47953bmr9287226eaf.25.1770827897214; Wed, 11 Feb 2026 08:38:17 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770827897; cv=pass; d=google.com; s=arc-20240605; b=RAW096lzPmeYUB/nqoA5HwPQa9A3dlFyn0vPdyY8XOdzlCu9p1PSC2YlxNNPwhqhOm Y8+sWsCVDodqVBmx0nkfDREVQgf36P4xqgEQ9dMAnonvXo+E/RE833X2iVAKBbL6MTzH pin6/eO92AHh7SSOOxoZTqmAxTSXUgcSFdUV57wxbg8FT3cpi80dfgAR8TjoVzEDB4ao 1PPvjmWg1SCH3rnwEZRbuUdRexgh3oxuiTYUpZdRPBziY5AVZ2G+K2zJ35N7CYDXU1ya LHAYTG3uiQ2Ezxli+nnyJYawV7q/AGXkcTfV/qCebViworPhggDgxBKU24vzUovWYecF UO1A== 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=J9+9uRRBAGWz5X7TxvVtFsTx7Vy8WDityDu9RJu27Wo=; fh=XVix52929F1W5Sf3uNG7KPw+PeG2ro2I0vKFiukTrLc=; b=eBRZrLW/SwS1HF9C/8Y2sqnUnVLQpE9FvnyVaZ1jGgzYqNnLRyLEW7DrJnPUlF/pzG 40zetC+RoPw5MPtzCfJsSn8O/7tdS0cUxjHGbxT2GPktUYpkrz8RNZZMRn8BzB9bmHhE iAWNL0Bgrjd6iDKAFurlNLoIUzGe4J/eT4OFyJT9Yb5OJdAmfecuD8b7dMxebm1GBxZZ Wrwz35BTaAb5v4OWXCPRb24tZYDBpMdB5vUIGdUzNowJyukk6oU1LcjPcL4FHKRdvFi8 2yVMEH61A5k3aMjmzOXfPPEzYc7ZXAMo2yh/+bN4iB9r0BpTd7/rd9VOyJLCDaA7y4x2 VUCQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Ii7JuTbs; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1036 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-x1036.google.com (mail-pj1-x1036.google.com. [2607:f8b0:4864:20::1036]) by gmr-mx.google.com with ESMTPS id 006d021491bc7-67472f10cc9si74940eaf.1.2026.02.11.08.38.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Feb 2026 08:38:17 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1036 as permitted sender) client-ip=2607:f8b0:4864:20::1036; Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-354a2a7d90fso1258083a91.2 for ; Wed, 11 Feb 2026 08:38:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770827896; cv=none; d=google.com; s=arc-20240605; b=iDjOpz+SNMDckj1ifs1Hfi+wtSL/1JtHS6m6/mbjdwe5P46OTXBMP59VwBJy7X61AY Mb+WsRHVWnKuowppVYuPbr01wMEtdoAQcllZPR3KrlwBi8lfaQGZcNHEjcAeFVQE5Kdy XRFbMU06g99Jd9bHoexENWjKFOAyPGqSF1pSEh9H7nQVkv6KxwuHkxiAXj937iaua7rM LUIBb80LEPg768sexT1wPxr0iaVojMGfmwf9MLd+RdqooVbVMDqUEWaMZB30w5JG6QgE klhedpV3rhgXVSM3e/ClbKESGu8CZB/1QAAQyR1/j5wGoLykLQjEcV+7hLq/3BMcVs8i ysfg== 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=J9+9uRRBAGWz5X7TxvVtFsTx7Vy8WDityDu9RJu27Wo=; fh=XVix52929F1W5Sf3uNG7KPw+PeG2ro2I0vKFiukTrLc=; b=GJiXS4e4HYRxeAGTHBNqWTP1JOOhkoNR6QHV4e1N6mjnxJRHj73OfSY3nBr8akXO1Y 4hNe63MqMaBSv/RwquthRzeB+JcLpKpiwsrDjlABV5o7kt9UrjrEFgVdT2dJSta1Qzmo 9yTd143Wjf4oP9f2fbj8LMB1NBPviTcJMLzqr+DmgyPaDBbFrK2qwpvn3yTYhaE5EcMs q3zIixRWokRgW/Oyj6Majt24RMrPBgkQiuFnhPzKGK2bc5b1ZuQc3Z88h7AJuxos1r9k ru/0Iwy9NeDW8wbMSolYu41iHG0O2A+UJArYM5HeVDopzQqFTDyiq5oURmvlq1iErU2O iM/Q==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCVkryB2Vz2NMcYITEIsic/0hszRkR7X5ct7jJGMVG7RyiJGSaQ6hFcORpx3rgEg6ru5saZincOijaiJ@googlegroups.com X-Gm-Gg: AZuq6aIPf6CEuvTD2cptWzV0EeT0N0/UDnUExZF93oH2Yh7MoQp4Tlb9XsY+X7e6cnB aPR8PaBE55KFyGjlbY5NwuYz0LwcKpG3VJ4k6h1KiCY+QCwT34cllBvB50+OGcfLcKBkBdHhLGK oUUunxSuZXcIBB4vm6wBZHtcBHs0aa9mIk1+6sP2dXfmfHGgdPAgsL2kEDJTTW1UEWA7zrMksB8 v/jA+eSxPBhF7FqHp5lxMhVYCPhS2xHCZZOj8A6azRaVcvuA7VFARCGIhK8sz1pBF36Z6DNkiB4 /PXGn9udZ/oI/ivZGT9p5CeqKF19FaWaUv394q8Iwo5G2xlr5yzXctfUeTJ+VDaEYGnMfyubRXw MAtmBgxnjBRUQBnGgRCELnUQ9Vuw2ozrfPTY49Den3Nkyr26SQq/Qm4uHviVtiTbJ5QFMTu0Lrb saA4DRJi2NV0JUGriBgOWoLLP0Lg== X-Received: by 2002:a17:90b:528f:b0:356:2c7b:c014 with SMTP id 98e67ed59e1d1-3568f305c18mr34927a91.9.1770827896470; Wed, 11 Feb 2026 08:38:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Wed, 11 Feb 2026 11:37:39 -0500 X-Gm-Features: AZwV_Qir5hXgmAa4e7xHN66Zb9OixaPt-XWwPU-ZssvZJdtOhIMdNEYfAinJMIE 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="000000000000ba4798064a8eff02" 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=Ii7JuTbs; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1036 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 (/) --000000000000ba4798064a8eff02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > i see so a minimal change to taproot would be a new version: =E2=80=9Csc= ript spend only=E2=80=9D or similar. BIP 360's P2MR (Pay-to-Merkle-Root) is P2TR but script spend only via a simple and minimal change. Thanks for working on commit-reveal -- also thanks to Tadge for lifeboat, I think this line of research is worthwhile and helpful. Correct me if you disagree, I think of commit-reveal as useful for the following case: Q-day happens AND we have P2MR AND OP_TXHASH, but not OP_SLH_CHECKSIG, commit-reveal might be the best option to migrate to a PQ signature scheme. I am pursuing the P2MR + OP_SLH_CHECKSIG approach this approach is the least disruptive to how people use Bitcoin today and would be simpler for wallets to support (SLH only requires signing a single transaction vs. two transactions and having to handle griefing/reset). In both cases we want BIP 360's P2MR. I'd also like OP_TXHASH and OP_SLH_CHECKSIG as well. I'm using OP_SLH_CHECKSIG as a placeholder here, if you like OP_SHRINCS_CHECKSIG better, you could also do P2MR + OP_SHRINCS_CHECKSIG On Wed, Feb 11, 2026 at 2:25=E2=80=AFAM Erik Aronesty wrote: > i see so a minimal change to taproot would be a new version: =E2=80=9Cscr= ipt spend > only=E2=80=9D or similar. > > On Tue, Feb 10, 2026 at 6:41=E2=80=AFPM Ethan Heilman = wrote: > >> >> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs >> tapscript >> > false, covenant based multistep secret-reveal spending paths don't >> rely on signatures at all >> >> P2TR has a public key baked into it via the key spend path. This key pat= h >> spend bypasses any covenant or script constraints. The attacker does not >> need to see a value spend to break the key path spend. This means a quan= tum >> attacker can break the nums point in key spend path of the initial outpu= t >> and the AnchorPublishTx output and then just taking all the coins [0]. >> >> > agreed. they have to spend resources to attack your private key and >> the only thing they can do is "grief" using a timing attack with the >> results, rather than steal outright. a massive incentive difference. >> >> Ok, so a core assumption you are making here is that a CRQC isn't >> powerful enough for recovering signing keys to be effectively free. This= is >> likely to be true at the early stages of CRQC, but this assumption may n= ot >> hold forever. If ECC is mathematically broken via a classical attack thi= s >> assumption might not hold at all. I'm attempting to address both quantum >> and classical breaks. >> >> > TX_HASH is simple and generally useful and there is no guarantee that >> q-day will even come >> >> TX_HASH is great! >> >> [0]: As originally noted here: >> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-c= tv-op-txhash-and-no-new-signatures/2168/4 >> >> On Tue, Feb 10, 2026 at 7:19=E2=80=AFPM Erik Aronesty wro= te: >> >>> >>>> >>>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs >>>> tapscript, and the only available tapscript supporting output type, P2= TR, >>>> isn't quantum safe. >>>> >>> >>> false, covenant based multistep secret-reveal spending paths don't rely >>> on signatures at all >>> >>> >>>> >>>> I'm going to assume: >>>> - you mean to use this commit-reveal for migrating between signature >>>> algorithms, not for everyday use, >>>> >>> >>> it can be used if "q day" happens. otherwise ignored. >>> >>> >>>> - TXHASH is being used because you are waiting for the commitment to b= e >>>> confirmed on-chain rather than lifeboat's out-of-band commitment syste= m >>>> >>> >>> it's used so you can commit to a spending constraint without committing >>> to the final "as yet to be determined" quantum-safe destination: >>> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-= ctv-op-txhash-and-no-new-signatures/2168 >>> >>> >>> >>>> Once you post your commit-txn, but before it confirms, other parties >>>> can post competing commit-txns that double spend your output. If one o= f >>>> malicious transactions confirm, you must now wait for a timelock to ex= pire >>>> and then try to post your transaction. >>>> >>> >>> agreed. they have to spend resources to attack your private key and the >>> only thing they can do is "grief" using a timing attack with the result= s, >>> rather than steal outright. a massive incentive difference. >>> >>> >>>> 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. T= hus, >>>> 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 thei= r own >>>> issues. >>>> >>> >>> each time you use the reset-path, they have to re-attack a new key. >>> very expensive just to grief a small amount of fees spread across all >>> miners. sounds like science-fiction levels of compute. >>> >>> >>> plus.... TX_HASH is simple and generally useful and there is no >>> guarantee that q-day will even come >>> >> --=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%2BUNum_%3D1Me0Q%3DfBc7oS6s4i_GwZEw1Ad60S_efHOVnqMw%40mail.gmail.co= m. --000000000000ba4798064a8eff02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 i see so a minimal change to taproot=C2=A0would be a new version: =E2=80=9C= script spend only=E2=80=9D or similar.

BIP 360's P2MR (Pay-to-Me= rkle-Root) is P2TR but script spend only via a simple and minimal change.
Thanks for=C2=A0working on commit-reveal -- also thanks to Tadge for = lifeboat, I think this line of research is worthwhile and helpful.=C2=A0Cor= rect me if you disagree, I think of commit-reveal as useful for the followi= ng case:=C2=A0Q-day happens AND we have P2MR AND OP_TXHASH, but not OP_SLH_= CHECKSIG, commit-reveal might be the best option to migrate to a PQ signatu= re scheme.

I am pursuing the P2MR=C2=A0+ OP_SLH_CHECKSIG approach th= is approach is the least disruptive to how people use Bitcoin today and wou= ld be simpler for wallets to support (SLH only requires signing a single tr= ansaction vs. two transactions and having to handle griefing/reset).
In both cases we want BIP 360's P2MR. I'd also like OP_TXHASH and = OP_SLH_CHECKSIG as well.

I'm using OP_SLH_CHECKSIG as a placehol= der here, if you like OP_SHRINCS_CHECKSIG better, you could also do P2MR=C2= =A0+=C2=A0OP_SHRINC= S_CHECKSIG


On Wed, Feb 11, 2026 at 2:25=E2=80= =AFAM Erik Aronesty <erik@q32.com>= ; wrote:
i see so a minimal change to taproot=C2=A0would be a new version:= =E2=80=9Cscript spend only=E2=80=9D or similar.

On Tue, Feb 10, 2026 at 6:4= 1=E2=80=AFPM Ethan Heilman <eth3rs@gmail.com> wrote:
>>=C2=A0 You'd still need=C2=A0 BIP 360 P2MR (or P2TRD) since OP_TXHASH needs ta= pscript
>=C2=A0 false, covenant based multistep secret-reveal spending paths don't rely= on signatures at all

P2TR has a public key baked into it via the ke= y spend path. This key path spend bypasses any covenant or script constrain= ts. The attacker does not need to see a value spend to break the key path s= pend. This means a quantum attacker can break the nums point in key spend p= ath of the initial output and the=C2=A0AnchorPublishTx output and then just= taking all the coins [0].

>=C2=A0 agreed. they have to spend resources to attack your private key and the onl= y thing they can do is=C2=A0"grief" using a timing attack with th= e results, rather than steal outright.=C2=A0 a=C2=A0massive=C2=A0incentive difference.= =C2=A0=C2=A0

Ok, so a core assumption you are making here is that a = CRQC isn't powerful enough for recovering signing keys to be effectivel= y free. This is likely to be true at the early stages of CRQC, but this ass= umption may not hold forever. If ECC is mathematically broken via a classic= al attack this assumption might not hold at all. I'm attempting to addr= ess both quantum and classical breaks.

>=C2=A0 TX_HASH is simple and generally useful and there is no guarantee that q-day= will even come

TX_HASH is great!

[0]: As originally noted he= re: ht= tps://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op= -txhash-and-no-new-signatures/2168/4

On Tue, Feb 10, 2026 at 7:19=E2=80= =AFPM Erik Aronesty <e= rik@q32.com> wrote:


You'd still need= =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.

false, covenant based multistep secret-= reveal spending paths don't rely on signatures at all
=C2=A0

I'= m going to assume:
- you mean to use this commit-reveal for migrating b= etween signature algorithms, not for everyday use,

it can be used if "q day" happens.=C2=A0 otherw= ise ignored.
=C2=A0
- 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

it's used s= o you can commit to a spending constraint without committing to the final &= quot;as yet to be determined" quantum-safe destination:=C2=A0 https://delving= bitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash-and-n= o-new-signatures/2168
=C2=A0
=C2=A0
Once you post your c= ommit-txn, but before it confirms, other parties can post competing commit-= txns that double spend your output. If one of malicious transactions confir= m, you must now wait for a timelock to expire and then try to post your tra= nsaction.

agreed. they have to spend reso= urces to attack your private key and the only thing they can do is=C2=A0&qu= ot;grief" using a timing attack with the results, rather than steal ou= tright.=C2=A0 a=C2=A0massive=C2=A0incentive difference.=C2=A0=C2=A0
=C2=A0
They c= an block you again. Each time they burn some of you coins in fees. Miners g= et 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 o= ut-of-band commitments, but out-of-band commitments have their own issues.<= br>

each time you use the reset-path, they= have to re-attack a new key.=C2=A0 very expensive just to grief a small am= ount of fees spread across all miners.=C2=A0 =C2=A0sounds like science-fict= ion levels of compute.=C2=A0=C2=A0
=C2=A0

plus.... TX_HASH= is simple and generally useful and there is no guarantee that q-day will e= ven come

--
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%2BUNum_%3D1Me0Q%3DfBc7oS6s4i_GwZEw1Ad60S_ef= HOVnqMw%40mail.gmail.com.
--000000000000ba4798064a8eff02--