From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 19 Feb 2026 07:12:09 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vt5hI-0000ab-8N for bitcoindev@gnusha.org; Thu, 19 Feb 2026 07:12:09 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-40aee511210sf10185430fac.2 for ; Thu, 19 Feb 2026 07:12:07 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1771513922; cv=pass; d=google.com; s=arc-20240605; b=VG1mR+pFniYcf3J6dXQhAUiyenugI/F0kLhNYj35Gto8eUBFtemV6xOKKGBLHKIxBa X47SEEGBDijVb07nQK9Rr0BnqKokVFsFAEHn0jWBKj99WEDduHWq0+Tsy/Vct7V2+Xqs vop7qxdEOy+tf04phrXfN6TWTDOtKNpoheL+ygnJS+nOz12gfVrU61SVXzI/J5irmKvI 1bNGKdS08rEqI7DhxgfowHQqmRLkXQXioqGBHDNTCxZ/MQt3IUvNai1mpPSuBouixAkv wz2Ej+BgobLF2uVFV1rh+C9gMlv4SumdSH05eLInGnzfOIKsXdsb9upFliFfJ/O74swC 6UTA== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=Ne5CcJ+dsCQhY35JBPksfXsyBDH1BPhmgHIdIc/eCL4=; fh=qM6ttetbwpKHlz1Vf3qDJpeT95Ss+V+7H0YgnLPn1es=; b=Q2RxeELfvhdWEUTOLslFzYEuN1npZzuFuKwGV2bCSEFZz+J/OJgrJ4AwUYodULJUEj Kw8SvSAy4HNcagb4vMJSCYZOOvP5+WZaSJ/8aFKpgG21EnSWVHOIvL5BiwBeFOTeQQoi Qvdzs+vJoZdoTn3Usgm4EdhlGtRryC/jYTDLv5Bb+eedsHnvf2V+FSgEntKojCQWYrDH 41rhASsYZVynx8Px2p2kKoW6dxYeebBtHASEFCRcQCJ8283akH8O+QHPYENNiTVGe8Ou G0sLfRI2+Y5Wj6hOxov/+FJlO2otKf104dE2X/pBvEUwFMp6KTJNYHOBF3vN2cJrBDDu ykFg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ceeEODVU; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771513922; x=1772118722; 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=Ne5CcJ+dsCQhY35JBPksfXsyBDH1BPhmgHIdIc/eCL4=; b=GjbrMD1ByLRyMqVuK2684vftyXBmn00PKECl1QCe++XaGavCG3vHa5Qd/k09aIa9Ld o0H2Zz01iI2QEm4Jo9XFD/FJKW0lZ316w3vgNCE+0lO+7NuAppEjvNvivoqj16eCP3Of WA8dR63epgpkjwUhVp8bXHJYvfhXrLF5Gna1GLHEHI5eTPOSuECsj2YmBDosgVQBK0F2 AuoHsQFLmYkUgK6RHIyeauWvAO69mLttIv4tT+FNbccw8nRwkVUdvCfO+g5DtLy/aqDo V7FVEwv46fLBsQTAByqFCcGb5gEIPIAQfvy++GQVJugQNE7RNkyGxvGTpTqiVnE2petz LGEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771513922; x=1772118722; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ne5CcJ+dsCQhY35JBPksfXsyBDH1BPhmgHIdIc/eCL4=; b=RYk90VQ7oV727z8B+GPhxU6rEO2MDBIRz0HNG6j2RBFGl3Cxg8LU8ZaFobsbLH5ITu 3MxzDJVi6QHsQOC91kqoyMIH+jYsZC03/2nHqjfgZ4jCH9pi9SSsLn8vCSze/w7weBLV N73ZKnrmmyNRr9SE72gdzSbvJZ/gkQYX+0Kt/GFJTfNSbdB7jPz6WwBC0t7RjKyos5Rk VKIfH8jfDxhR9CV6BX4aCoOCvyKlAWHYDVFBAqG8/0MlmqGPmmRp3YOlaLUhc84cnHD0 jC+H+iOpTKKrPq9506aVMnFNLw0rYKY216r9l9YvGF9RXuwPd/Qudcb0Q/CPIX61FXDm SYWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771513922; x=1772118722; 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=Ne5CcJ+dsCQhY35JBPksfXsyBDH1BPhmgHIdIc/eCL4=; b=vBL/Je5jT6O+u5yIpq96sCf6d38WolQuk+UwYw81Xh+Xsevu0pxLM5o6LBEFD6xWjA y9jTZBrYbaPjZxws21qF04Guy6vorAbKnGwtCEgoGnce4OBNa8DsqYZozRajzDycuaRt rRzQrW1IKzHKX/zvdLd5HfQ1tCILpowsPJk0Qm02oyu96+M1QkIQbilJc4KXLMNQXD/V tLHQSFZuXdO3ZHDMqy6emvGj7rSwBAa+UUx6Hb09ay+IUzEnIcpzm7cF68n6NEYecqy/ da3uDeNF5jxYhebSGIIP5t2uqjof9aMWrjiGR/rYv5VDbQNa8nyRgM6IiLrGw8n9BbuD ugdg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUcZrvTAMx8tRXnqCTa60j/f4meEzAtvvnpdaF89WlHTkTiR+/5Wm2sY6PLYPdlMGwyKx9YTHg3ENSK@gnusha.org X-Gm-Message-State: AOJu0YyE5CF13gnSq1oK+uVlt/ytA8L3HBcdhp8+/YWWpi9MK5CqAisi /5Y55AFVnZ05KbycVhgDOJr8zctWMydgxdfAcMmfXopjqduzcpggjXvg X-Received: by 2002:a05:6870:d61f:b0:40b:da6:fd79 with SMTP id 586e51a60fabf-415291eed6dmr3061103fac.51.1771513921790; Thu, 19 Feb 2026 07:12:01 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HtaMjFwl70cd3rOWLNuFi4J2/MioMFGhIINzPOT3Zmyw==" Received: by 2002:a05:6871:c895:20b0:409:6297:eafe with SMTP id 586e51a60fabf-40eca6c6745ls3815104fac.1.-pod-prod-07-us; Thu, 19 Feb 2026 07:11:57 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUDxBK0I8TQkVnFGo+sL5/ulO9dHhEUSZk05sDC4oB3DLqlWOUE1TkxFCs7ij+4NRzuc/VCHKevSChO@googlegroups.com X-Received: by 2002:a05:6808:86d1:b0:463:ab56:9ed0 with SMTP id 5614622812f47-46410b8551cmr2155334b6e.2.1771513917466; Thu, 19 Feb 2026 07:11:57 -0800 (PST) Received: by 2002:ab3:6f15:0:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-2e5e540c876msc7a; Thu, 19 Feb 2026 06:36:06 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCX2E2HEHtjw0ZGCdivX1ej/Tlbw26QtPuTqds+jT866yGOdQdcvH18tZyAh0GUkMrsfehJ/D6EsFIfo@googlegroups.com X-Received: by 2002:a05:6512:b95:b0:59e:62d0:2ad3 with SMTP id 2adb3069b0e04-59f83bc4c12mr1764938e87.43.1771511764134; Thu, 19 Feb 2026 06:36:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771511764; cv=pass; d=google.com; s=arc-20240605; b=PWcf6mMuIgA/S1yE27WgX4/AGioLR8RkpJ6L5lQ2Oe+sT/FaG2j1Rn48Y+mIAIqZT0 wNzpznyvIPTM2wUWHVrFvT7J9nZd6SFoDonCTkhngZte6vLFy1DifgfWktz+mlE4ogHz scvFQ7wIdBMKSZqo0TUpxn4y2QXipi5gAkauCc3n8Z+PD8CNAuLZAhdYXJKNvpPV7NYu CPVOXO4Ctyt+K9StvEHRlT+hKm8q2/u05kxTMu+hB9Jg13oH9XJGmPPwYe4c9nWpVGn5 6HnRuB5soKufbPiabkhnLItILNVU8jKcEEqMlm8S+f+clJjh9CceWxIT2jYuCzsKDaMY iw8Q== 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=oRL4xMk0OJGF8kHC9QIWOhfICqIvkIC91OBw+2eBO3k=; fh=EzfHDoX7RW7+NjVpbgW+/7+CKEOA3k6entXT3TGtAtk=; b=ffiF8mdCdAzx9YBRMozUZAyEPQ4xlViU2sMngXuzTylXFFQMSl8kOeecxM9I9aExQi aSqf4AQzbT5usKpWtZaNLOQVf5wC3Gdp8dgVPVy7NHfwOqU7n303Jut/OEPTjUOxzC2J tOKxDm+3kZbFuadL7GbdxfxK2yp9o7a4v9eBFzE6l6aR4PsSajuGlXCka0p4C2EcBQq3 AkATgsL5qpEuM1UJVLabgUGt/PtAqyWnb6jTmHfW4mwrxjG/QFYTnWxWgeY5mNoC4vh/ IEINMTSejpQooE3pBE5THrcFNOYWj50Rmt6rIHw+BRCmgpJAPO0RmrH7kM8CLEkIPguI bxYA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ceeEODVU; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com. [2a00:1450:4864:20::534]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3870690bd09si4771011fa.7.2026.02.19.06.36.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Feb 2026 06:36:04 -0800 (PST) Received-SPF: pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) client-ip=2a00:1450:4864:20::534; Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-65808d08423so1436943a12.1 for ; Thu, 19 Feb 2026 06:36:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771511763; cv=none; d=google.com; s=arc-20240605; b=HkhSu5zBQZKrdtpwIoLlegnGLppGb5cdTq/lYr6Ga/g4IYmvwbxiUYzDbZbeAvP1sV VfSimslFDubYmE0X4mIJU/uD2TusWO6ewmwhfiD+IilEwEj2XovlWWIVYYCrqlZ9WXgB 07IK7736zKUrFJJ8YUX7U7pXyFB7p5p+9MVgNZ5efN/UJkpb9E+nB9HRbOisyQYf0D1r b7RxKfoCLBpAbV8LRe1pJzVASFQsSOj0gmsS4Iai3rGkXieAWf9gTStrHR/US2wmi2og +7LriHofOnoiLpweltdbUZGuMktMk+PPfZe34PFU6tTh5PPflQUeUXdKpzHK1QytUie+ E8pA== 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=oRL4xMk0OJGF8kHC9QIWOhfICqIvkIC91OBw+2eBO3k=; fh=EzfHDoX7RW7+NjVpbgW+/7+CKEOA3k6entXT3TGtAtk=; b=faOzjovDxw6JekJ3vjMFgFiQgetE1Cb7+F6/bis7/kFkPuXFstgI/4sHT4kiFpF7k6 9hqafXXVP+ImAqLl/c+egOWDA6aPBjnyIjYK80CAboO2fxQFM62HdANfO2rZ0bQSpe96 sEe6AGIhYGKZz/3Skfm4fQPJ8ALCEkNYdFLZ0i5dV79CrLpShi7Jp+NSegMX3ylTodCd D8YruPmZR76lqPkwj5o/0gCqa/EDIY8eEz6Rf03OneRUBlPmOlKJWK+dwgU2ARMwhe5x Imr/KCF/le/uxozaXoxzwlaGgk0m5aQr4YapsWw46GnPdHrSsRkucvIg4SPcHq/mG/Dz Sntg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCX/2/BabddWIeTMhGHbxcnCuplhJS75JxTCqAoG/wMbJ8+xqTb5ViIREYvA7g8pT5thkFrngZaLj6PB@googlegroups.com X-Gm-Gg: AZuq6aJjVCmlzjEaG1269VyAIaW6zPxlXokOkomyAPhRLzDnnX1bSJAgiYdbpVAi8tf 2fQ1Nu0ifo/d/0U/eNtBj1PjJ3RJ3UW95koxmWmDmXhJ3wn8q+TtctYhgm8MK0r2uvW7xcUrDwC P3cVvTzbJCgUWviQgnzKnTofeMwiRa1rTVWplokY56UefaJRrI9vW8YQUe9uZVZd9QjkgRke3h4 vx4DSk4jy6WZAJJPODbvKTNonKRCbkRBijXBpDOAJ06Cu08pYkIHwiGxlHApQ9Y/5yBABC2HNmj S8CiDz6aJ9c3nQzS X-Received: by 2002:a17:907:980a:b0:b88:6309:c300 with SMTP id a640c23a62f3a-b903dc90470mr308150866b.39.1771511762896; Thu, 19 Feb 2026 06:36:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Garlo Nicon Date: Thu, 19 Feb 2026 15:35:51 +0100 X-Gm-Features: AaiRm53B0XSc8IB7JY_JmdtNeFicxIMeS489tO8MMmuakE3fdV3_Mh2bS0atWBI 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: Erik Aronesty , Ethan Heilman , Jonas Nick , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="00000000000057cd78064b2e3901" X-Original-Sender: garlonicon@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ceeEODVU; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --00000000000057cd78064b2e3901 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Future PQ Bitcoin wallet devs will see secp256k1 as we today see broken primitives like md5 or DES. We still have OP_SHA1 in the Script, and even in the TapScript, even though there are known collisions for that. Also note, that MD5 is broken, only when it comes to collisions. MD5 preimages are still unknown, because mounting a preimage attack is much harder. So, if we talk about disabling obsolete cryptography, then when OP_SHA1 will be disabled? I guess it won't change in the nearest future, even though the first SHA-1 collision happened in February 2017, around 9 years ago. > Future devs shouldn't have to add legacy cruft EC libraries into their codebases when it's not even usable for cryptography anymore. Well, to fully break OP_CHECKSIG, you need to break both secp256k1 and SHA-256. Otherwise, by breaking only secp256k1 alone, you will still have 40-byte DER signatures, and not 9-byte minimal 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: aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801 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 'conduition' via Bitcoin Development Mailing List = < bitcoindev@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-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 > . > > > -- > 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/GhzGKZ5zphDf7mFpC_PMD0Bn7-KI= K14HXdCPLeB7HKvPBfDRVG8eUAlCKKLWcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xo= W4Js%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/= CAN7kyNizzKzDg4fVOGe976Xq%3DMLCpiAufZaJLkRV-AhhFW28_g%40mail.gmail.com. --00000000000057cd78064b2e3901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Future PQ Bitcoin wallet devs will see secp256k1 as w= e today see broken primitives like md5 or DES.

