From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 23 Feb 2026 06:01:41 -0800 Received: from mail-oi1-f184.google.com ([209.85.167.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vuWVH-0008Ga-0a for bitcoindev@gnusha.org; Mon, 23 Feb 2026 06:01:40 -0800 Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-463c4133ccasf47617712b6e.2 for ; Mon, 23 Feb 2026 06:01:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771855292; cv=pass; d=google.com; s=arc-20240605; b=WFd8UUaQLEpzRK0Ee8X5Mj0Mn3O7OOSPxdiO55OwdR3u4awtDceSAoTcF+FcW3kQoU kzYe6f+xrCw+lYQWucKpCuneTgB7787c83uZylpBmBegjZMh6X5J9JnnsHzMhzzB/5ZI 8G3Ll6C3L+rglyssl0VlWl16kfLRq3LOLv2ITm0OtblesfpBoTCvRPozFOf28zIiLp/k 8UaYqo7xzdSXMypxl5JoVyQumBADbQaTmP+VRMWYEhBZHDlfxwNrKPFj7zTxyd+2/KfE jLUWLDxiWK21bIjHQ2ZE+cX6MTXsYq/6yJDQ0/WQWJKEjRhtg8F4/EqF4C4ptE2+ZjsT fjpg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=dy3f5jWrvPlofAMM7w3VKbhmUAKBwAvTfVOF4pYdB+4=; fh=jbRObde8lIkEjJMAbC+0+MTTGAUFAGMxGA4qVtYHp9M=; b=DUpQcw0ObK+uLDUkL2Xw86zUr+r4rBJpH8bwV3AW0WbgssTtODrZOWocQFf46kkWIO qo7Kvbhyim9E+tjmi62w5k9YWK3htdVQAcrq/LI1bYL/A71ghkvJYX5VVdWSDSltv/Td 9qxZU1KIoSK2VkgYjFz1Pg3rnEcuRn6moCCrfE8+Nayc/F2SzBfjcqZd/jZ02NTUZVFx peegmrSq8aryWoGGGxHMyohTsiT7yMubD7OMnGocuVUmluQ3vCn3UtIn9yGaJtZDruZ8 fAzRCwUNgEA1MlHIwf7iTKN1ACrXY7ZsJTV8lYMTKmtSK5bAzbzBuoHRXhyYwUmQznEw WhYg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=bygerkdxnbhqvcpdf5iu4dljb4.protonmail header.b=mskcTqa8; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771855292; x=1772460092; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=dy3f5jWrvPlofAMM7w3VKbhmUAKBwAvTfVOF4pYdB+4=; b=tiuOD8Yt9jvmsWWX4Aw/r3CfnpllM0xl7ytLjhpaCAjQ9MWRq0ll7dnyxfUAFG7BmQ OJBYRbyePOZTnlZ71gKjTCn+npt+zSO39FDSQXVI0GY73ReVoR3zv9u1xbmmnMR2NbJ8 rCLzjkGd+HEShtizE1mxLvyyYN49UK6PL0E1SQcyF7+TIHq+QkNI4LFCkQfcSwiRoxJb XXfDCdd+sThkOnm3mcMfw20gCWHSm4Ag0TAbhWSLWV+JkFtTZVG5N4Dfmv2m/QLHlPJs PRhmBxuVKNqkuuwej1qJ9L/s+WkpJOEOBhhKeVpfgE+9n06SpCqByJxnvxOqvYWN5zvo t4Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771855292; x=1772460092; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dy3f5jWrvPlofAMM7w3VKbhmUAKBwAvTfVOF4pYdB+4=; b=EWE6YxxDzE2FwGMS4O5+jSVMu5lmH5cLb1YpAi/Mashw9K5CInLx5ooIH7D89vvUlq 591dLO8I6FTRrdKjJ6S91fQiV7bsGpFdSqcvri0BAb/mhojbhvP7uBF/s7RIPVBiPI3V 3+D0gpXbNtyciVs03hFoabv/OplPXxFti+OaiPTGLSiTwMtaAZYGMxS8bFwh1Z5gkSEE bdzYggVolg9uuBMnNRMZE1Zk9dIpQsvu5YlriSeqSxcso2N1t7OepkzbqR8ducyZrcdM PEt+qY6z4OW6SbL2YaDmuCI60K5ZMd0TZYROhab4y+8XAbP00sdDR/qB/n9h5Qi/Xrsm stQg== X-Forwarded-Encrypted: i=2; AJvYcCUOPGNQCZAJg03TSlToSaDmpQzhbL3nWq3+q9dzXD3CpYInQCIUUzClMmxUKbTMQmH/rli/4rL2avoF@gnusha.org X-Gm-Message-State: AOJu0YzLi9e1u85ZgbIyvMsxPy5i7+98h5jaBIFDqjVpeCmcissVhF90 LQIodGiyjw43WoWltYqYGZt/YtX/kuqbIFTIslJyDBwOojAAFfgt6gqw X-Received: by 2002:a05:6808:150d:b0:451:4c6d:a635 with SMTP id 5614622812f47-46446210c22mr4279561b6e.19.1771855291714; Mon, 23 Feb 2026 06:01:31 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+E4ShmmemTyrHNjUEZjTV5b5GMy4pHSUf85/1rEGyp/MA==" Received: by 2002:a05:6870:f21e:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-40eca6341b8ls8397717fac.1.-pod-prod-08-us; Mon, 23 Feb 2026 06:01:25 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWJMAnVt/klkTmG5VtDymM1qFuVz5AGzYqkDkVTYlxl1aAzNO/ivtJxqyP6TOZ/ldkK49HQAgiNZpv3@googlegroups.com X-Received: by 2002:a05:6808:2e47:b0:463:d796:aca0 with SMTP id 5614622812f47-464461d772emr5371626b6e.16.1771855284904; Mon, 23 Feb 2026 06:01:24 -0800 (PST) Received: by 2002:a05:6808:b2b:b0:44f:fe66:38a2 with SMTP id 5614622812f47-46395e57794msb6e; Mon, 23 Feb 2026 06:00:36 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCU/IOsuxFYcZyrXjTyK+M0Pye4piXucQYcNMaU4AWHU+RAjfn9PwWAPcffBCk9qDjox2IzmokiHbMmQ@googlegroups.com X-Received: by 2002:a17:90b:4b07:b0:341:315:f4ec with SMTP id 98e67ed59e1d1-358ae7e915dmr8099777a91.7.1771855234670; Mon, 23 Feb 2026 06:00:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771855234; cv=none; d=google.com; s=arc-20240605; b=ExCm8eHMbmwJsGwmqhsItCQj06QHGKxU2LQyvBVt86kROTby9gr+cZCsSIyoOKoBwd DIl6cx8ICxDTvSOREQRHV5UuaLogts6dKLZvlGNMZzwkSYsESBrI5qfloMctQhfGbEI/ ssjm9X2VZeqKXQJbZUALP/qnTF02EkMRtisaQ31Uj2qDj010Z/XKt9Gkb6Ltoba/lIPH rXD8kmgE1rzpOoTyeNva0CMNk8V/V9QhdR5+d0LI/aE27tu6XAVq5byBXytbagDK7Dul 3pb+rxqBU1BOcnXjN+0V1VAGC6CONQCp3/g9xdDeg02ibJXqtrBKYdh1DXIlQowb7VDb 44YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=xP5rEnCNh3W2zwXiATKDM3HPYYnkH2qPrbKpuy8ZIHM=; fh=YD/SamhoH1A3eJLzNj7r5Ib/zv/lOhX7ZsVL5ZwGHCk=; b=IKHXCZnKPesQop5Lg0IeDlqFxqXS4GcRGIYmxIX+LOq3jwU9sFNLVhBmIkcQNUIq1g vYWCdh0u7vf5MmahaeQbv0AREYMrSA3c/2F/wUIAG1kcMn8z3ipoh3gPv1V3j6CKmnnW beO+16rRzT/cO2P9vGATuJgTZ8Od1kcT/nfAhzJxjo6fAodODExx01SE7IxF5uYPYkS6 3HvOeQhNoonomNm9+ksgoA5tTWpUrYegYVp9nGc5kOm+ln+bd+BEEQ89UYPgtfXjvw8i bCVwEPQS5Hca78zeRMUtADd5J2FXuqwnbV4dDy2b+0GJbRdiOjF7m7P26WcRAdU+098e UTVA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=bygerkdxnbhqvcpdf5iu4dljb4.protonmail header.b=mskcTqa8; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24425.protonmail.ch (mail-24425.protonmail.ch. [109.224.244.25]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-358a4c22b48si120875a91.0.2026.02.23.06.00.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 06:00:34 -0800 (PST) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.25 as permitted sender) client-ip=109.224.244.25; Date: Mon, 23 Feb 2026 14:00:27 +0000 To: Erik Aronesty , "garlonicon@gmail.com" From: "'conduition' via Bitcoin Development Mailing List" Cc: Ethan Heilman , Jonas Nick , bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: bcf41dfd5cc0866a5019fbd39ddf290692002400 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------b8693cca0f15b4d22f90cc8c56d74e19105144868b78c0138b51a21e94f9a448"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=bygerkdxnbhqvcpdf5iu4dljb4.protonmail header.b=mskcTqa8; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.25 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------b8693cca0f15b4d22f90cc8c56d74e19105144868b78c0138b51a21e94f9a448 Content-Type: multipart/mixed;boundary=---------------------cef106f04d9c6b813e4847e6da3614d3 -----------------------cef106f04d9c6b813e4847e6da3614d3 Content-Type: multipart/alternative;boundary=---------------------91f3f9d5a6129a0266b58fecb0d9ad07 -----------------------91f3f9d5a6129a0266b58fecb0d9ad07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" For Garlo: > So, if we talk about disabling obsolete cryptography, then when OP_SHA1 w= ill be disabled? We are not talking about disabling obsolete cryptography. We are talking ab= out adding new address formats to Bitcoin, with an eye specifically on resi= sting breaks in the ECDLP (such as by a CRQC). I hope you can see why enabl= ing a new address format is a totally different proposition than your examp= les. > Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and SH= A-256. This is not about OP_CHECKSIG or its future in script. See previous paragra= ph. For Erik: > Covenant backed multistep secret-reveal schemes are inherently quantum re= sistant (as long as we eliminate the mandatory nums-spend-path with a small= optional tr version addition) I'd be excited to learn about this as an option. Erik, could you please ans= wer my previous questions about the viability of your linked protocol? I'm = not questioning its quantum-resistance properties (yet). I'm wondering how = it is possible to instantiate this scheme in a way that allows a wallet to = actually use this commit/reveal scheme without knowing the final destinatio= n CTV templates (denoted T & E in the delving post) in advance of creating = the phase 0 locking script. Quoting myself: > On one hand the author says phase zero doesn't commit to final CTV templa= tes E & T. However it also says T & E are committed to via the P_anchor tap= script tree, which must be pinned by phase 0. So unless I'm misunderstandin= g, this technique seems to require a priori knowledge of template hashes T = and E when creating the funding address and UTXO in phase 0, so this would = not be viable as a PQ fallback spending path. Happy to be proven wrong. If this is indeed possible i would be super joyed to see it. I just don't u= nderstand how it would be, based on my limited knowledge of TXHASH and CTV. > It's clearly too soon to pick a signature scheme for quantum. Notwithstanding any forthcoming answers to my previous questions on covenan= t-based commit/reveal, i agree partially. Yes, it is too early to risk addi= ng a new cutting edge cryptosystem that relies on novel assumptions, like c= losest-vector, or isogeny-path problems. There is much progress still to be= made in attacking these schemes, and in improving their performance and fl= exibility. But in the case of hash-based signature (HBS) schemes, i disagree. HBS is a= lready mature. Whatever cryptanalytic breakthroughs the future holds, we ca= n be reasonably sure that SHA256 preimage resistance will hold for a long t= ime, so HBS security will hold. Even today md4 and md5 preimage resistance = still holds. Securing coins using hashes alone is the ideal fallback, and e= ven if HBS is not the most efficient class of schemes, that doesn't matter = so much if we don't use HBS as our primary everyday signature scheme. Its v= alue lies in security, not efficiency. Once an efficient PQ scheme is mature, we can use that to someday replace E= CDLP, and rely on HBS as a fallback once again. If you're worried about stuff like how xpubs would work with HBS, we have s= olutions for that too, and they are mostly drop-in replacements for existin= g standards. regards conduitionOn Friday, February 20th, 2026 at 6:48 PM, Erik Aronesty wrote: > Covenant backed multistep secret-reveal schemes are inherently quantum re= sistant (as long as we eliminate the mandatory nums-spend-path with a small= optional tr version addition) >=20 >=20 > It's clearly too soon to pick a signature scheme for quantum. Kyber is pr= obably the most broadly accepted scheme, but nobody uses it without a hybri= d approach, and it doesn't trivially support schemes like xpub key derivati= on. >=20 > But it's NOT too soon to add covenants, which can give people peace-of-mi= nd quantum-safe vaults without needing to trust new quantum sigs. >=20 > On Mon, Feb 16, 2026 at 11:39=E2=80=AFPM conduition wrote: >=20 > > > I just don't see a reason to do P2MR over just utilizing P2TR (or may= beP2TRv2). > > > > > > P2MR will *also* require an equivalent P2MR-disable-soft-fork > >=20 > >=20 > >=20 > > P2TRv2 means locking wallets into using elliptic curve code for as long= as P2TRv2 exists, because you will always have to compute and verify the t= weaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as w= e today see broken primitives like md5 or DES. Future devs shouldn't have t= o add legacy cruft EC libraries into their codebases when it's not even usa= ble for cryptography anymore. > >=20 > > Even if you assume a second P2MR-disable-soft-fork will be needed (whic= h is debatable), then it still pays to remove the inefficient and unnecessa= ry cruft of EC crypto for the foreseeable post-quantum future. You might th= ink of it as decoupling UTXO ownership from any specific public-key cryptos= ystem. > >=20 > > Furthermore, if EC/keypath spending is disabled, P2MR actually requires= less witness space per input than P2TRv2 because we dont need the now-usel= ess internal key in a P2MR script spend witness, whereas P2TRv2 will requir= e it indefinitely until we can migrate to another new address format in the= distant future. See https://github.com/bitcoin/bips/blob/master/bip-0360.m= ediawiki#comparison-with-p2tr-script-path-spend > >=20 > > P2MR is strictly more secure since it depends on weaker assumptions. P2= TRv2 is more complex for wallets to implement than P2MR, unless you count c= ode reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and l= ess block-space-efficient for script path spends. So who would choose P2TRv= 2 over P2MR? > >=20 > > The only redeeming factor of P2TRv2 is that it saves a few dozen witnes= s bytes per input when using schnorr EC key spending, compared to P2MR spen= ding. For low-frequency use cases like cold storage, that doesnt matter muc= h. At current rates thats like 10 sats per input. For high frequency use ca= ses where every vbyte counts like hot wallets, exchanges, mining payouts, e= tc, i have good news: P2TRv1 still exists and can be used just fine. You "j= ust" need to make sure the coins are moved to a PQ address before a quantum= computer attacks them. I'm assuming these high-frequency use case actors a= re online enough to take that last step when necessary. > >=20 > > Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be = slightly more space efficient in the near-term. Thinking longer term, P2MR = is the better choice. > >=20 > > Thinking even further into the future, we have options for a sort of P2= TR-style of address using isogenies, by hiding a commitment to a taproot-st= yle script tree inside a public key curve (public keys in isogeny cryptosys= tems are represented by elliptic curves). Keypath spending would be via SQI= sign (or other schemes). So don't worry, we are not stuck with only merkle = trees forever. I'll elaborate more on this idea in a forthcoming article i = have cooking on isogenies. > >=20 > >=20 > > > ZK proof-of-seedphrase > >=20 > > If we were going to use a ZK proof to rescue quantum procrastinators, i= t should be proof of BIP32 hardened key derivation, and possibly also proof= of pubkey hash preimage knowledge. This is strictly more general than a ze= ro-knowledge proof of seed phrase, the arithmetization would be wayyy more = efficient, and would recover more coins from more diverse wallet types. > >=20 > > Also, there is no need for it to be a hefty zero-knowledge proof, like = a STARK. Rescue could be deployed using a commit and reveal protocol, as ha= s been discussed on the list previously (sorry, i dont have the link in fro= nt of me right now). The idea is that a sender can rescue frozen UTXOs usin= g a commit/reveal sequence of transactions which ultimately proves the send= er knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the c= oins in question through hardened BIP32 CKD, which a CRQC shouldn't be able= to forge. > >=20 > > This would maximize rescue coverage while minimizing blockspace congest= ion, and could be done as a soft fork. > >=20 > >=20 > > ----- > >=20 > > I'm glad to see thoughtful discussion on the subject of how to handle a= quantum freeze. But it is important to put this in perspective in the cont= ext of this thread: right now the number one most important thing - which w= e NEED to do if Bitcoin is to survive appearance of a CRQC - is to provide = a standardized wallet address format which includes a secure fallback way t= o authenticate UTXOs if ECC is unsafe to use. We can debate about freezing = or rescuing coins, or the philosophy of ownership, but these questions will= not be decidable for years. > >=20 > > What is decidable is this: how would you change Ethan's proposal, if at= all? I'll remind everyone that currently it is limited only to adding two = features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are= all we need in consensus to finally give hodlers an option to migrate. > >=20 > >=20 > > I've gone through and catalogued some of the feedback on Ethan's propos= al. So far I've heard these material critiques: > >=20 > >=20 > > 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them t= o implement commit/reveal? > >=20 > > As i mentioned in my last message i don't think that is possible, at le= ast not using the technique Erik linked. I'd be happy to be proven wrong he= re because that'd be fantastic news if true. > >=20 > >=20 > > 2. Why not use SHRINCS instead of SLH-DSA? > >=20 > > Seems like a valid idea to me. SHRINCS would add implementation and UX = complexity but it'd also make the fallback sig scheme scalable - a very nic= e property to have in the worst case scenario where a majority of users end= up needing to sign with it. Philosophically i dislike statefulness in a cr= yptosystem, but maybe as a fallback it is an acceptable tradeoff. > >=20 > >=20 > > 3. Why not deploy GSR and let wallet devs roll their own crypto? > >=20 > > As ethan pointed out, this would be bad for standardization and interop= erability, and also requires GSR to be deployed as a pre-requisite. If GSR = is activated and in-script signing schemes are standardized correctly, it c= ould possibly be a suitable alternative to activating dedicated SLH-DSA opc= odes. > >=20 > >=20 > > 4. Why not continue using P2TR and disable keypath spending later, rath= er than adding a whole new address format? > >=20 > > As ethan pointed out, this depends on timing a future disabling soft fo= rk correctly and will lead to FUD, avoidable debate, and confusion. It is a= lso confiscatory, as it would freeze standardized keypath-only P2TR outputs= which lack a script path. > >=20 > >=20 > > 5. Why not redeploy P2TR with a new segwit version number, which opts i= nto a future keypath-disabling soft fork? > >=20 > > Ethan and i have both made some compelling arguments as to why we shoul= d give the community a new address format which is totally decoupled from a= ny PQ-vulnerable cryptography. If the increased fees of P2MR are an issue f= or high-frequency hot wallets, P2TR is still viable, at least until Q-day. = As stated Ethan's proposal is more motivated by long term cold storage use = cases. I consider a small increase in witness size to be an acceptable trad= eoff for (speculative) quantum security, and the costs of clinging to those= savings in the near-term to be unacceptable. Key-path spending may be rein= vented in the future using other novel cryptosystems, with another new addr= ess format that depends on new cryptographic assumptions. > >=20 > > ----- > >=20 > > I apologize if i missed anyone's feedback notes in this summary. Please= correct me if i have! > >=20 > > regards, > > conduition > >=20 > >=20 > > On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin De= velopment Mailing List wrote: > >=20 > > > Hi list, just wanted to pipe in on the subject of commit/reveal using= OP_TXHASH. I don't think it is possible. The protocol link Erik posted ( h= ttps://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-o= p-txhash-and-no-new-signatures/2168 ) seems to contradict itself. On one ha= nd the author says phase zero doesn't commit to final CTV templates E & T. = However it also says T & E are committed to via the P_anchor tapscript tree= , which must be pinned by phase 0. So unless I'm misunderstanding, this tec= hnique seems to require a priori knowledge of template hashes T and E when = creating the funding address and UTXO in phase 0, so this would not be viab= le as a PQ fallback spending path. Happy to be proven wrong. > > >=20 > > > regards, > > > conduition > > >=20 > > >=20 > > >=20 > > > On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty wrote: > > >=20 > > > > >=20 > > > > >=20 > > > > > You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs ta= pscript, and the only available tapscript supporting output type, P2TR, isn= 't quantum safe. > > > >=20 > > > >=20 > > > > false, covenant based multistep secret-reveal spending paths don't = rely on signatures at all > > > >=20 > > > > >=20 > > > > > I'm going to assume: > > > > > - you mean to use this commit-reveal for migrating between signat= ure algorithms, not for everyday use, > > > >=20 > > > >=20 > > > > it can be used if "q day" happens. otherwise ignored. > > > >=20 > > > > > - TXHASH is being used because you are waiting for the commitment= to be confirmed on-chain rather than lifeboat's out-of-band commitment sys= tem > > > >=20 > > > >=20 > > > > it's used so you can commit to a spending constraint without commit= ting to the final "as yet to be determined" quantum-safe destination: https= ://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-tx= hash-and-no-new-signatures/2168 > > > >=20 > > > > > Once you post your commit-txn, but before it confirms, other part= ies 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. > > > >=20 > > > >=20 > > > > 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 resul= ts, rather than steal outright. a massive incentive difference. > > > >=20 > > > > > They can block you again. Each time they burn some of you coins i= n 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 sin= ce it uses out-of-band commitments, but out-of-band commitments have their = own issues. > > > >=20 > > > >=20 > > > > 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 mine= rs. sounds like science-fiction levels of compute. > > > >=20 > > > > plus.... TX_HASH is simple and generally useful and there is no gua= rantee 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, s= end an email to bitcoindev+unsubscribe@googlegroups.com. > > > > To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.= com. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKx= bdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me. --=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/= WCU43Srj6CNeiFvY13jPrHlceJeD6SeKoTWmsHwgebvImqPDO1IEZ6N-0qlm_ialjt0_fAGnAuB= B62c0gMfM1QGJAKQJjFZ0bJ0NjNepiY0%3D%40proton.me. -----------------------91f3f9d5a6129a0266b58fecb0d9ad07 Content-Type: multipart/related;boundary=---------------------5be95d8c4fe6783f9fa153d0e188727f -----------------------5be95d8c4fe6783f9fa153d0e188727f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For Garlo:

So, if we talk about disabling= obsolete cryptography, then when OP_SHA1 will be disabled?

We are not talking about disabling obso= lete cryptography. We are talking about adding new address formats to Bitco= in, with an eye specifically on resisting breaks in the ECDLP (such as by a= CRQC). I hope you can see why enabling a new address format is a totally d= ifferent proposition than your examples.

= Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and SHA-= 256.

This is not about = OP_CHECKSIG or its future in script. See previous paragraph.
<= div>

For Erik:

Covenant backed multistep secret-reveal schemes are inherently qua= ntum resistant (as long as we eliminate the mandatory nums-spend-path with = a small optional tr version addition)

I'd be excited to learn about this as an option. Erik, could = you please answer my previous questions about the viability of your linked = protocol? I'm not questioning its quantum-resistance properties (yet). I'm = wondering how it is possible to instantiate this scheme in a way that allow= s a wallet to actually use this commit/reveal scheme without knowing the fi= nal destination CTV templates (denoted T & E in the delving post) in ad= vance of creating the phase 0 locking script.

<= div>Quoting myself:

On one hand the= author says phase zero doesn't commit to final CTV templates E & T. Ho= wever it also says T & E are committed to via the P_anchor tapscript tr= ee, which must be pinned by phase 0. So unless I'm misunderstanding, this t= echnique seems to require a priori knowledge of template hashes T and E whe= n creating the funding address and UTXO in phase 0, so this would not be vi= able as a PQ fallback spending path. Happy to be proven wrong.
=

If this is indeed possible i would b= e super joyed to see it. I just don't understand how it would be, based on = my limited knowledge of TXHASH and CTV.

I= t's clearly too soon to pick a signature scheme for quantum.

Notwithstanding any forthcoming answer= s to my previous questions on covenant-based commit/reveal, i agree partial= ly. Yes, it is too early to risk adding a new cutting edge cryptosystem tha= t relies on novel assumptions, like closest-vector, or isogeny-path problem= s. There is much progress still to be made in attacking these schemes, and = in improving their performance and flexibility.

=
But in the case of hash-based signature (HBS) schemes, i disagre= e. HBS is already mature. Whatever cryptanalytic breakthroughs the future h= olds, we can be reasonably sure that SHA256 preimage resistance will hold f= or a long time, so HBS security will hold. Even today md4 and md5 preimage = resistance still holds. Securing coins using hashes alone is the ideal fall= back, and even if HBS is not the most efficient class of schemes, that does= n't matter so much if we don't use HBS as our primary everyday signature sc= heme. Its value lies in security, not efficiency.

Once an efficient PQ scheme is mature, we can use that to som= eday replace ECDLP, and rely on HBS as a fallback once again.
<= div>
If you're worried about stuff like how xpubs would= work with HBS, we have solutions for that too, and they are mostly drop-in= replacements for existing standards.

regards
conduition
On Friday, February 20th, 2026 at 6:48 PM, Erik Aronesty <erik@q= 32.com> wrote:
Cove= nant backed multistep secret-reveal schemes are inherently quantum resistan= t (as long as we eliminate the mandatory nums-spend-path with a small optio= nal tr version addition)

It's clearly too soon to p= ick a signature scheme for quantum. Kyber is probably the most broadly acce= pted scheme, but nobody uses it without a hybrid approach, and it doesn't t= rivially support schemes like xpub key derivation.

But it's NOT to= o soon to add covenants, which can give people peace-of-mind quantum-safe v= aults without needing to trust new quantum sigs.

On Mon, Feb 16, 2026 at 11:39=E2=80=AFPM conduition <c= onduition@proton.me> wrote:
> I just don't see a reason to do P2MR over just utilizing P2TR= (or maybe
P2TRv2).
>
> P2MR will *also* require an equivalent P2MR-disable-soft-= fork



P2= TRv2 means locking wallets into using elliptic curve code for as long as P2= TRv2 exists, because you will always have to compute and verify the tweaked= output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as we toda= y see broken primitives like md5 or DES. Future devs shouldn't have to add = legacy cruft EC libraries into their codebases when it's not even usable fo= r cryptography anymore.

Even if you a= ssume a second P2MR-disable-soft-fork will be needed (which is debatable), = then it still pays to remove the inefficient and unnecessary cruft of EC cr= ypto for the foreseeable post-quantum future. You might think of it as deco= upling UTXO ownership from any specific public-key cryptosystem.

Furthermore, if EC/keypath spending is disabled= , P2MR actually requires less witness space per input than P2TRv2 because w= e dont need the now-useless internal key in a P2MR script spend witness, wh= ereas P2TRv2 will require it indefinitely until we can migrate to another n= ew address format in the distant future. See https://git= hub.com/bitcoin/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-sc= ript-path-spend

P2MR is strictly = more secure since it depends on weaker assumptions. P2TRv2 is more complex = for wallets to implement than P2MR, unless you count code reuse from P2TRv1= . P2TRv2 is (marginally) computationally slower, and less block-space-effic= ient for script path spends. So who would choose P2TRv2 over P2MR?

The only redeeming factor of P2TRv2 is that i= t saves a few dozen witness bytes per input when using schnorr EC key spend= ing, compared to P2MR spending. For low-frequency use cases like cold stora= ge, that doesnt matter much. At current rates thats like 10 sats per input.= For high frequency use cases where every vbyte counts like hot wallets, ex= changes, mining payouts, etc, i have good news: P2TRv1 still exists and can= be used just fine. You "just" need to make sure the coins are moved to a P= Q address before a quantum computer attacks them. I'm assuming these high-f= requency use case actors are online enough to take that last step when nece= ssary.

Thus i see P2MR as the superio= r choice to P2TRv2 even if P2TRv2 may be slightly more space efficient in t= he near-term. Thinking longer term, P2MR is the better choice.
=

Thinking even further into the future, we have op= tions for a sort of P2TR-style of address using isogenies, by hiding a comm= itment to a taproot-style script tree inside a public key curve (public key= s in isogeny cryptosystems are represented by elliptic curves). Keypath spe= nding would be via SQIsign (or other schemes). So don't worry, we are not s= tuck with only merkle trees forever. I'll elaborate more on this idea in a = forthcoming article i have cooking on isogenies.


> ZK proof-of-seedphrase
If we were going to use a ZK proof to rescue quantum proc= rastinators, it should be proof of BIP32 hardened key derivation, and possi= bly also proof of pubkey hash preimage knowledge. This is strictly more gen= eral than a zero-knowledge proof of seed phrase, the arithmetization would = be wayyy more efficient, and would recover more coins from more diverse wal= let types.

Also, there is no need for= it to be a hefty zero-knowledge proof, like a STARK. Rescue could be deplo= yed using a commit and reveal protocol, as has been discussed on the list p= reviously (sorry, i dont have the link in front of me right now). The idea = is that a sender can rescue frozen UTXOs using a commit/reveal sequence of = transactions which ultimately proves the sender knew a BIP32 parent xpriv (= or pubkey hash preimage) which controls the coins in question through harde= ned BIP32 CKD, which a CRQC shouldn't be able to forge.
This would maximize rescue coverage while minimizing blo= ckspace congestion, and could be done as a soft fork.

=

-----

I'm glad to see thoughtful discussion on the subject of how to handle a qu= antum freeze. But it is important to put this in perspective in the context= of this thread: right now the number one most important thing - which we N= EED to do if Bitcoin is to survive appearance of a CRQC - is to provide a s= tandardized wallet address format which includes a secure fallback way to a= uthenticate UTXOs if ECC is unsafe to use. We can debate about freezing or = rescuing coins, or the philosophy of ownership, but these questions will no= t be decidable for years.

What is dec= idable is this: how would you change Ethan's proposal, if at all? I'll remi= nd everyone that currently it is limited only to adding two features: BIP36= 0 P2MR addresses, and SLH-DSA opcodes. Those two changes are all we need in= consensus to finally give hodlers an option to migrate.
<= br>

I've gone through and catalogued some of= the feedback on Ethan's proposal. So far I've heard these material critiqu= es:


1. Why not instead= deploy covenant opcodes (TXHASH, CTV) and use them to implement commit/rev= eal?

As i mentioned in my last messag= e i don't think that is possible, at least not using the technique Erik lin= ked. I'd be happy to be proven wrong here because that'd be fantastic news = if true.


2. Why not us= e SHRINCS instead of SLH-DSA?

Seems l= ike a valid idea to me. SHRINCS would add implementation and UX complexity = but it'd also make the fallback sig scheme scalable - a very nice property = to have in the worst case scenario where a majority of users end up needing= to sign with it. Philosophically i dislike statefulness in a cryptosystem,= but maybe as a fallback it is an acceptable tradeoff.

3. Why not deploy GSR and let wallet devs = roll their own crypto?

As ethan point= ed out, this would be bad for standardization and interoperability, and als= o requires GSR to be deployed as a pre-requisite. If GSR is activated and i= n-script signing schemes are standardized correctly, it could possibly be a= suitable alternative to activating dedicated SLH-DSA opcodes.
=


4. Why not continue using P2TR and= disable keypath spending later, rather than adding a whole new address for= mat?

As ethan pointed out, this depen= ds on timing a future disabling soft fork correctly and will lead to FUD, a= voidable debate, and confusion. It is also confiscatory, as it would freeze= standardized keypath-only P2TR outputs which lack a script path.


5. Why not redeploy P2TR with a= new segwit version number, which opts into a future keypath-disabling soft= fork?

Ethan and i have both made som= e compelling arguments as to why we should give the community a new address= format which is totally decoupled from any PQ-vulnerable cryptography. If = the increased fees of P2MR are an issue for high-frequency hot wallets, P2T= R is still viable, at least until Q-day. As stated Ethan's proposal is more= motivated by long term cold storage use cases. I consider a small increase= in witness size to be an acceptable tradeoff for (speculative) quantum sec= urity, and the costs of clinging to those savings in the near-term to be un= acceptable. Key-path spending may be reinvented in the future using other n= ovel cryptosystems, with another new address format that depends on new cry= ptographic assumptions.

-----<= /div>

I apologize if i missed anyone's feedback no= tes in this summary. Please correct me if i have!

regards,
conduition


On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoi= n Development Mailing List <bitcoindev@google= groups.com> wrote:
Hi list, just wanted to pipe= in on the subject of commit/reveal using OP_TXHASH. I don't think it is po= ssible. The protocol link Erik posted ( = https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-= op-txhash-and-no-new-signatures/2168 ) seems to contradict itsel= f. On one hand the author says phase zero doesn't commit to final CTV templ= ates E & T. However it also says T & E are committed to via the P_a= nchor tapscript tree, which must be pinned by phase 0. So unless I'm misund= erstanding, this technique seems to require a priori knowledge of template = hashes T and E when creating the funding address and UTXO in phase 0, so th= is would not be viable as a PQ fallback spending path. Happy to be proven w= rong.

regards,
condui= tion



On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty <erik@q32.com> wrote:


You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript, and the only avail= able tapscript supporting output type, P2TR, isn't quantum safe.
<= /blockquote>

false, covenant based multistep secret-reve= al 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 be confirmed on-chain r= ather than lifeboat's out-of-band commitment system
<= div>
it's used so you can commit to a spending constraint wit= hout committing to the final "as yet to be determined" quantum-safe destina= tion: https://delvingbitcoin.org/t/a-quantum-= resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/2168
<= div dir=3D"ltr">
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 timeloc= k to expire and then try to post your transaction.
They can b= lock you again. Each time they burn some of you coins in fees. Miners get t= he fees, so they might be incentivized to do this. Thus, we must trust mine= rs not to do this. Lifeboat doesn't have this issue since it uses out-of-ba= nd commitments, but out-of-band commitments have their own issues.

--
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@googl= egroups.com.
To view this discussion visit https://grou= ps.google.com/d/msgid/bitcoindev/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZ= o6R9ZYbJFUQ%40mail.gmail.com.

--
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@googl= egroups.com.
To view this discussion visit https://groups.google.com/d/msgid/b= itcoindev/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7= fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40proton.me.


--
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/WCU43S= rj6CNeiFvY13jPrHlceJeD6SeKoTWmsHwgebvImqPDO1IEZ6N-0qlm_ialjt0_fAGnAuBB62c0g= MfM1QGJAKQJjFZ0bJ0NjNepiY0%3D%40proton.me.
-----------------------5be95d8c4fe6783f9fa153d0e188727f-- -----------------------91f3f9d5a6129a0266b58fecb0d9ad07-- -----------------------cef106f04d9c6b813e4847e6da3614d3 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------cef106f04d9c6b813e4847e6da3614d3-- --------b8693cca0f15b4d22f90cc8c56d74e19105144868b78c0138b51a21e94f9a448 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmmcXWoJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcwKam8MmueRpbpWcNc9gwRPGmGBzWz7iwD0lz+ YNmGIBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABNfwEAosCB6z2G8V0O6Ys6 Tj7HlO6FjVNz1sW+udut/xZk1DoBAPU3Porv+ryBy34mgYnbvkPIVrGab1Z1 /luXtCuig+MI =+g8F -----END PGP SIGNATURE----- --------b8693cca0f15b4d22f90cc8c56d74e19105144868b78c0138b51a21e94f9a448--