From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 24 Feb 2026 19:41:59 -0800 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vv5mf-0001Q6-Vz for bitcoindev@gnusha.org; Tue, 24 Feb 2026 19:41:59 -0800 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-463a075e177sf27767902b6e.2 for ; Tue, 24 Feb 2026 19:41:57 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1771990912; cv=pass; d=google.com; s=arc-20240605; b=ADzsglT5k7ZbAQT//5p/WFJvhW/mdZoqxv5foUaSCETqvHlMMvrfVF7EWRbsSpQyXt 0oRPFkfbI+Wj1UptrWpprbHjQD6fXrhrK+EtdNAiEY1F3DuoUq0seBV5Xoq3RC60sp2N RdxIhE9lexHhWvq/ka0PudRe0WSBLhSZjMBSkiX+hB/xL+82WbGgJldUnmHArAzvKeKx erlznHcNBdZaPiLC2FTdyk0ITiphAYoUCmoMIqJCMRoAf9VP3u10uxWOXWpbGgYIGAew 6hysfJhJETZmpKMspmRoE41x6rXz1XP7SlH8c/UvxHzfXLD1z//25WC1BRY6lsnA9d15 hcsQ== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=Wj2QBgHSmkLldQ1Eg+q8qCQY9FK9C3HbRrKTAZclFYQ=; fh=gps2YHoGb0GGkiHSzQ1xy2mtuPhO/1xwAIrswVh7Dc4=; b=RkFAfyb9H17wRGtUj+PKp/gtsW2Sw0Xa5WU7qwMCr7iaa7fScV062WYKpBxjCf7/Jq wqp4l2vtXtKJr+8eyW8HQUJRcVu1JABddJ080Knhw0os7jO8njgcog9Q+5A1nD9bgwVB g2Zw9SHweO0/c0+Bp22NppVx7VzKYjVWPQYf1DkHvp78w1anAa0kqXg6V5JcL3V7ClL2 uogk0K/xwQzYfkRN9ZUA866iEk3VI9AuJ9F+/5TSqdC/PePJjAAnqL+NfbZxTkxlQZWJ 1hnVaJR5clwNW8xNbRgz++VhADdStWVgCUjMOwU0wKcyy3RQT7PaKZS/+D6Fsy5wHoUw pwjQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=GS5yL+W5; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771990912; x=1772595712; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Wj2QBgHSmkLldQ1Eg+q8qCQY9FK9C3HbRrKTAZclFYQ=; b=baHjeK6bBEfWeloQqc6VQvdM1bqy2MpDPtPX1M9mjc32VYvlySIR7UNAfz3ZQlCt8T PXadPJS9haEcX9XSd785wcQugQVjaFIMZnuoGklowj8An+cGyk/P3noJ95FrGNUvP8Ng fP+oB+czM0ILw7MT6mMfpRWPo/MdwZnlPK33njd9BztgxhsUreYzR1HELms9nuTgcM9I 585Q17A0hlNdVA2WoH/IpQsmvGLvqhyUcSA/Peu8GxIadaOZLsleQJHB/724aTlFwwJ1 SEtR5yvefq8OpnZNhmIVwn8+PC4s+P5tQEKobQw7vwam/m4rM7j2EO6SJQIhSYgKOQU1 0ckw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771990912; x=1772595712; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Wj2QBgHSmkLldQ1Eg+q8qCQY9FK9C3HbRrKTAZclFYQ=; b=R7jsC8GngS7YX5MHJCYHen0sqTJyJSL747iNm5YYn6vqm3E2XL80u2cmnAYi342aoU MYKOUA3YckzKb33AFhNDyKukWNXHHR4aZyjWf/XYNuwocAMCpC4r3loUkJ7nq1EGcHbL VTmbOYPs3t7bb/kPvczRJ9unGdEpQLGYCDrb6uEYZd/pzcLM7QBZlMjGghpZw3EkxGyI X56bc6OX3PhS2EmIV67i7dneQYtUwT8WWrDMN0vmOgh2CvGggXfrTinmfp0wwHPaAu1l cWdDK3crsbPmf8H3HiEM+8Q2mNlgP+J3DyV+NPW7jUoRMymN1blez112I8s79w5RYMCI llfg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUa4H7aiIrvv54/AEy02sW/CCFRFskTKEshH+INY582aN8k56NvwKdQE+/7rkn5NQ+BIPuk8nKVjnvb@gnusha.org X-Gm-Message-State: AOJu0YwnwW+h5amtwUPs1Cwz4eMm2r2U5KrraA5X98DwueZaVEzu6OG7 LmiM1fCjwEYCIIZT72g9/3Q/K1AZpWJxxH4vFFiSFhLODDgEyCstrje7 X-Received: by 2002:a05:6808:d4a:b0:450:471:b9ba with SMTP id 5614622812f47-46491307408mr396273b6e.14.1771990911306; Tue, 24 Feb 2026 19:41:51 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HLcRGBTebgF1d07l09PdxaPCiGbF7guRiHWbSNhNiVvQ==" Received: by 2002:a05:6871:587:10b0:40f:17a9:2919 with SMTP id 586e51a60fabf-415f01f39dbls57087fac.0.-pod-prod-06-us; Tue, 24 Feb 2026 19:41:47 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVLVuZSawdnU75RysvGjbdcuRrNzEd/7/buLs8U6ncykv7P9OdMI2oKBqTVSh4EDD0N0gcFMXOi7B8W@googlegroups.com X-Received: by 2002:a05:6808:1781:b0:45f:1387:973b with SMTP id 5614622812f47-464912c274amr397895b6e.6.1771990907263; Tue, 24 Feb 2026 19:41:47 -0800 (PST) Received: by 2002:a05:600c:5908:b0:483:6a76:922 with SMTP id 5b1f17b1804b1-483702f5e0ems5e9; Fri, 20 Feb 2026 10:48:43 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVCLX6CxmH5bel5jL3AyUHJudDwzniaREn3uZxMN7zoMMeiE+dYnHBBLmh+RZ7G+MErJQkbf+mPwY1M@googlegroups.com X-Received: by 2002:a05:600c:8b01:b0:46e:35a0:3587 with SMTP id 5b1f17b1804b1-483a95ef65bmr8732975e9.27.1771613321025; Fri, 20 Feb 2026 10:48:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771613321; cv=pass; d=google.com; s=arc-20240605; b=K9iSaHH37NwcZ7+bBHqcqEgPBU1Y38p89pchF2Ein/wLUKP4UgxModC5CkVgS/8m0+ YY+P+dZI6NJUM7LLyzT/szXU6HXGxYYd80VziKtoHE9QfyxrCX3POprTNvcTSHHtE3V6 NvTrr1tFsRQaxlbUHq1ZU03WYzmra4tY5iWq2ORibUHPlvaaoRUn1kIlkG9em7l/+Qcn NMLxUm+v3duEoEEaBvkHZOX5x2eqi0VPfU9ZqNu9M3mo2UapyOqp0r7QB3LQxGrNjoyC U6fG4APqOynbnnOMAHBBQT7WasyksniNyft/A56z+dvXZOWlnqUXd7qux14KtLmax9TZ /ymA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=g+dfkj197Jv/c87/iSptNGhj/baSKaU+9yqFdbQaKYQ=; fh=t5Tr4pGoo7VqrrcwlhbipKmMC+mJ2U6PJhyJa5zu7yo=; b=fhLwLnIprNmawTod44tx/68I42h07G9KZr49BmjeC7PMvqOMzI5aiQb+9ev2TaIyoA qGy5piCxjBrNU4bm9AbxTfWaEEG4AjIjZIGKDr7j16kinsyFZYxBn9YT82GX4NJR7YwO zpg6hFX1mOrKXSbXJbUlQ8+Hg0PifehWPqceufFsTBkSVFuNygPU85aH9wnPEdRzlOkK KzhNTYfYBGuUtLKdu/6cGi2M5Q7DXcUIRmksp7roEBkoLf2uga26tFn3GE1kv/dtPDFz 6y+CeUK9unmIn+adDvcKJH37BuNF88h5ZLndwNUNohSSJCd8cUin6DaHfonkIzf4GyvZ i+lA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=GS5yL+W5; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com. [2a00:1450:4864:20::536]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-483a3dd7820si365205e9.1.2026.02.20.10.48.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Feb 2026 10:48:40 -0800 (PST) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) client-ip=2a00:1450:4864:20::536; Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-65808bb859cso3032503a12.2 for ; Fri, 20 Feb 2026 10:48:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771613320; cv=none; d=google.com; s=arc-20240605; b=T5YRSxhbSByBsDvd18PV1pAIGnpdH3B7wJkITqzyQQqllgQnkryL2p69i3GvJapAU9 51CItn9ByybX/apgWhqlv1UUVf5ziTl2dUjmNLXjwSX8DqlnNdgYw6uP+8Nn7GPtzjGj bqXTbJgd8CbLkvKO4SW6vxbT54zbUSqZ1hlV86nU4SgNCIHSu/KbISHFz3EUvfJdBkUO wtnFhQpNLY1P9xXWwKY6XOkulIxBhAM72Ws/cbTCXs1dyoD3VvU0SjWqKi7r2qVqZ3qj 21gN+bq6UkFNvEy/kksjh/VzAhH1agTlrQVqTzGJFY4Ad7XiCaTWWhmnqrO/lkCxfjXM jWxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=g+dfkj197Jv/c87/iSptNGhj/baSKaU+9yqFdbQaKYQ=; fh=t5Tr4pGoo7VqrrcwlhbipKmMC+mJ2U6PJhyJa5zu7yo=; b=lgdtqej1NkN4YLhx84bJONmi6ujoe9SQrRB0+4Azb6AtTDIKtAF6y8ZKOVlh+IqFaW 2fYS0t/jqSKa4TlU6PYFeNJ2eH5I2Ag01yij4QSEYgO2Rf0PV0SY8PAlBsmZyBCAW9zA +SZ1uBHj6c3+KnhCQQ66Gw/9G4QKyiPPtzE8H+q9W9FGf8xyxyoF9D2CTPPPkumfaNi9 WLwl3I3myZEn8KEZOx1f9kNGEoWE98nKRjta56amiQTU34O/KC4nr+kEW1xiNtKFwP8O t0d+ZLAQ8juoSN7hO/D+E05G1BJ46oiTGvHdxA0vaAVWVVos7b3khr5Uz94MeXFEB0HF Qw6w==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCXfYJ2G+wE+d91y01TRTeYYqTPDIW68ZXjoalCyN+iouLhN/Fw8uET6O+oOqDiG+G8AJ0XjBrw4yyX2@googlegroups.com X-Gm-Gg: AZuq6aJmoUXo25KGDpW06Bq3Ql59Ccp0KLMSD/A9n/f1eCGGjbtX/rVJhruFBzc2VVc fmIuXGd1V2MECKZL6JUB0JrGXvRM623xuGkflN4nHtt0eXk1SsPdsv4FNVcZq440GM77dKyJmK4 L5/0/LG0B8QUNLjmt1nJhY765Z9xbhw/PDFbgSuuJFl6HxBLAULlFXOGg5FMN6zl8JWg0XVLS/l bETUf6J/4yBEV3rv8+HqT45rjJkc4TXoWedQ61/ITCpwhCS5ox+GlRB65llPp8+E4/5lPw2cmc9 tn7acEBqvlUOYAOwwxK+pkKtYbNJFXIpsuKQtb5oW/FZzUH8qOmeNIN3kbJ9hFtVdlvDkWhyJ8G X X-Received: by 2002:a17:907:9308:b0:b88:5a74:4cd6 with SMTP id a640c23a62f3a-b9081b6ddc6mr31934366b.43.1771613319891; Fri, 20 Feb 2026 10:48:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Fri, 20 Feb 2026 10:48:28 -0800 X-Gm-Features: AaiRm50gHS5IVclErinqrGxq69qiVn_Gf79GWZbtdB8nl4e-tmT1QL_3qnACZdA Message-ID: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms To: conduition Cc: Ethan Heilman , Jonas Nick , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000009c927d064b45dec5" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=GS5yL+W5; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) --0000000000009c927d064b45dec5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Covenant backed multistep secret-reveal schemes are inherently quantum resistant (as long as we eliminate the mandatory nums-spend-path with a small optional tr version addition) It's clearly too soon to pick a signature scheme for quantum. Kyber is probably the most broadly accepted scheme, but nobody uses it without a hybrid approach, and it doesn't trivially support schemes like xpub key derivation. But it's NOT too soon to add covenants, which can give people peace-of-mind quantum-safe vaults without needing to trust new quantum sigs. On Mon, Feb 16, 2026 at 11:39=E2=80=AFPM conduition = 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 > > > > 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 > tweaked output pubkey. Future PQ Bitcoin wallet devs will see secp256k1 a= s > we today see broken primitives like md5 or DES. Future devs shouldn't hav= e > to add 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 unnecessa= ry > cruft of EC crypto for the foreseeable post-quantum future. You might thi= nk > of 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 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 distant future. See > https://github.com/bitcoin/bips/blob/master/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 P2MR, unless you cou= nt > code reuse from P2TRv1. P2TRv2 is (marginally) computationally slower, an= d > less block-space-efficient for script path spends. So who would choose > P2TRv2 over P2MR? > > 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 doesnt matt= er > much. At current rates thats like 10 sats per input. For high frequency u= se > cases where every vbyte counts like hot wallets, exchanges, mining payout= s, > 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 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 P2TRv2 even if P2TRv2 may be > slightly more space efficient in the near-term. Thinking longer term, P2M= R > 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 > taproot-style script tree inside a public key curve (public keys in isoge= ny > 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 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 procrastinators, 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 typ= es. > > 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 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 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 > quantum 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 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 to authenticate UTXOs if ECC is unsafe to use. We can debate > about freezing or rescuing coins, or the philosophy of ownership, but the= se > 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 > features: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes a= re > 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 > implement commit/reveal? > > As i mentioned in my last message i don't think that is possible, at leas= t > not using the technique Erik linked. I'd be happy to be proven wrong 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 > 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 user= s > 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 would be bad for standardization and > interoperability, and also requires GSR to be deployed as a pre-requisite= . > If GSR is activated 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 > 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 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 int= o > a future keypath-disabling soft fork? > > Ethan and i have both made some compelling arguments as to why we should > 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 fo= r > high-frequency hot wallets, P2TR is still viable, at least until Q-day. A= s > 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 ne= w > address format that depends on new cryptographic assumptions. > > ----- > > I apologize if i missed anyone's feedback notes in this summary. Please > correct me if i have! > > regards, > conduition > > > On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' via Bitcoin > Development 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-ct= v-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 a= re > committed to via the P_anchor tapscript tree, which must be pinned by pha= se > 0. So unless I'm misunderstanding, this technique seems to require a prio= ri > knowledge of template hashes T and E when creating the funding address an= d > UTXO in phase 0, so this would not be viable as a PQ fallback spending > path. Happy to be proven wrong. > > regards, > conduition > > > > On Wednesday, February 11th, 2026 at 1:06 AM, Erik Aronesty > wrote: > > >> >> You'd still need BIP 360 P2MR (or P2TRD) since OP_TXHASH needs tapscript= , >> and the only available tapscript supporting output type, P2TR, isn't >> quantum safe. >> > > false, covenant based multistep secret-reveal spending paths don't rely o= n > 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 rather than lifeboat's out-of-band commitment system >> > > it's used so you can commit to a spending constraint without committing t= o > the final "as yet to be determined" quantum-safe destination: > https://delvingbitcoin.org/t/a-quantum-resistance-script-only-using-op-ct= v-op-txhash-and-no-new-signatures/2168 > >> Once you post your commit-txn, but before it confirms, other parties can >> post competing commit-txns that double spend your output. If one of >> malicious transactions confirm, you must now wait for a timelock to expi= re >> and then try to post your transaction. >> > > agreed. they have to spend resources to attack your private key and the > only thing they can do is "grief" using a timing attack with the results, > rather than steal outright. a massive incentive difference. > >> They can block you again. Each time they burn some of you coins in fees. >> Miners get the fees, so they might be incentivized to do this. Thus, we >> must trust miners not to do this. Lifeboat doesn't have this issue since= it >> uses out-of-band commitments, but out-of-band commitments have their own >> issues. >> > > each time you use the reset-path, they have to re-attack a new key. very > expensive just to grief a small amount of fees spread across all miners. > sounds like science-fiction levels of compute. > > plus.... TX_HASH is simple and generally useful and there is no guarantee > that q-day will even come > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAJowKgL5okUA%3DDHSyUJfzdb6p= _z5a6H_hN6NuhZo6R9ZYbJFUQ%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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/ByJc1I7sSQAMLnAzSHPi8KSSscU0= qakPM2YI0qC6VBBOwzmYtQEW5NY6d80eLUCf7fmKxbdFlSuxm4RCoT5rtKT68Khdi2xjwYIu4B5= e6BQ%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/= CAJowKgL-hAxkb2uVTdHE%3Duo6%2BkRq1TEhabF_LNawE9K3j8_ivQ%40mail.gmail.com. --0000000000009c927d064b45dec5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Covenant backed = multistep secret-reveal schemes are inherently quantum resistant (as long a= s we eliminate the mandatory nums-spend-path with a small optional tr versi= on addition)
<= div class=3D"gmail-public-DraftStyleDefault-block gmail-public-DraftStyleDe= fault-ltr" style=3D"background-color:transparent">
It's clearly too soon to pick a signa= ture scheme for quantum. Kyber is probably the most broadly accepted scheme= , but nobody uses it without a hybrid approach, and it doesn't triviall= y support schemes like xpub key derivation.=C2=A0