We still have OP_SHA1= in the Script, and even in the TapScript, even though there are known coll= isions for that. Also note, that MD5 is broken, only when it comes to colli= sions. MD5 preimages are still unknown, because mounting a preimage attack = is much harder.

So, if we talk about disabling obsolete cryptography= , then when OP_SHA1 will be disabled? I guess it won't change in the ne= arest future, even though the first SHA-1 collision happened in February 20= 17, around 9 years ago.

> Future devs shouldn't have to add l= egacy cruft EC libraries into their codebases when it's not even usable= for cryptography anymore.

Well, to fully break OP_CHECKSIG, you nee= d to break both secp256k1 and SHA-256. Otherwise, by breaking only secp256k= 1 alone, you will still have 40-byte DER signatures, and not 9-byte minimal= ones, where everything is fully broken. And it is possible to enforce a gi= ven Proof of Work, if you use OP_SIZE on DER signatures. Even if you use pr= ivate key, equal to one, then still: you won't sweep everything, for ex= ample from this transaction: aba3c2ae442aa20150996ee68f9aa4da83b57a43128910= 78be0c2e68c50b2801

Which means, that there are still use cases for O= P_CHECKSIG, even if you can break secp256k1, as long as you cannot break SH= A-256.

wt., 17 lut 2026 o 08:51=C2=A0'conduition= ' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> napisa=C5=82(a):
=
> I just don't see a r= eason 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 us= ing elliptic curve code for as long as P2TRv2 exists, because you will alwa= ys have to compute and verify the tweaked output pubkey. Future PQ Bitcoin = wallet devs will see secp256k1 as we today see broken primitives like md5 o= r DES. Future devs shouldn't have 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-disabl= e-soft-fork will be needed (which is debatable), then it still pays to remo= ve the inefficient and unnecessary cruft of EC crypto for the foreseeable p= ost-quantum future. You might think of it as decoupling UTXO ownership from= any specific public-key cryptosystem.

