From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 25 Jun 2026 11:31:17 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wcor6-0006Uu-NQ for bitcoindev@gnusha.org; Thu, 25 Jun 2026 11:31:17 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6a0eb9d885bsf169403eaf.2 for ; Thu, 25 Jun 2026 11:31:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1782412270; cv=pass; d=google.com; s=arc-20260327; b=sMAHw1NiQA6b4vlhTxgOsQgSW47vkFvBYOxRZk2GVje/t1cAM0KIsaxmCHWd7nmSJk DnPPKd9O344Nfr/sOwseqPnyiF9QBNHkascNwq8yeWmsrkA6EfQmKFya0zfxoGgTVVTd FKPDkK0fj4zBXRIWpo9s0VtVZXYtPgxao5ryeSP3UgnwFFiTd4QegQPnJkCyvrT3R5Na LBVXSpPv87afRzjuOeoZVttYcVdiiCe1EVPZtxAk9awol0BNIkFJzLyBDKl8vj60zkae 2S07oTr40K71T8ljMo5E8ahrEwL2hY8XJqsvQXRf9k9R6cbHIuxz6oJKYRM99/HNunRh in5g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:mime-version:feedback-id:message-id :subject:from:to:date:sender:dkim-signature; bh=ZhHyZYyAd0oqULlR2zdPrX8In9YsGY3Db//kkPQn7qU=; fh=EzKQdFrTpMYMfNcJTzPzuVC1KkjBGIG4jVcxnlP4LoM=; b=EHfaDmN3bT6b9QjHgAIBlD+uDVAdQHEz1TB4LrTIkVKlMddENHzgMfKkvPMdGsqkRA 2k1iVk71PmCvCWDkBUWuZstHQsAqbe1I4U7I7HJV6XL89uJ6/HrNsbrNtn4xG9KqVReC UyqqfYsE30LxhYJs0xMkuzXI+ufbwJrcd3HpUJhVIpEq0jaoU28kTNxbvJwRG/MTbj2w acogTXJzTUl+iTn3WYs1Vzf2iWbaaQyAPqEg+Bzs2wYiBZu7hFRcGbzeDZEgGdSf3k9A jsOju+xNudG3A4uP/Cu5FC549WBGATTrMbmmldqehGua9saB8inFDblv8HBvX5OZg5gV WLPg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=HeoUn31M; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.117 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1782412270; x=1783017070; 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:mime-version:feedback-id:message-id:subject:from :to:date:sender:from:to:cc:subject:date:message-id:reply-to; bh=ZhHyZYyAd0oqULlR2zdPrX8In9YsGY3Db//kkPQn7qU=; b=WcLH80VQ3QuwV+q46Z28556dKasuilM0Hnn6WrcOwfZNSTX4DikLLcXbK0nzU7U1pw YOdb6tDkkkIUyA6X/kbcGg58OtQGP0XMr9hv47mhIt+ky0WWTfRum5C9hNkHqGCgIPmQ oSC6aZNK9PZgGDHZScJYljw+Qn+oOYXVaCyLDDhXN4e/fsMpeirhNYqWeQdTZtyE/W6c P4JEdlO1EqEs+JwlsNJHv4xfjz/pjgAEWkatmug0ZJWjFZ2hcoDRa5QZUO3JQ9KCQmxK gknGbs5MdCwXfgY8C7C3p1WiSei/Z4s/DMj1ezw/u6EmTK2sjeY9n31G+IU9u0at3bM5 TD9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782412270; x=1783017070; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:message-id:subject:from :to:date:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=ZhHyZYyAd0oqULlR2zdPrX8In9YsGY3Db//kkPQn7qU=; b=UVAtnvP250dbShlfa99OzO1Fir+TLU0bjJDrtYCWcDSk88oaylAWQZpUPJmdQtsCLJ KFSibr1x6pRhglV7lTJtXfNjPJ//uXDNJzj7+B0OdDKFwt9K2PHQbdqDkVvSyfe7RR+8 M+QXkIVR7W1a7S+m65UqbItRDIQQtUgDIV0BCn/x0i7xAw95dZ0blN/32PG0ewwDzQJY EAn7Nmn+iWLSsJ171m5UyugwWIQPy0jffwtTSA4kkFU6I8hz8z/lhlIGufb4s1R77VQh TMwIbGdbxBgKY5deas+lCMMZv0zMdFqzAMR4TplJQ2qybZtRSkPLXP9ckmcomAxYZXvZ jjSQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ8GgzQaYTCmZOoG2hXTZGEXakKhlVzq57rp5LPZ2hRECNPkrDRIIuHd/h1EvYZymGH0sOPN3V5G26SD@gnusha.org X-Gm-Message-State: AOJu0YzZ+t98xwD8S8v11p5CyGGnw7nHm0oH4a3sjiPpLzxj4VKdSHDC 3FYpB/uiBhHmuqPg5FNSBtcGY76cB3a4eqnS+QH0XsC1NRtJZYY8YIHq X-Received: by 2002:a05:6820:212:b0:69e:9a18:14ec with SMTP id 006d021491bc7-6a135201bb7mr2758742eaf.33.1782412270523; Thu, 25 Jun 2026 11:31:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdTJ125lqzKZdN6GHaopP7NII0wGANBNrKPlUDyERBZQQ==" Received: by 2002:a05:6871:78c:b0:41c:64c3:46be with SMTP id 586e51a60fabf-446dfb16a9cls5720718fac.1.-pod-prod-07-us; Thu, 25 Jun 2026 11:31:04 -0700 (PDT) X-Received: by 2002:a05:6808:f14:b0:48a:67e8:69c4 with SMTP id 5614622812f47-49217720f72mr3491745b6e.22.1782412264157; Thu, 25 Jun 2026 11:31:04 -0700 (PDT) Received: by 2002:a05:6808:e315:20b0:48b:fa0b:2a12 with SMTP id 5614622812f47-4904a175c59msb6e; Thu, 25 Jun 2026 10:42:47 -0700 (PDT) X-Received: by 2002:a05:6830:83a2:b0:7e7:57d8:a6a2 with SMTP id 46e09a7af769-7e99c3ada45mr3455699a34.17.1782409365775; Thu, 25 Jun 2026 10:42:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782409365; cv=none; d=google.com; s=arc-20260327; b=k9U9/kY8Qf/fx0d1y3hPht/atmmK/FZiXCbeTrYkwEofoNcgVunVDaNYyhhbBOoBj3 cE4SQNku3H7jZlE9wwvqJ2DxuDKciTdIf4yPLVc7ikQRQq3V25dGUY/hLLjd+tPjU2Ef L0eApP9ka14gHNlXwE8TwBK/2ZPWDd2zw6dXfgtiL14Tu4QN8j4B1+saePw1S6/PZlbK KJRhbCC05aCkKlkFWCu2SOAkPWVk++HDyT9dvSYlvpfcXvH0QDkN7U0DtALXC6qfGA1t ZVY4tnYtbSpt3NIOJ+w7FfUsOauTB2Laf8dW4E7GGbN2WDZCEZD3JZHUl+EiWVnEFpfB B3VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:mime-version:feedback-id:message-id :subject:from:to:date:dkim-signature; bh=TQ48qPwLkUYJwqPsI56varVmITwcRlyKCt/UYnpaoYk=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=JGy4cksfEmbU9MLD16V7o0VHBU8gkowiQYZLpcwPt2VOjsUe9umNfJl1HE+0Fyze3J gUg5CoJMKEYVG59xr4DumxrRAhL4iEdmB0Orj2fxmgBs3UYcun/4ocFSoqx9sS2DRMSz HKqM4sy9kwzo02qvtQ6rRJobGd07PnoAyq+xTMBY89pvvXk71X8RVXmAqaNLVQHuRdQ8 jF/s0XzDLLoWVE3Ll8BWWkLpEl2qlgaays1Za6DkFcjDOwUrIdpC8LqoDpPzQNNm0dZ3 BbQuea913H6ER3COM+rd4jVRcVCQRvUcOkkRviUVCRvXTNiYAC0Ms1BCT9ApybA6Jjk4 fdPw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=HeoUn31M; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.117 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-244117.protonmail.ch (mail-244117.protonmail.ch. [109.224.244.117]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-7e944278b6fsi589051a34.6.2026.06.25.10.42.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2026 10:42:45 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.117 as permitted sender) client-ip=109.224.244.117; Date: Thu, 25 Jun 2026 17:42:35 +0000 To: Bitcoin Development Mailing List From: Pieter Wuille Subject: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Message-ID: Feedback-ID: 19463299:user:proton X-Pm-Message-ID: f516108abc53a4de9b629c1d712bbd7f458e67c8 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=HeoUn31M; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.117 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net 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: 2.3 (++) Hi all, In parallel to the threads[1][2][3] discussing the P2TRv2 and P2MR concepts, I'd like to talk about the possibility of codifying in the consensus rules the (expectation of) the disabling of EC opcodes/paths within the new output type. The motivation for this is that while P2TRv2 has a "soft" built-in expectation of a future softfork that will disable EC opcodes/paths (just within the new output type itself) at the right time, its consensus rules are identical to P2TR (with the exception of PQC opcodes, if those aren't also added to P2TR). Plans and intent of protocol designers are one thing, but the future ecosystem isn't beholden to those: the only certainty is the adopted consensus rules themselves. Without confidence that the intended disabling will happen, it becomes unclear what CRQC-resistance the P2TRv2 type offers. Meanwhile, P2MR as formulated doesn't need/have such an expectation, but would still benefit from it, as users are otherwise restricted to (IMO) extremely onerous restrictions on public key sharing. To some extent, this is an unsolvable problem: we cannot codify plans that depend on outside-world conditions like CRQCs existing. Still, approximations exist which can be added as automatic triggers for this EC disabling, along with the new output type itself: * Tripwire (P2XX-T): use the presence of a NUMS point spend as trigger (suggested by Tadge Dryja[4]). Specifically, as part of the softfork definition, a NUMS point is picked. Whenever a transaction is mined whose input contains a successful " OP_CHECKSIG", EC opcodes/paths are disabled within the new output type, as of the next block. Note that the tripwire isn't intended as a replacement for the expected future EC-disabling softfork; instead, it puts an upper bound on that disabling. * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger the disabling, allowing a faster reaction time to urgent CRQC threats. Practically, this can be achieved by bundling the expected EC-disabling softfork with the softfork that introduces the new output type, but giving the disabling one a separate, and very long or infinite, activation window. This means that in addition to expecting the future ecosystem to decide when Q-day is too close, the hashrate majority is allowed to make that call too. (suggested offline by Sjors Provoost) * Combination (P2XX-T-ML): trigger EC disabling either through Tripwire, or through Miner Lockdown. I believe P2TR-T and P2MR-T are unambiguous improvements over P2TRv2 and P2MR respectively. This is because: * With Tripwire, anyone with a CRQC can, without permission, disable the EC paths/opcodes in the new output type for everyone. Because of that possibility, disabling is something all users of the new output type need to be prepared for at all times, and thus the later EC-disabling softfork cannot be considered confiscatory. That could otherwise be a reason to oppose the future EC-disabling softfork. Consider P2TR and P2TRv2. If there are no differences in consensus rules between them, it is worth asking why the future ecosystem should be expected to disable EC paths & opcodes in one but not the other, just based on earlier-stated plans. With Tripwire, disabling EC in P2TR-T is categorically non-confiscatory, making doing it there an objective choice. * Relatedly, for the same reason it likely convinces users and wallet developers to test, more seriously, the usability of the expected PQC paths, as not doing so inevitably means risking burning those coins. This is especially important for P2MR, which has some incentives to use it beyond CRQC-protecting coins. * The only downside I see is some additional technical complexity. The ability to sign with a NUMS point is an unequivocal proof that the secp256k1 ECDLP assumption no longer holds, and is thus a clear upper bound on when EC ought not to be used anymore. Note that this differs from a canary (an idea which has also been discussed) that uses a weaker curve, as the goal of those is to be predictive. The point here is specifically to just be an upper bound. To me, this makes both P2MR-T and P2TR-T more "Later"-style (as I've defined it in [5] and follow-ups) than P2MR and P2TRv2 respectively, which I consider an improvement for both. There still is an expectation of a later softfork that disables the EC paths/opcodes within the PQC output type, and thus the tripwire isn't actually expected to ever trigger. Still, I believe that its presence changes the game theory and incentives around usage of the output type, and future consensus changes. Of course, it cannot help with deciding what the right time for the EC-disabling softfork is, but it can help make it happen. The same is true for the Miner Lockdown idea. I'm a bit more hesitant about that, as it may be empowering the (collective of) miners too much. They always have the ability to just disallow EC spends of course, but the Miner Lockdown idea makes network nodes start enforcing the same rule too, making it irreversible. On the other hand, it is still opt-in (users deciding to move coins to the new output type), and this becomes them choosing to give miners a Lockdown button, which can presumably be used on shorter notice than the ecosystem can agree on a consensus change (even if it's pre-planned). I'd prefer to keep the discussion here just about adding the Tripwire and/or Miner Lockdown ideas, rather than MR vs TR, as I think this is orthogonal to the distinction between those. Thoughts? -- Pieter [1]: https://groups.google.com/g/bitcoindev/c/Qy4gwAGTK2w/m/_CjQ8xvdAAAJ [2]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/T7UWqgnvAAAJ [3]: https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603 [4]: https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ [5]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/Gona1fr3AgAJ -- 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/yHRpA2LEJ2AugT4W2KiWO3ggSims4GuHBkr6rWtE-e1uVC2wh3ZqD4bUDyxXq1iEuPrezhZZeqDoG7uBLNvjbW0sk_UTorI1Pkz6LcKhXRA%3D%40wuille.net.