From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 24 Feb 2026 19:41:46 -0800 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vv5mS-0001Ps-Qm for bitcoindev@gnusha.org; Tue, 24 Feb 2026 19:41:46 -0800 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7d4d668425dsf71524725a34.1 for ; Tue, 24 Feb 2026 19:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771990898; x=1772595698; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=wg09vpEruaHfpmDpcsnVJgCXRlBV05GG1tCVKQBO7xs=; b=ie2vgy8cAK3de1ni+kKTPLrt3r4xpi72ke18oHvYZTquYXcJBCUDu7h6aUgdoWrVuh I1vWYbLn+55GQ3b8RvxRst/QzP8C04Y9IKQuYtyQSPM5A8gsYgwysrlo/4tG2mmzswEJ z4swz1pUvc5EPFo036rNqC0+P6+e9/j/vXekFkIcrDuWfY4h25oNzUt5HCOrkAPc+mDw dUNRJKU/sNjR8xXRzoOrlJsLsFMf3eq26KG7KcGloksba2LEmA3FMq4nx4Hb4jd//tcE EhnqYfJ/MHtFt7Hwm74jtSkIZPCiv3+wHRkeUY6Qt1OmRuVp9WMavR1+y24RutMFtlAC sz9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771990898; x=1772595698; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=wg09vpEruaHfpmDpcsnVJgCXRlBV05GG1tCVKQBO7xs=; b=GjoItnmFAqNPOld6Jx793svXHxJ32v6DPQSUtlcLxTt97qf3br5gL1Qp9HAml9JvCy pKGI3xrCs0Ws/z2ooajqjahUKh8TmSAXZpZWzm6ESaS0RUz0rwkE2WzDY8v8Od/87bto pBdPK/7D+nQTvZHcZ3F1vII1yx4hElnENJClyyx3uIAiAF9S1sYOgEe4LUUDFQlO09PM peIpXanNLHFdpXB45ZJkzST8vctanl9fqeAaFuh987NIo4yUosakFh7yV/OrdgF7aHEg 1JDOON9X4dg8N5GLVEOD4qA80CZWBmn7isqiOIvi3bn7+WbelV0+5PqxeH+wJk7yFUGa t5WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771990898; x=1772595698; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=wg09vpEruaHfpmDpcsnVJgCXRlBV05GG1tCVKQBO7xs=; b=DDV6lkwHxLD/NLcgIBbb+xFjlkOO+ZcGsCmk0Y9a1jGsnC2eER52g4GBqNtPmxIgjZ 7KjupV9oonHRPM9lB03Bv1RZ95AvObdbYrZsRkweD9bnMI5g5wO8BgTSzoj0g4YJkrCL Ti22DfLWsSi70Tge7FWwAUTIa8k/E1miEC4j/7NVmNDj0SCMbwoqP7bfs0E11+HzC6fU o5DSodtWhBGKec6Tn9XJ1Q9MAIcrDhr+F+XQTOq4TWGmRxLdlYVd7gYPJaOwVh53hEaa Lbm2Zv25WAcJUmRTo91goisBF2t0rLz6TtP5PyIz2a5KgOdq/WN8KrNASepLrzfmYoct wqtw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVhIYGN9akG7sRVS7mfmorVw99rKgnO8gprM6rFSFnO81aVG4W/TCpZnpWbrSXYyV0NkydCVK2Xa492@gnusha.org X-Gm-Message-State: AOJu0YyqyPGkHNDCVrT498WFd6fAhA85KDxeZ+LzgZH5OnYbCL5njL4o Rqr6tv2Fp3lWxgQzu0++C7CQFjXwXc2meZWw5RLPUl13cEtoJi5Db3os X-Received: by 2002:a05:6870:b18:b0:3f5:694f:9366 with SMTP id 586e51a60fabf-4157af9d819mr9497867fac.30.1771990898262; Tue, 24 Feb 2026 19:41:38 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HK5ppBQnt8JSl5gqLJclaQyYzGGBvrY12+qzZXEBF4VQ==" Received: by 2002:a05:6870:224e:b0:3e8:9f07:3b9 with SMTP id 586e51a60fabf-415ede5c5edls110825fac.0.-pod-prod-03-us; Tue, 24 Feb 2026 19:41:33 -0800 (PST) X-Received: by 2002:a05:6808:11c9:b0:45e:f8af:1015 with SMTP id 5614622812f47-46446418bedmr6957629b6e.62.1771990893118; Tue, 24 Feb 2026 19:41:33 -0800 (PST) Received: by 2002:a05:690c:450f:b0:797:d142:b0fa with SMTP id 00721157ae682-797d142c176ms7b3; Thu, 19 Feb 2026 17:41:17 -0800 (PST) X-Received: by 2002:a05:690c:39d:b0:796:357a:9af1 with SMTP id 00721157ae682-7979e90b781mr172612027b3.61.1771551675890; Thu, 19 Feb 2026 17:41:15 -0800 (PST) Date: Thu, 19 Feb 2026 17:41:15 -0800 (PST) From: Alex To: Bitcoin Development Mailing List Message-Id: <0b534992-146b-46bd-8865-56b7afda31adn@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_79914_2132343990.1771551675458" X-Original-Sender: alexhultman@gmail.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 (/) ------=_Part_79914_2132343990.1771551675458 Content-Type: multipart/alternative; boundary="----=_Part_79915_807104973.1771551675458" ------=_Part_79915_807104973.1771551675458 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > So, if we talk about disabling obsolete cryptography, then when OP_SHA1= =20 will be disabled? This is a dishonest misrepresentation of the proposal in this thread.=20 Nobody is arguing about disabling any algorithm. The proposal _explicitly_= =20 states, that the same Elliptic Curve signatures would still be the=20 preferred default signatures and that they merely would move from being=20 implicitly default via the key spend path to instead being explicitly=20 called upon via a spending script. Please, do not strawman the proposal if you haven't read it. Nobody is=20 arguing about disabling Schnorr/ECDSA. Read the proposal before assuming. torsdag 19 februari 2026 kl. 16:12:01 UTC+1 skrev Garlo Nicon: > > Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken= =20 > primitives like md5 or DES. > > We still have OP_SHA1 in the Script, and even in the TapScript, even=20 > though there are known collisions for that. Also note, that MD5 is broken= ,=20 > only when it comes to collisions. MD5 preimages are still unknown, becaus= e=20 > mounting a preimage attack is much harder. > > So, if we talk about disabling obsolete cryptography, then when OP_SHA1= =20 > will be disabled? I guess it won't change in the nearest future, even=20 > though the first SHA-1 collision happened in February 2017, around 9 year= s=20 > ago. > > > > Future devs shouldn't have to add legacy cruft EC libraries into their= =20 > codebases when it's not even usable for cryptography anymore. > > Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and=20 > SHA-256. Otherwise, by breaking only secp256k1 alone, you will still have= =20 > 40-byte DER signatures, and not 9-byte minimal ones, where everything is= =20 > fully broken. And it is possible to enforce a given Proof of Work, if you= =20 > use OP_SIZE on DER signatures. Even if you use private key, equal to one,= =20 > then still: you won't sweep everything, for example from this transaction= :=20 > aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801 > > Which means, that there are still use cases for OP_CHECKSIG, even if you= =20 > can break secp256k1, as long as you cannot break SHA-256. > > wt., 17 lut 2026 o 08:51 'conduition' via Bitcoin Development Mailing Lis= t=20 > napisa=C5=82(a): > >> > I just don't see a reason to do P2MR over just utilizing P2TR (or mayb= e >> P2TRv2). >> > >> > P2MR will *also* require an equivalent P2MR-disable-soft-fork >> >> >> >> P2TRv2 means locking wallets into using elliptic curve code for as long= =20 >> as P2TRv2 exists, because you will always have to compute and verify the= =20 >> tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 = as=20 >> we today see broken primitives like md5 or DES. Future devs shouldn't ha= ve=20 >> to add legacy cruft EC libraries into their codebases when it's not even= =20 >> usable for cryptography anymore. >> >> Even if you assume a second P2MR-disable-soft-fork will be needed (which= =20 >> is debatable), then it still pays to remove the inefficient and unnecess= ary=20 >> cruft of EC crypto for the foreseeable post-quantum future. You might th= ink=20 >> of it as decoupling UTXO ownership from any specific public-key=20 >> cryptosystem. >> >> Furthermore, if EC/keypath spending is disabled, P2MR actually requires= =20 >> less witness space per input than P2TRv2 because we dont need the=20 >> now-useless internal key in a P2MR script spend witness, whereas P2TRv2= =20 >> will require it indefinitely until we can migrate to another new address= =20 >> format in the distant future. See=20 >> https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki#compariso= n-with-p2tr-script-path-spend >> >> P2MR is strictly more secure since it depends on weaker assumptions.=20 >> P2TRv2 is more complex for wallets to implement than P2MR, unless you co= unt=20 >> code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, a= nd=20 >> less block-space-efficient for script path spends. So who would choose= =20 >> P2TRv2 over P2MR? >> >> The only redeeming factor of P2TRv2 is that it saves a few dozen witness= =20 >> bytes per input when using schnorr EC key spending, compared to P2MR=20 >> spending. For low-frequency use cases like cold storage, that doesnt mat= ter=20 >> much. At current rates thats like 10 sats per input. For high frequency = use=20 >> cases where every vbyte counts like hot wallets, exchanges, mining payou= ts,=20 >> etc, i have good news: P2TRv1 still exists and can be used just fine. Yo= u=20 >> "just" need to make sure the coins are moved to a PQ address before a=20 >> quantum computer attacks them. I'm assuming these high-frequency use cas= e=20 >> actors are online enough to take that last step when necessary. >> >> Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be= =20 >> slightly more space efficient in the near-term. Thinking longer term, P2= MR=20 >> is the better choice. >> >> Thinking even further into the future, we have options for a sort of=20 >> P2TR-style of address using isogenies, by hiding a commitment to a=20 >> taproot-style script tree inside a public key curve (public keys in isog= eny=20 >> cryptosystems are represented by elliptic curves). Keypath spending woul= d=20 >> be via SQIsign (or other schemes). So don't worry, we are not stuck with= =20 >> only merkle trees forever. I'll elaborate more on this idea in a=20 >> forthcoming article i have cooking on isogenies. >> >> >> > ZK proof-of-seedphrase >> >> If we were going to use a ZK proof to rescue quantum procrastinators, it= =20 >> should be proof of BIP32 hardened key derivation, and possibly also proo= f=20 >> of pubkey hash preimage knowledge. This is strictly more general than a= =20 >> zero-knowledge proof of seed phrase, the arithmetization would be wayyy= =20 >> more efficient, and would recover more coins from more diverse wallet ty= pes. >> >> Also, there is no need for it to be a hefty zero-knowledge proof, like a= =20 >> STARK. Rescue could be deployed using a commit and reveal protocol, as h= as=20 >> been discussed on the list previously (sorry, i dont have the link in fr= ont=20 >> of me right now). The idea is that a sender can rescue frozen UTXOs usin= g a=20 >> commit/reveal sequence of transactions which ultimately proves the sende= r=20 >> knew a BIP32 parent xpriv (or pubkey hash preimage) which controls the= =20 >> coins in question through hardened BIP32 CKD, which a CRQC shouldn't be= =20 >> able to forge. >> >> This would maximize rescue coverage while minimizing blockspace=20 >> congestion, and could be done as a soft fork. >> >> >> ----- >> >> I'm glad to see thoughtful discussion on the subject of how to handle a= =20 >> quantum freeze. But it is important to put this in perspective in the=20 >> context of this thread: right now the number one most important thing -= =20 >> which we NEED to do if Bitcoin is to survive appearance of a CRQC - is t= o=20 >> provide a standardized wallet address format which includes a secure=20 >> fallback way to authenticate UTXOs if ECC is unsafe to use. We can debat= e=20 >> about freezing or rescuing coins, or the philosophy of ownership, but th= ese=20 >> questions will not be decidable for years. >> >> What is decidable is this: how would you change Ethan's proposal, if at= =20 >> all? I'll remind everyone that currently it is limited only to adding tw= o=20 >> features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes = are=20 >> all we need in consensus to finally give hodlers an option to migrate. >> >> >> I've gone through and catalogued some of the feedback on Ethan's=20 >> proposal. So far I've heard these material critiques: >> >> >> 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to= =20 >> implement commit/reveal? >> >> As i mentioned in my last message i don't think that is possible, at=20 >> least not using the technique Erik linked. I'd be happy to be proven wro= ng=20 >> here because that'd be fantastic news if true. >> >> >> 2. Why not use SHRINCS instead of SLH-DSA? >> >> Seems like a valid idea to me. SHRINCS would add implementation and UX= =20 >> complexity but it'd also make the fallback sig scheme scalable - a very= =20 >> nice property to have in the worst case scenario where a majority of use= rs=20 >> end up needing to sign with it. Philosophically i dislike statefulness i= n a=20 >> 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 pointed out, this would be bad for standardization and=20 >> interoperability, and also requires GSR to be deployed as a pre-requisit= e.=20 >> If GSR is activated and in-script signing schemes are standardized=20 >> correctly, it could possibly be a suitable alternative to activating=20 >> dedicated SLH-DSA opcodes. >> >> >> 4. Why not continue using P2TR and disable keypath spending later, rathe= r=20 >> than adding a whole new address format? >> >> As ethan pointed out, this depends on timing a future disabling soft for= k=20 >> correctly and will lead to FUD, avoidable debate, and confusion. It is a= lso=20 >> confiscatory, as it would freeze standardized keypath-only P2TR outputs= =20 >> which lack a script path. >> >> >> 5. Why not redeploy P2TR with a new segwit version number, which opts=20 >> into a future keypath-disabling soft fork? >> >> Ethan and i have both made some compelling arguments as to why we should= =20 >> give the community a new address format which is totally decoupled from = any=20 >> PQ-vulnerable cryptography. If the increased fees of P2MR are an issue f= or=20 >> high-frequency hot wallets, P2TR is still viable, at least until Q-day. = As=20 >> stated Ethan's proposal is more motivated by long term cold storage use= =20 >> cases. I consider a small increase in witness size to be an acceptable= =20 >> tradeoff for (speculative) quantum security, and the costs of clinging t= o=20 >> those savings in the near-term to be unacceptable. Key-path spending may= be=20 >> reinvented in the future using other novel cryptosystems, with another n= ew=20 >> address format that depends on new cryptographic assumptions. >> >> ----- >> >> I apologize if i missed anyone's feedback notes in this summary. Please= =20 >> correct me if i have! >> >> regards, >> conduition >> >> >> On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin=20 >> Development Mailing List wrote: >> >> Hi list, just wanted to pipe in on the subject of commit/reveal using=20 >> OP_TXHASH. I don't think it is possible. The protocol link Erik posted (= =20 >> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-c= tv-op-txhash-and-no-new-signatures/2168=20 >> ) seems to contradict itself. On one hand the author says phase zero=20 >> doesn't commit to final CTV templates E & T. However it also says T & E = are=20 >> committed to via the P_anchor tapscript tree, which must be pinned by ph= ase=20 >> 0. So unless I'm misunderstanding, this technique seems to require a pri= ori=20 >> knowledge of template hashes T and E when creating the funding address a= nd=20 >> UTXO in phase 0, so this would not be viable as a PQ fallback spending= =20 >> path. Happy to be proven wrong. >> >> regards, >> conduition=20 >> >> >> >> On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty < >> er...@q32.com> wrote: >> >> >>> >>> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs=20 >>> tapscript, and the only available tapscript supporting output type, P2T= R,=20 >>> isn't quantum safe. >>> >> >> false, covenant based multistep secret-reveal spending paths don't rely= =20 >> on signatures at all >> >>> >>> I'm going to assume:=20 >>> - you mean to use this commit-reveal for migrating between signature=20 >>> 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= =20 >>> confirmed on-chain rather than lifeboat's out-of-band commitment system >>> >> >> it's used so you can commit to a spending constraint without committing= =20 >> to the final "as yet to be determined" quantum-safe destination:=20 >> https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-c= tv-op-txhash-and-no-new-signatures/2168 >> >>> Once you post your commit-txn, but before it confirms, other parties ca= n=20 >>> post competing commit-txns that double spend your output. If one of=20 >>> malicious transactions confirm, you must now wait for a timelock to exp= ire=20 >>> and then try to post your transaction.=20 >>> >> >> agreed. they have to spend resources to attack your private key and the= =20 >> only thing they can do is "grief" using a timing attack with the results= ,=20 >> rather than steal outright. a massive incentive difference.=20 >> >>> They can block you again. Each time they burn some of you coins in fees= .=20 >>> Miners get the fees, so they might be incentivized to do this. Thus, we= =20 >>> must trust miners not to do this. Lifeboat doesn't have this issue sinc= e it=20 >>> uses out-of-band commitments, but out-of-band commitments have their ow= n=20 >>> issues. >>> >> >> each time you use the reset-path, they have to re-attack a new key. very= =20 >> expensive just to grief a small amount of fees spread across all miners.= =20 >> sounds like science-fiction levels of compute.=20 >> >> plus.... TX_HASH is simple and generally useful and there is no guarante= e=20 >> that q-day will even come >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/CAJowKgL5okUA%3DDHSyUJfzdb6= p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.com >> . >> >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/ByJc1I7sSQAMLnAzSHPi8KSSscU= 0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B= 5e6BQ%3D%40proton.me >> . >> >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-K= IK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3x= oW4Js%3D%40proton.me=20 >> >> . >> > --=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/= 0b534992-146b-46bd-8865-56b7afda31adn%40googlegroups.com. ------=_Part_79915_807104973.1771551675458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 So, if we talk about disabling obsolete cryptogra= phy, then when OP_SHA1 will be disabled?