But it's NOT = too soon to add covenants, which can give people peace-of-mind quantum-safe= vaults without needing=C2=A0to trust new quantum sigs.
=

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


P2TRv2 means locking wallet= s into using elliptic curve code for as long as P2TRv2 exists, because 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 primitives l= ike md5 or DES. Future devs shouldn't have to add legacy cruft EC libra= ries into their codebases when it's not even usable for cryptography an= ymore.

Even if you assume a second P2= MR-disable-soft-fork will be needed (which is debatable), then it still pay= s to remove the inefficient and unnecessary cruft of EC crypto for the fore= seeable post-quantum future. You might think of it as decoupling UTXO owner= ship from any specific public-key cryptosystem.

=
Furthermore, if EC/keypath spending is disabled, P2MR actually r= equires less witness space per input than P2TRv2 because we dont need the n= ow-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/b= ips/blob/master/bip-0360.mediawiki#comparison-with-p2tr-script-path-spend


The only redeeming factor of P2TRv2 is that it saves a few doz= en witness bytes per input when using schnorr EC key spending, compared to = P2MR spending. For low-frequency use cases like cold storage, that doesnt m= atter much. At current rates thats like 10 sats per input. For high frequen= cy use cases where every vbyte counts like hot wallets, exchanges, mining p= ayouts, etc, i have good news: P2TRv1 still exists and can be used just fin= e. You "just" need to make sure the coins are moved to a PQ addre= ss before a quantum computer attacks them. I'm assuming these high-freq= uency use case actors are online enough to take that last step when necessa= ry.

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