Furthermore, if EC/keypath spending is disabled, P2MR actually requires l= ess witness space per input than P2TRv2 because we dont need the now-useles= s 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 d= istant 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 depen= ds on weaker assumptions. P2TRv2 is more complex for wallets to implement t= han P2MR, unless you count code reuse from P2TRv1. P2TRv2 is (marginally) c= omputationally slower, and less block-space-efficient for script path spend= s. So who would choose P2TRv2 over P2MR?

The only redeeming factor of P2TRv2 is that it saves a few dozen witnes= s bytes per input when using schnorr EC key spending, compared to P2MR spen= ding. For low-frequency use cases like cold storage, that doesnt matter muc= h. At current rates thats like 10 sats per input. For high frequency use ca= ses where every vbyte counts like hot wallets, exchanges, mining payouts, e= tc, i have good news: P2TRv1 still exists and can be used just fine. You &q= uot;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, 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 = 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 wit= h only merkle trees forever. I'll elaborate more on this idea in a fort= hcoming article i have cooking on isogenies.


> ZK proof-of-seedphrase

If we were going to use a ZK proof to rescue quantum procrast= inators, 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 w= ayyy 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 previ= ously (sorry, i dont have the link in front of me right now). The idea is t= hat a sender can rescue frozen UTXOs using a commit/reveal sequence of tran= sactions which ultimately proves the sender knew a BIP32 parent xpriv (or p= ubkey 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 blo= ckspace congestion, and could be done as a soft fork.

=

-----

I'm glad to see thoughtful discussion on the subject of how to handle = a quantum freeze. But it is important to put this in perspective in the con= text 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 these questions wil= l 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 fea= tures: BIP360 P2MR addresses, and SLH-DSA opcodes. Those two changes are al= l we need in consensus to finally give hodlers an option to migrate.=


I've gone through and ca= talogued some of the feedback on Ethan's proposal. So far I've hear= d these material critiques:


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

As i men= tioned 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 a= dd 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 a= cceptable tradeoff.


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

As ethan pointed out, this would be bad for stand= ardization and interoperability, and also requires GSR to be deployed as a = pre-requisite. If GSR is activated and in-script signing schemes are standa= rdized 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, ra= ther than adding a whole new address format?

As ethan pointed out, this depends on timing a future disabling sof= t fork correctly and will lead to FUD, avoidable debate, and confusion. It = is also confiscatory, as it would freeze standardized keypath-only P2TR out= puts which lack a script path.


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

<= div>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 any PQ-vulnerable cryptography. If the increased fees of P2MR are an i= ssue 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 st= orage use cases. I consider a small increase in witness size to be an accep= table tradeoff for (speculative) quantum security, and the costs of clingin= g to those savings in the near-term to be unacceptable. Key-path spending m= ay be reinvented in the future using other novel cryptosystems, with anothe= r new address format that depends on new cryptographic assumptions.<= /div>

-----

= 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' 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/m= sgid/bitcoindev/GhzGKZ5zphDf7mFpC_PMD0Bn7-KIK14HXdCPLeB7HKvPBfDRVG8eUAlCKKL= Wcki6XDW0h0R1IQC5SS9B7jnMRS85GzOzcmCt9v5R3xoW4Js%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/CAN7kyNizzKzDg4fVOGe976Xq%3DMLCpiAufZaJLkRV-AhhFW28_g%40ma= il.gmail.com.
--00000000000057cd78064b2e3901--