This is a dishon= est misrepresentation of the proposal in this thread. Nobody is arguing abo= ut disabling any algorithm. The proposal _explicitly_ states, that the same= Elliptic Curve signatures would still be the preferred default signatures = and that they merely would move from being implicitly default via the key s= pend path to instead being explicitly called upon via a spending script.
Please, do not strawman the proposal if you haven't read= it. Nobody is arguing about disabling Schnorr/ECDSA. Read the proposal bef= ore assuming.

torsdag 19 februari 2026 kl. 16:12:01 UTC+= 1 skrev Garlo Nicon:
> Future PQ Bitcoin wallet devs will see secp25= 6k1 as we today see broken primitives like md5 or DES.

We still have OP_SHA1 in the Script, and even in the TapScript, e= ven though there are known collisions for that. Also note, that MD5 is brok= en, only when it comes to collisions. MD5 preimages are still unknown, beca= use mounting a preimage attack is much harder.

So, if we talk about = disabling obsolete cryptography, then when OP_SHA1 will be disabled? I gues= s it won't change in the nearest future, even though the first SHA-1 co= llision happened in February 2017, around 9 years ago.


> Future devs shouldn't have to add legacy cruft EC librar= ies into their codebases when it's not even usable for cryptography any= more.

Well, to fully break OP_CHECKSIG, you n= eed to break both secp256k1 and SHA-256. Otherwise, by breaking only secp25= 6k1 alone, you will still have 40-byte DER signatures, and not 9-byte minim= al ones, where everything is fully broken. And it is possible to enforce a = given Proof of Work, if you use OP_SIZE on DER signatures. Even if you use = private key, equal to one, then still: you won't sweep everything, for = example from this transaction: aba3c2ae442aa20150996ee68f9aa4da83b57a431289= 1078be0c2e68c50b2801