Also, there is no nee= d 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 l= ist 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 sequenc= e of transactions which ultimately proves the sender knew a BIP32 parent xp= riv (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 minim= izing blockspace congestion, and could be done as a soft fork.
=


-----

<= div>I'm glad to see thoughtful discussion on the subject of how t= o handle a quantum freeze. But it is important to put this in perspective i= n the context of this thread: right now the number one most important thing= - which we NEED to do if Bitcoin is to survive appearance of a CRQC - is t= o provide a standardized wallet address format which includes a secure fall= back way to authenticate UTXOs if ECC is unsafe to use. We can debate about= freezing or rescuing coins, or the philosophy of ownership, but these ques= tions will not be decidable for years.







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 disa= bling soft fork correctly and will lead to FUD, avoidable debate, and confu= sion. 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 some compelling arguments as = to why we should give the community a new address format which is totally d= ecoupled from any PQ-vulnerable cryptography. If the increased fees of P2MR= are an issue for high-frequency hot wallets, P2TR is still viable, at leas= t until Q-day. As stated Ethan's proposal is more motivated by long ter= m cold storage use cases. I consider a small increase in witness size to be= an acceptable tradeoff for (speculative) quantum security, and the costs o= f clinging to those savings in the near-term to be unacceptable. Key-path s= pending may be reinvented in the future using other novel cryptosystems, wi= th another new address format that depends on new cryptographic assumptions= .

-----

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

conduition
On Tuesday, February 17th, 2026 at 4:22 AM, 'conduition' vi= a Bitcoin Development Mailing List <bitcoindev@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 i= tself. On one hand the author says phase zero doesn't commit to final C= TV 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&= #39;m misunderstanding, this technique seems to require a priori knowledge = of template hashes T and E when creating the funding address and UTXO in ph= ase 0, so this would not be viable as a PQ fallback spending path. Happy to= be proven wrong.

regards,
conduition



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


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-quantum-resistance-script-only-using-op-ctv= -op-txhash-and-no-new-signatures/2168
Once you post = your commit-txn, but before it confirms, other parties can post competing c= ommit-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 yo= ur transaction.

agreed. they have to spen= d resources to attack your private key and the only thing they can do is &q= uot;grief" using a timing attack with the results, rather than steal o= utright. a massiv= e incentive difference.
They can block you again. Each time= they burn some of you coins in fees. Miners get the fees, so they might be= incentivized to do this. Thus, we must trust miners not to do this. Lifebo= at doesn't have this issue since it uses out-of-band commitments, but o= ut-of-band commitments have their own issues.
<= div>
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 min= ers. sounds like science-fiction levels of compute.

= plus.... TX_HASH is simple and generally useful and there is no guarantee t= hat 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 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 &= quot;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/CAJowKgL-hAxkb2uVTdHE%3Duo6%2BkRq1TEhabF_LNawE9K3j8_ivQ%= 40mail.gmail.com.
--0000000000009c927d064b45dec5--