From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 16 Feb 2026 23:51:25 -0800 Received: from mail-oi1-f191.google.com ([209.85.167.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vsFrf-0000aU-St for bitcoindev@gnusha.org; Mon, 16 Feb 2026 23:51:25 -0800 Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-463b565032dsf27438376b6e.1 for ; Mon, 16 Feb 2026 23:51:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771314677; cv=pass; d=google.com; s=arc-20240605; b=JYJuHQ3nnvtjvRIDsXNrAzERIeAM0CbpB7EvBETx6c1Sh3eSiUfqPGw6bJ1Aizo4Og FyocraRipT/NL+O2IPF2duhNsN5SYI38Q3ubN9+AHUEqcK3fJQq69JydkebiFBYRpN5y 3EF5HsiZxHYW6/oOpQXK9XDkeKQZ/yle461qpOQC7Un1jxuaTgLSU/1LJrUWkW8/bxlF czXNIdSU9cuG21Jd+dCKYvgC/RYliiNJ1ijTaU+1NaIRctv1Jt3RHC/dO0rvwUB5HHXv IUTYY7DTUXWGhxAbepQbepnM8jD/ZtWhskCOvy0nOhiJk+nXUUXppj3AinosHDGyYCPg K54Q== 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=lzUMX85PCD7ZKUd197SJmYYSOIAOvfTlWjmWvnJWKkc=; fh=q/BCw4NAyUXUQe1mrxsTIEQEfHlixzIdQvWTupMbTj0=; b=ceeuWxVyup3ql7En8skPpezQSVDV+DkMfNwSReHFJF+vxfDicfvpl/QL/mbd1dIJKm vUL6SfrlrcZi/5lSAmzJMp94bjG6Iz7MF5PN00h4Qnyv52d2tzP5AM6syCPl5Yosmx0y V3osR5RpwFH/vVuBk9nbAS8X7k2J8L3KylF0r/r67ca20jFHNyKsCyb1X2fr4aqUJOHk JgTEl4WGHJmd+Fh+lQfmclriIxygZM03r1/CpFgmyt/VwnFyMSaewtJCL0DdtMZzRAVm nZbhFCgc2AtKEjqVyOW7Xqg2X8BBkCJ7VTJZhQ2UC3qIjB/Gy/SiR+VcMKF6nItXork/ iCYw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="WfD8E/Q3"; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 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=1771314677; x=1771919477; 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=lzUMX85PCD7ZKUd197SJmYYSOIAOvfTlWjmWvnJWKkc=; b=Wj2+X6Nf0iN1V18FgAhUB5q9gmzSy5pvvGmgGpGnQPwvhQUy+nWFwE17z0NOLP/QV/ Zs4cJ57IV2EdkWHE1GMNU8r670CwJOfsw4wwm5RTitcTjMlyiYBQnlYAacXYxPTKdTlQ BXaUXllyTrt88uQESSdV0f/5iS3z97IK86ppN/t/R2U1OiddijXfGRnzTlVohikc5DJZ KxGydufGAh8IlLBWVd6XKVVZ1Qq87/PdRhVb5oG5mO4DnyAmtFdHK5ukMLa0H4ceeT18 DuEl8BHghrMaH3M1cPvP0TPUVRaOM+uI8MPWiE3C+PyMoR9tgidawSG/IBpInnfusJs4 jD/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771314677; x=1771919477; 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=lzUMX85PCD7ZKUd197SJmYYSOIAOvfTlWjmWvnJWKkc=; b=mIaJWsagYJ2UEFBryX6ym1z85+anXtEZzfJoYGONbY3BR8TtLMlkZ0ghT2yPZsUuUk diITOyyrEAHsK0I3YU2pDfQzoBgih32DtNaKJ+9ayVLuUShGf9IcXtgahoDwJDPefJvp XmaF+p65ryWDSL1eI43dPHlt1l1RVF7Jf0UXUco5enLcR9slXpvuob4T7zRPMP+qtPQD feOTgeYoSvdlLPTWNQsJVQavdDv0PTqDiYe1HeF9BHMb+64OOEc08c5INx1JvJA+LTS9 MO+qVffUfoCpGi8SMqm4h0ATlz7gQp+tnFjNe3MKVPM0Yo2+ZFkEF0RueqpD6kiw9+uN WT0Q== X-Forwarded-Encrypted: i=2; AJvYcCWBrVfbrkdKDGisnNr9rjWKf3anB5JS55C//t1kglc9hdNY1e14aoAFLVYwhgAnNh9IWTJqZfo80nvV@gnusha.org X-Gm-Message-State: AOJu0YzoERQOY5Xgtb7vfvhTZ5w0Z8dyDHhNhWBR5kXEufd1Hxx0uPA/ i2wUUAw3C6RkcODSGmQj80oCBcvCfIk+k8WzUikC2DbO+mcdZm4QmpIJ X-Received: by 2002:a05:6808:c1e8:b0:450:a9d0:b790 with SMTP id 5614622812f47-4639f1f3886mr6426418b6e.46.1771314677402; Mon, 16 Feb 2026 23:51:17 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+G46afrumuQ/PlJTzbTw9RLXgfz/WodYY3Xw84fkE+C3A==" Received: by 2002:a05:6871:d10e:b0:404:2f39:e1c0 with SMTP id 586e51a60fabf-40eca697e32ls3830391fac.2.-pod-prod-08-us; Mon, 16 Feb 2026 23:51:12 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCX9Rvm6En8ffZMF6a9IZY1rYGD4czXnR9vkQVa/wv/Ur1s5njRmOseMNYIjqRXr+NvJ/rF20uL0cERL@googlegroups.com X-Received: by 2002:a05:6808:1806:b0:45a:6cf0:68c1 with SMTP id 5614622812f47-4639f2243b9mr6810330b6e.58.1771314672390; Mon, 16 Feb 2026 23:51:12 -0800 (PST) Received: by 2002:ab3:6342:0:b0:2cb:e387:155d with SMTP id a1c4a302cd1d6-2e5e59e8dc6msc7a; Mon, 16 Feb 2026 23:39:31 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCUtk5ZEUVAwTQr2CYK798H8u5hjOwRJWjRxwW5S0VOaKQu+KYizuKYjIMILGa/QEpEhkw1FMb1cW/nD@googlegroups.com X-Received: by 2002:a05:6512:318c:b0:59e:aba:d193 with SMTP id 2adb3069b0e04-59f6d378689mr2936303e87.24.1771313968806; Mon, 16 Feb 2026 23:39:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771313968; cv=none; d=google.com; s=arc-20240605; b=KgkWGmVBEZOyeziv7TTZ/hDkPWf82fqTcNWj2dfwktjnQ2vA02NZv4M7ARyA/2x6IC ejG9oapTTFAuVVYHxA21UjKcrCvNl//g5ljslZ0TAiRhMuRWiJOH5YpAC9iBEDP2km48 Bsz75kFxvT626mn7Qr0Z9CuHDH8d4SQrQ5O4YT9C2vjpm0d4dHVv5oNKkv30lZFlNSX9 Vl3CDrfbu/ODyc3h5UrE3UtBiJEvGHGuDVjlCeOJyfsSTGIvEhh+TtqMnx7LNWeJBYIy 4Uqyu+00y+HH0MQyAs/B1HdcuKpGpatHOkz84E2a7mYt7VDMlozAlt17cycqQszWG2p1 UXcg== 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=Bal6bSYdqLSETWEePjLIqIveXPzCS157m/9tFrNHXvk=; fh=3+uASwMjPD74uNvxLp2h2wkt79Eyq19TwQqWD0xa6VM=; b=U/dXqj8HRuPny64hHFMjNKZdYiAnBxMZuzOUORiF8n0mtZ+Vs/wVQI78wE1xiEy0uB wyFsLN/YSILTvWlh0XWUuxrLhEnhD1iNHVZJljHLRbSL6Hl87au++b67cv6NoKov9mG8 MN/igvklIjPcSD0p8ubFzbCbRkbOGwcAF7s1MIjDjmv/R6g7+XYCQ87WyGyoy5HPAiND UUKO+burRhTI8RQPA2TFLGUry9GbwvLsV752pUyC0GleksO8XaUMQJKbjw59VW1NY4En zzbk72apBIAmYu7TUudgxNZI3gIaZMsfBUTnJSvLkj/ofB9+9ZCq51dycesDDsmqJ7Jo rn9w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="WfD8E/Q3"; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10697.protonmail.ch (mail-10697.protonmail.ch. [79.135.106.97]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-59e5f58e03fsi453829e87.4.2026.02.16.23.39.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 23:39:28 -0800 (PST) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.97 as permitted sender) client-ip=79.135.106.97; Date: Tue, 17 Feb 2026 07:39:22 +0000 To: conduition From: "'conduition' via Bitcoin Development Mailing List" Cc: Erik Aronesty , 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: 62cf4ca6063d2b2ca5e9a7498218eb329ea3d4db MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------63781fe3c80b0a66a1ca0ac9b0068d84c7fb0aadeafe67bed6bd5bfd0b8a71cb"; 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=protonmail header.b="WfD8E/Q3"; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.97 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) --------63781fe3c80b0a66a1ca0ac9b0068d84c7fb0aadeafe67bed6bd5bfd0b8a71cb Content-Type: multipart/mixed;boundary=---------------------f1616ba7e4d9bb820dc55242f2c2f411 -----------------------f1616ba7e4d9bb820dc55242f2c2f411 Content-Type: multipart/alternative;boundary=---------------------82ec313b1be7df03d845638b80f9d2fb -----------------------82ec313b1be7df03d845638b80f9d2fb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > I just don't see a reason to do P2MR over just utilizing P2TR (or maybeP2= TRv2). > > P2MR will *also* require an equivalent P2MR-disable-soft-fork 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 tweak= ed output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 as we to= day see broken primitives like md5 or DES. Future devs shouldn't have to ad= d legacy cruft EC libraries into their codebases when it's not even usable = for cryptography anymore. Even 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 c= ruft of EC crypto for the foreseeable post-quantum future. You might think = of it as decoupling UTXO ownership from any specific public-key cryptosyste= m. Furthermore, if EC/keypath spending is disabled, P2MR actually requires les= s witness space per input than P2TRv2 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 dis= tant future. See https://github.com/bitcoin/bips/blob/master/bip-0360.media= wiki#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 P2MR, unless you count code = reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, and less = block-space-efficient for script path spends. So who would choose P2TRv2 ov= er P2MR? The only redeeming factor of P2TRv2 is that it saves a few dozen witness by= tes per input when using schnorr EC key spending, compared to P2MR spending= . For low-frequency use cases like cold storage, that doesnt matter much. A= t current rates thats like 10 sats per input. For high frequency use cases = where every vbyte counts like hot wallets, exchanges, 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 PQ address before a quantum com= puter attacks them. I'm assuming these high-frequency use case actors are o= nline enough to take that last step when necessary. Thus i see P2MR as the superior choice to P2TRv2 even if P2TRv2 may be slig= htly more space efficient in the near-term. Thinking longer term, P2MR is t= he better choice. Thinking even further into the future, we have options for a sort of P2TR-s= tyle of address using isogenies, by hiding a commitment to a taproot-style = script tree inside a public key curve (public keys in isogeny cryptosystems= are represented by elliptic curves). Keypath spending would be via SQIsign= (or other schemes). So don't worry, we are not stuck with only merkle tree= s 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 procrastinators, it sh= ould be proof of BIP32 hardened key derivation, and possibly also proof of = pubkey hash preimage knowledge. This is strictly more general than a zero-k= nowledge proof of seed phrase, the arithmetization would be wayyy more effi= cient, 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 ST= ARK. Rescue could be deployed using a commit and reveal protocol, as has be= en discussed on the list previously (sorry, i dont have the link in front o= f 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 k= new 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 blockspace congestion,= and could be done as a soft fork. ----- I'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 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 feat= ures: 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 catalogued some of the feedback on Ethan's proposal. = So far I've heard these material critiques: 1. Why not instead deploy covenant opcodes (TXHASH, CTV) and use them to im= plement commit/reveal? As i mentioned 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 b= ecause 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 comp= lexity but it'd also make the fallback sig scheme scalable - a very nice pr= operty 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 crypto= system, 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 interoperab= ility, and also requires GSR to be deployed as a pre-requisite. If GSR is a= ctivated and in-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 t= han adding a whole new address format? As ethan pointed out, this depends on timing a future disabling soft fork c= orrectly and will lead to FUD, avoidable debate, and confusion. It is also = confiscatory, as it would freeze standardized keypath-only P2TR outputs whi= ch 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 some compelling arguments as to why we should gi= ve the community a new address format which is totally decoupled from any P= Q-vulnerable cryptography. If the increased fees of P2MR are an issue for h= igh-frequency hot wallets, P2TR is still viable, at least until Q-day. As s= tated Ethan's proposal is more motivated by long term cold storage use case= s. I consider a small increase in witness size to be an acceptable tradeoff= for (speculative) quantum security, and the costs of clinging to those sav= ings in the near-term to be unacceptable. Key-path spending may be reinvent= ed in the future using other novel cryptosystems, with another new address = format that depends on new cryptographic assumptions. ----- I apologize if i missed anyone's feedback notes in this summary. Please cor= rect me if i have! regards, conduition On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin Develo= pment Mailing List wrote: > 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 ( https= ://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-tx= hash-and-no-new-signatures/2168 ) seems to contradict itself. On one hand t= he author says phase zero doesn't commit to final CTV templates E & T. Howe= ver it also says T & E are committed to via the P_anchor tapscript tree, wh= ich must be pinned by phase 0. So unless I'm misunderstanding, this techniq= ue seems to require a priori knowledge of template hashes T and E when crea= ting the funding address and UTXO in phase 0, so this would not be viable a= s 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 tapscr= ipt, and the only available tapscript supporting output type, P2TR, isn't q= uantum 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 signature = 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 system > >=20 > >=20 > > 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://d= elvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ctv-op-txhash= -and-no-new-signatures/2168 > >=20 > > > 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 mal= icious 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 results, = rather than steal outright. a massive incentive difference. > >=20 > > > They can block you again. Each time they burn some of you coins in fe= es. Miners get the fees, so they might be incentivized to do this. Thus, we= must trust miners not to do this. Lifeboat doesn't have this issue since i= t 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. ver= y expensive just to grief a small amount of fees spread across all miners. = sounds like science-fiction levels of compute. > >=20 > > plus.... TX_HASH is simple and generally useful and there is no guarant= ee that q-day will even come > >=20 > > -- > > You received this message because you are subscribed to the Google Grou= ps "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send = an email to bitcoindev+unsubscribe@googlegroups.com. > > To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/CAJowKgL5okUA%3DDHSyUJfzdb6p_z5a6H_hN6NuhZo6R9ZYbJFUQ%40mail.gmail.com. >=20 > -- > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/ByJc1I7sSQAMLnAzSHPi8KSSscU0qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFl= Suxm4RCoT5rtKT68Khdi2xjwYIu4B5e6BQ%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/= GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC= 5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me. -----------------------82ec313b1be7df03d845638b80f9d2fb Content-Type: multipart/related;boundary=---------------------05dd7defeafadea24fdad61a07cdc502 -----------------------05dd7defeafadea24fdad61a07cdc502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> = I just don't see a reason to do P2MR over just utilizing P2TR (or maybe
P2TRv2).
>
&= gt; P2MR will *also* require an equivalent P2MR-disable-soft-fork



P2TRv2 means loc= king wallets into using elliptic curve code for as long as P2TRv2 exists, b= ecause you will always have to compute and verify the tweaked output pubkey= . Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken p= rimitives like md5 or DES. Future devs shouldn't have to add legacy cruft E= C libraries into their codebases when it's not even usable for cryptography= anymore.

Even 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 cruft of EC crypto for the f= oreseeable post-quantum future. You might think of it as decoupling UTXO ow= nership from any specific public-key cryptosystem.

Furthermore, if EC/keypath spending is disabled, P2MR actuall= y requires less witness space per input than P2TRv2 because we dont need th= e now-useless internal key in a P2MR script spend witness, whereas P2TRv2 w= ill require it indefinitely until we can migrate to another new address for= mat in the distant future. See https://github.com/bitcoi= n/bips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spen= d

P2MR is strictly more secure si= nce it depends on weaker assumptions. P2TRv2 is more complex for wallets to= implement than P2MR, unless you count code reuse from P2TRv1. P2TRv2 is (m= arginally) computationally slower, and less block-space-efficient for scrip= t path spends. So who would choose P2TRv2 over P2MR?

<= /div>
The only redeeming factor of P2TRv2 is that it saves a few = dozen witness bytes per input when using schnorr EC key spending, compared = to P2MR spending. For low-frequency use cases like cold storage, that doesn= t matter much. At current rates thats like 10 sats per input. For high freq= uency use cases where every vbyte counts like hot wallets, exchanges, minin= g 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 PQ address befo= re a quantum computer attacks them. I'm assuming these high-frequency use c= ase actors are online enough to take that last step when necessary.<= /div>

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

Thinking even further into the future, we have options for a so= rt of P2TR-style of address using isogenies, by hiding a commitment to a ta= proot-style script tree inside a public key curve (public keys in isogeny c= ryptosystems are represented by elliptic curves). Keypath spending would be= via SQIsign (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 ar= ticle i have cooking on isogenies.


> ZK proof-of-seedphrase

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.

Also, there is no need for it to be a he= fty zero-knowledge proof, like a STARK. Rescue could be deployed using a co= mmit and reveal protocol, as has been discussed on the list previously (sor= ry, i dont have the link in front of me right now). The idea is that a send= er can rescue frozen UTXOs using a commit/reveal sequence of transactions w= hich 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.

<= span>This would maximize rescue coverage while minimizing blockspace conges= tion, and could be done as a soft fork.

-----

I'm glad to s= ee thoughtful discussion on the subject of how to handle a quantum freeze. = But it is important to put this in perspective in the context of this threa= d: right now the number one most important thing - which we NEED to do if B= itcoin is to survive appearance of a CRQC - is to provide a standardized wa= llet address format which includes a secure fallback way to authenticate UT= XOs 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.

What is decidable is this= : how would you change Ethan's proposal, if at all? I'll remind everyone th= at currently it is limited only to adding two features: BIP360 P2MR address= es, 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 catalogued some of the feedback = on Ethan's proposal. So far I've heard these material critiques:


1. Why not instead deploy covena= nt opcodes (TXHASH, CTV) and use them to implement commit/reveal?

As i mentioned in my last message i don't thin= k that is possible, at least not using the technique Erik linked. I'd be ha= ppy to be proven wrong here because that'd be fantastic news if true.


2. Why not use SHRINCS inst= ead of SLH-DSA?

Seems like a valid id= ea 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 pointed out, this w= ould be bad for standardization and interoperability, and also requires GSR= to be deployed as a pre-requisite. If GSR is activated and in-script signi= ng schemes are standardized correctly, it could possibly be a suitable alte= rnative to activating dedicated SLH-DSA opcodes.


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

As ethan pointed out, this depends on timing a= future disabling soft fork correctly and will lead to FUD, avoidable debat= e, 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 ve= rsion number, which opts into a future keypath-disabling soft fork?<= /div>

Ethan and i have both made some compelling a= rguments 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, P2TR is still via= ble, 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 si= ze to be an acceptable tradeoff for (speculative) quantum security, and the= costs of clinging to those savings in the near-term to be unacceptable. Ke= y-path spending may be reinvented in the future using other novel cryptosys= tems, with another new address format that depends on new cryptographic ass= umptions.

-----

=
I apologize if i missed anyone's feedback notes in this su= mmary. Please correct me if i have!

r= egards,
conduition


On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoi= n Development Mailing List <bitcoindev@googlegroups.com> wrote:
Hi list, just w= anted to pipe in on the subject of commit/reveal using OP_TXHASH. I don't t= hink it is 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 con= tradict itself. On one hand the author says phase zero doesn't commit to fi= nal CTV templates E & T. However it also says T & E are committed t= o via the P_anchor tapscript tree, which must be pinned by phase 0. So unle= ss I'm misunderstanding, this technique seems to require a priori knowledge= of template hashes T and E when creating the funding address and UTXO in p= hase 0, so this would not be viable as a PQ fallback spending path. Happy t= o be proven wrong.

regards,
conduition



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

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

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 th= ere is no guarantee that q-day will even come

--
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://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@googlegroups.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/GhzGKZ= 5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7= jnMRS85GzOzcmCt9v5R3xoW4Js%3D%40proton.me.
-----------------------05dd7defeafadea24fdad61a07cdc502-- -----------------------82ec313b1be7df03d845638b80f9d2fb-- -----------------------f1616ba7e4d9bb820dc55242f2c2f411 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== -----------------------f1616ba7e4d9bb820dc55242f2c2f411-- --------63781fe3c80b0a66a1ca0ac9b0068d84c7fb0aadeafe67bed6bd5bfd0b8a71cb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmmUGxsJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcgBzrlQRJBaFovu8LBC3MzpAv91jtA83G+z3Vh rYcdrBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAt6AD/bZbY3VOAymTdK8dN 5dgsxBWstWp9O5zB2fVDCW4eXOAA/A/azTuwh2d96SkxrQpTGpWGzU0rxJps +zOZ99WVowED =pPFw -----END PGP SIGNATURE----- --------63781fe3c80b0a66a1ca0ac9b0068d84c7fb0aadeafe67bed6bd5bfd0b8a71cb--