Which means, that there are still use cases for= OP_CHECKSIG, even if you can break secp256k1, as long as you cannot break = SHA-256.

wt., 17 lut 2026 o 08:51=C2=A0'= ;conduition' via Bitcoin Development Mailing List <bitco...@googlegroups.com> napisa=C5=82(a)= :
> 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-s= oft-fork



P2TRv2 means locking wallets into using elliptic curve code for as long a= s P2TRv2 exists, because you will always have to compute and verify the twe= aked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as we = today 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 ev= en usable for cryptography anymore.

E= ven if you assume a second P2MR-disable-soft-fork will be needed (which is = debatable), then it still pays to remove the inefficient and unnecessary cr= uft of EC crypto for the foreseeable post-quantum future. You might think o= f it as decoupling UTXO ownership from any specific public-key cryptosystem= .

Furthermore, if EC/keypath spending= is disabled, P2MR actually requires less witness space per input than P2TR= v2 because we dont need the now-useless internal key in a P2MR script spend= witness, whereas P2TRv2 will require it indefinitely until we can migrate = to another new address format in the distant future. See https://github.com/bitcoin/bips/blob/maste= r/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend

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

T= he only redeeming factor of P2TRv2 is that it saves a few dozen witness byt= es per input when using schnorr EC key spending, compared to P2MR spending.= For low-frequency use cases like cold storage, that doesnt matter much. At= current rates thats like 10 sats per input. For high frequency use cases w= here every vbyte counts like hot wallets, exchanges, mining payouts, etc, 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 qu= antum computer attacks them. I'm assuming these high-frequency use case= actors are online enough to take that last step when necessary.

Thus i see P2MR as the superior choice to P2TRv= 2 even if P2TRv2 may be slightly more space efficient in the near-term. Thi= nking longer term, P2MR is the better choice.

Thinking even further into the future, we have options for a sort = of P2TR-style of address using isogenies, by hiding a commitment to a tapro= ot-style script tree inside a public key curve (public keys in isogeny cryp= tosystems are represented by elliptic curves). Keypath spending would be vi= a SQIsign (or other schemes). So don't worry, we are not stuck with onl= y merkle trees forever. I'll elaborate more on this idea in a forthcomi= ng article i have cooking on isogenies.

> ZK proof-of-seedphrase

If we were going to use a ZK proof to rescue quantum procrastinato= rs, it should be proof of BIP32 hardened key derivation, and possibly also = proof of pubkey hash preimage knowledge. This is strictly more general than= a zero-knowledge proof of seed phrase, the arithmetization would be wayyy = more efficient, and would recover more coins from more diverse wallet types= .

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 has been discussed on the list previously= (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 transacti= ons which ultimately proves the sender knew a BIP32 parent xpriv (or pubkey= hash preimage) which controls the coins in question through hardened BIP32= CKD, which a CRQC shouldn't be able to forge.

This would maximize rescue coverage while minimizing blockspa= ce congestion, and could be done as a soft fork.


-----

I= 9;m glad to see thoughtful discussion on the subject of how to handle a qua= ntum 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 NE= ED to do if Bitcoin is to survive appearance of a CRQC - is to provide a st= andardized wallet address format which includes a secure fallback way to au= thenticate UTXOs if ECC is unsafe to use. We can debate about freezing or r= escuing coins, or the philosophy of ownership, but these questions will not= be decidable for years.

What is deci= dable 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.


I've gone through and catalog= ued some of the feedback on Ethan's proposal. So far I've heard the= se material critiques:


1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to i= mplement commit/reveal?

As i mentione= d in my last message i don't think that is possible, at least not using= the technique Erik linked. I'd be happy to be proven wrong here becaus= e that'd be fantastic news if true.

2. Why not use SHRINCS instead of SLH-DSA?

Seems like a valid idea to me. SHRINCS would add im= plementation and UX complexity but it'd also make the fallback sig sche= me 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 disl= ike statefulness in a cryptosystem, but maybe as a fallback it is an accept= able tradeoff.


3. Why = not deploy GSR and let wallet devs roll their own crypto?
=
As ethan pointed out, this would be bad for standardiz= ation and interoperability, and also requires GSR to be deployed as a pre-r= equisite. If GSR is activated and in-script signing schemes are standardize= d correctly, it could possibly be a suitable alternative to activating dedi= cated SLH-DSA opcodes.


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

As ethan pointed out, this depends on timing a future disabling soft for= k correctly and will lead to FUD, avoidable debate, and confusion. It is al= so 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 i= nto a future keypath-disabling soft fork?

<= span>Ethan and i have both made some compelling arguments as to why we shou= ld 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, 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= tradeoff for (speculative) quantum security, and the costs of clinging to = those savings in the near-term to be unacceptable. Key-path spending may be= reinvented in the future using other novel cryptosystems, with another new= address format that depends on new cryptographic assumptions.
=

-----

I apo= logize if i missed anyone's feedback notes in this summary. Please corr= ect me if i have!

regards,conduition


On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' vi= a Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi list, just wanted to pipe= in on the subject of commit/reveal using OP_TXHASH. I don't think it i= s possible. 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 itself. On one hand 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 techni= que seems to require a priori knowledge of template hashes T and E when cre= ating 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.

reg= ards,
conduition


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


You'd still n= eed=20 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

I'm goi= ng to assume:
- you mean to use this commit-reveal for migrating betwee= n signature algorithms, not for everyday use,
it can be used if "q day" happens. otherwise ignore= d.
- 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 syst= em

it's used so you can commi= t to a spending constraint without committing to the final "as yet to = be determined" quantum-safe destination: https://delvingbitcoin.org/t/a-qua= ntum-resistance-script-only-using-op-ctv-op-txhash-and-no-new-signatures/21= 68
Once you post your commit-txn, but before it conf= irms, other parties can post competing commit-txns that double spend your o= utput. If one of malicious transactions confirm, you must now wait for a ti= melock to expire 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 atta= ck with the results, rather than steal outright. a massive incentive difference.
=
They can block you again. Each time they burn some of you coins in fee= s. 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 sinc= e it uses out-of-band commitments, but out-of-band commitments have their o= wn issues.

each time you use the reset= -path, they have to re-attack a new key. very expensive just to grief a sm= all amount of fees spread across all miners. sounds like science-fiction = levels of compute.

plus.... TX_HASH is simple and gene= rally useful and there is no guarantee that q-day will even 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 bitc= oindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.co= m.

--
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 bitc= oindev+...@googlegroups.com.
To view this discussion visit https://gr= oups.google.com/d/msgid/bitcoindev/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6= VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%3D%40pr= oton.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 bitcoindev+...@googlegro= ups.com.
To view this discussion visit https://groups.google= .com/d/msgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8= eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%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/bitcoind= ev/0b534992-146b-46bd-8865-56b7afda31adn%40googlegroups.com.
------=_Part_79915_807104973.1771551675458-- ------=_Part_79914_2132343990.1771551675458--