From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 03 Jul 2026 14:46:49 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wflii-000236-FW for bitcoindev@gnusha.org; Fri, 03 Jul 2026 14:46:49 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-4489d5b6876sf967076fac.2 for ; Fri, 03 Jul 2026 14:46:47 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1783115202; cv=pass; d=google.com; s=arc-20260327; b=EdWXjBd3dlHE2KA85jiyI5UslAuQIcyLdqcJbZ/GiHpDsCnBBL/4/m7lmZ6W3vN7u+ kIi9b5DG7soEIXzEwFBtHN2aYITmQWr1tydxwrAYxDD3LHQXvvS6Px0rD5/hEQV9FWXA F5BrjbK2B4yQ3gfKoniL5kGFPxCOo19HCd/e7Pcp6nnxhslCJp0jPP6FhKJglr3JULzY cvNEWKSe/Ymr/9kmoMfs5Sg2BYqhah5fsyUfArJyZPYWHCT556jnBAkyK/Vj1RBn6BLE +w43zcWZtwwrcXWewzmcZHx3spireiNwcvjJOtKzq48jr9RCr9E/3m4fAIRu4+OsC6MF CN3Q== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:sender:dkim-signature; bh=EBgau+jDwpypo3XCbR6JIWiGAaqFj8raci87v99kxyU=; fh=Dq9LxBaHvBFWPpHwZwjUFrtilh8/foElAbzw9GIB/GU=; b=N2O2i1U/6H2owIJPHImkvh7oxitCzbmLAJoGgpg+RXlUdaNoMQ+jpVIHwoemS5NQYf h2cwcCvOkILbj7nLpZpLvWFnZO9SYnVjZ8tpk2b3WrW5wEHjWrsNibCtHQpIpcDxNjP4 GGs6gQRqmPOSByPEAjxDvlaKRA4WaUlol9HtG8l5UEjftKNnzhyR9RDbxlmD/S4FzwsY 4OR8u7NGhdn+TLzuXFLPct/3CAxLJVwmH6MlGbjV98TJxnQ0sBwCxe9ZEm2QxXHI7zDJ Dq2ZPgkGyxs/VSzzlzkxk+lb13UgQkk45FUDya9EBSavBdXr7q0ubg4qQi82gQWocxCq D0+Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=vvNMJ58N; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.26 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=1783115202; x=1783720002; 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:content-transfer-encoding:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:sender:from:to:cc:subject:date:message-id:reply-to; bh=EBgau+jDwpypo3XCbR6JIWiGAaqFj8raci87v99kxyU=; b=jiYKu1u6vAOAd/KIh4cVXrMG0ktjHBuz+29zK6wWwmBP4whCUJaXXZFFpdbKQ8bBly XRSPglQuJrb7kHP/APOmOY2SUGzeMStdkwpUoGedMJei/I/TKLHvGxQUeUUDLivLTMXb hAvEzDJggGJFkGGtYO/+L6VBcUOwnuy8bv2BDb094a64AUdtU9oocNhzclOHJ9qrAQ1F LyrACEmxRr0NWxZ8rZPjJICopUxZqRzmae6TszkNqHrgLooWK52gZ6vHybEhH9xg9rMF heG7SAAkeB+iCGLBP0HYlugZsMbJOaq/iqO371fjk/RuAv5xd6XU7H37RqxTwx3QmJRg dBfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783115202; x=1783720002; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=EBgau+jDwpypo3XCbR6JIWiGAaqFj8raci87v99kxyU=; b=VHOAe7f2Uz0wanznzAMhXUGmo7ggVG7AfE8f9HefyVb/vsj5Qzf2W0dqWT73ksntB0 hTOmIplKwBIdhHM1YbOPrdwnZlAqqdE602VeOyupOpbASBN7+CzvCHLzhXDwl42luoEP wR1MP+hBkPcP34y9s4PfsBn8kLPO2VQYNuiXbnpan2ehN8Owa3Rss5THLfaVLzwrVVZ4 UdqxBAWeXfyQUGmf5CXU7jdzJQCGEA2pUnwM0rTIeEpe6kwv51ox9SKCVK08RDK3Vi6Q LXlJBIBfLXGR5KWKLVOoOb29OwEb6FoKhx/XxEgoxoTMtEvtJRWk9kNgHtm2W2q1/IIw QLjA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ9K324AYUFSnfmVho8SzrUWidPB2OcefZ0VKsF2TJ9B/f1OrVxQ4CjtcEeMalBOgScNWbIgN4/cdJZs@gnusha.org X-Gm-Message-State: AOJu0YycdlSKfnHy2quaxA2wHNF8AIiaj2ALYEwGKuGcQUj1YhZjujNG P6TPIrTEMrO6fUGnQAvaHA9mdsFq8IeAbFd8iuniFGIdAnWfwUWRL/ou X-Received: by 2002:a05:6870:e40a:b0:448:448e:7a6 with SMTP id 586e51a60fabf-44d184422c4mr652271fac.29.1783115201768; Fri, 03 Jul 2026 14:46:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUcC0XZemEp2GBgUpDvZmEHlVMJkPYWjiYY81tP0uDuo8g==" Received: by 2002:a05:6871:c78c:20b0:447:88d1:85e7 with SMTP id 586e51a60fabf-44c3c583ed2ls1679153fac.2.-pod-prod-05-us; Fri, 03 Jul 2026 14:46:36 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/K+1WNf7Yy1sz5vCYWuV0xgUROp83heqHOJOJ38wW9s1zVtjfpeGhCE0gUjS1aV8QL9ikWd9jhuA9O@googlegroups.com X-Received: by 2002:a05:6808:120d:b0:492:f15e:3626 with SMTP id 5614622812f47-499bc40f22bmr541507b6e.40.1783115196160; Fri, 03 Jul 2026 14:46:36 -0700 (PDT) Received: by 2002:a05:600c:2d89:b0:493:bc77:9a11 with SMTP id 5b1f17b1804b1-493bc77a1b7ms5e9; Fri, 3 Jul 2026 14:23:54 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8zumDS8DpkGKd7q0iBM/YuY06wpS7kGbHLZpNY7LNn5kcRYRSyfeRy5lGpGd2aSmgu0G7TkcwjZaRO@googlegroups.com X-Received: by 2002:a05:600c:154b:b0:493:bfbf:1da4 with SMTP id 5b1f17b1804b1-493d11f0daamr6628925e9.22.1783113832446; Fri, 03 Jul 2026 14:23:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783113832; cv=none; d=google.com; s=arc-20260327; b=ch5fmnhUzrqvpEkjZcRqkY3p0LanT7Uy5W7jN+buGLWFXKMIJP7RWdW2KMfNSt23Jj D3rlkZpXkq7B0qs+qiuFUrDPixSYMzFVaotLgm5f7SD09BrQqNnq91yJDuKtkBQe22Od zd9EjJRtvtnoYwt12eJhgH5Y9Bde53UsPdcXxAPXQpvqIw3YJXzc4wd/ukzwJ3WMakpF 0psqOemn0UbNguJdVBjCxerVH7TtVNC3l2FpLh7g3UhgijL2YsFzeO0d/oRYFjZ0ktgt HZQ2jsVZMQK0oIkEPAQlYw36yUgIui7t8yVwbEBluH7KDXweniDqW0UOQHwhIE3+qbKg bhrw== 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:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=FxHaPNMfZaUwf57qAz9G4RcLZPFqvxsLi2vk3f0PXmU=; fh=t6RoFpU5qWR8JrV3dkWkoGwt3dL5fndvQ5k6y2MpZ/Q=; b=fVYTWuIlfo31vAI+KvY5JiyY+ZdWDMRLFOthFvEJ+0WAApyrLMPkwwjL3oJ97j+01d MOjwEMq6p6sV85YVhjSYshWzdlb2T9UAFy9htqpk7PiYJ2kxwKm2kfdP2nbOh1ZHfdZU ELEfH2shpMZJme/woxcnNO1OIZoGWMcqz95AGSpJTHks6RsGa0l5mlX6IGhou5PBevVN Xx4DWjsEjNPP+jLPH/720YtyetrGnhROqemPPIln/5KGQYkKscAf3IVleCdFN8uDV8Of 0aSyv8a33di225A3B/rNlR7qc+ZHKoizpJUxdBA9NzvFLDmUwHJhpFEANbs7TuTiiAal MK1Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=vvNMJ58N; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.26 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-10626.protonmail.ch (mail-10626.protonmail.ch. [79.135.106.26]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-47aa4024e5fsi13102f8f.7.2026.07.03.14.23.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jul 2026 14:23:52 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.26 as permitted sender) client-ip=79.135.106.26; Date: Fri, 03 Jul 2026 21:23:44 +0000 To: conduition From: Pieter Wuille Cc: Nagaev Boris , Bitcoin Development Mailing List Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Message-ID: In-Reply-To: References: Feedback-ID: 19463299:user:proton X-Pm-Message-ID: 482a4c1d0dcfd078f2c45ccda87341b8d7e59d7f MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=vvNMJ58N; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.26 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 list, Some responses inline below. On Friday, June 26th, 2026 at 2:20 PM, conduition wr= ote: > Mining an on-chain spend isn't the only option. The signature by (or disc= rete log of) the NUMS point is itself a sufficient and succinct proof that = EC spending ought to be disabled. We don't need a trustless "honeypot"/"rew= ard"/"bounty" for the CRQC, since we're already assuming the CRQC is cooper= ative. We don't need the "tripwire proof" to be included on-chain except fo= r posterity (i.e. nodes bootstrapping after Q-day, to know when to enact th= e new consensus rules retroactively). All a validator node today needs is t= o see the signature/discrete log of the NUMS point, anywhere, at any time, = to know that EC spending ought to be disabled immediately. > > It could be in an OP_RETURN, it could be a new field in a block, it could= be a simple P2P message or just seeing a TX containing the tripwire proof = appear in the mempool. There are multiple variations of what the tripwire proof could look like, a= nd I don't think the details matter as much. However, it must be part of th= e chain or it's not available to consensus rules. Just seeing a ECDLP break= age proof is not enough, because enforcing nodes need to be in agreement ab= out which blocks it applies to. And without being in the chain, there is no= way to guarantee all nodes see the proof at the same time w.r.t. blocks, a= nd discrepancies will leak to forks. The options I know of: * Using a spend of a known-to-be-NUMS transaction output (as my original ma= il proposed). I like this because it needs no infrastructure, and has no Do= S concerns as it's just a normal transaction. * Just publishing the DLP in a transaction (e.g. OP_RETURN with a specific = marker). This is smaller than a full transaction input + signature. * Similarly, but publishing in the coinbase, and requiring relay using a se= parate message. Less places a node needs to check, but I'm concerned about = the difficulty of testing infrastructure that relay of such a message works= . * Either of the two above options, but with AJ's (sig + msg + tweak) proof = form, which could be used to prove P2TR key-path spends with NUMS internal = key by unknowing malicious CRQCs. It's neat, but I'm not sure catering to n= on-cooperative CRQCs is all that relevant, because (a) if thefts are happen= ing, I think it's all too late anyway and (b) Malicious CRQCs aren't likely= to go after P2TR outputs first, probably, including for this reason. Maybe= it discourages them from stealing P2TR though, which may be a reason to co= nsider it... > Maybe requiring the tripwire proof to be mined is simple to implement for= validators, but relying on that alone runs the risk of miners censoring or= purposefully delaying the inclusion of the tripwire proof in a block. So i= t might be worth the extra complexity engineering of a more highly reactive= solution. That is a fair concern, but it's inevitable. Miners are by definition the d= ecider of the ordering of events as far as the consensus rules are concerne= d. This includes when the trigger happens. > > Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigge= r the disabling, allowing a faster reaction time to urgent CRQC threats. >=20 > I'll echo the others' concerns here about early activation, and add that = miners may actually be incentivized to trigger this activation early if giv= en the chance, since doing so will massively pump their fee revenue (though= perhaps at a cost to the price of Bitcoin itself). This could be more of a= concern as the subsidy drops lower and miners with sunk cost seek to recou= p their up-front hardware investment. That's a fair concern. A related one is that if the activation of the trigg= er is at a time with a juicy mempool full of ECC spends, it may encourage m= iners to not include the trigger, or if one does, for others to reorg it. I= think this can partially mitigated by having a delay of something in the o= rder of days between activation and actual enforcement (for both tripwire a= nd miner lockdown). > The more important question is, how do you propose to technically achieve= this? How does "majority hashpower" enact the disabling? My fear is that t= he reaction time will actually be very slow, because for us to measure "maj= ority hashpower" we typically measure this over an epoch of many blocks. Ot= herwise a random minority miner could luck their way into a few blocks that= signal for EC disabling, and so trigger the fork early. BIP9, with modified parameters, probably? It'd be conditional on the consen= sus change that introduces the P2XX-ML output type, which would be the real= softfork activation. The lockdown just reuses the same signalling infrastr= ucture, but isn't a consensus change. I haven't really thought about what t= he parameters need to look like. > The activation window would need to be spread out, and the further it is = spread out the less time miners have to react, if they even react at all. I'm not sure what you mean here. > This will confiscate coins held in hybrid scripts and in multisigs whose = parties use different sig-schemes, e.g. CHECKSIG CH= ECKSIG. >=20 > I would suggest to enforce the disabling by running spend validation as n= ormal, but failing at the end if EC-checksig operations have occurred witho= ut any PQ-checksig ops. This also implicitly disables P2TR-style key-spendi= ng and Boris' EC recovery scheme in P2TRH and P2MR, because such spends wou= ldn't involve a PQ signature. I don't think self-crafted hybrid schemes should be something to cater to, = but that approach works, indeed. PQC scripts could also be just a separate = script leaf version, which has no ECC opcodes from the start. > We thus concluded that deploying a hybrid scheme doesn't seem to offer mu= ch unique value, and comes at the expense of great risk and effort in addin= g a new checksig algorithm, which very few people will use anyway since the= y have much cheaper options (separate leaf scripts). I agree that SHRINCS doesn't need hybridization. On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns = wrote: > A slight variant of this approach would be to have a 128 byte value "aRsm= ", such that P =3D N+a*G, N is the BIP-341 NUMS point, and Rs is a BIP340 s= ignature of m by P. That would allow the victim of post-quantum theft via a= key-path spend of a BIP341 NUMS IPK to trigger the tripwire, in addition t= o someone who has direct access to a CRQC. Indeed, I had considered something similar, but see above for why I'm not c= onvinced supporting non-cooperative CRQCs is that useful. Also, in my view the tripwire isn't really a security feature on itself (it= 's not expected to trigger...), but more something that sets expectations a= round the output type for prospective users. In that sense, the question is really whether supporting non-cooperative CR= QCs helps set that expectation more than only cooperative ones, which are d= efinitely easier to support. > I think it could make sense to have the tripwire be included in the block= via the coinbase witness commitment output, rather than having it be locke= d to a transaction, so you only having to check the coinbase for the magic = rather than every transaction. That would require a separate P2P message to= relay the necessary ECDL-break proof to miners, and would probably need st= ratumv2 or a getblocktemplate update in order for the node to be able to te= ll pools to actually include that info in the coinbase. I worry this is untestable, really. You'd need things like fake-tripwires t= o be supported through the same message which don't require an ECDLP break,= and still propagate. And then that needs DoS protection measures, and ... On Sunday, June 28th, 2026 at 10:31 PM, Antoine Riard wrote: > [0] A cryptographically-leaning mind can note the first difficulty here. = Quid if it's not a "real" nothing-under-my-sleeve point... Show original me= ssage Due to EC's random self-reducibility, if an attacker has a non-negligible c= hange of finding the DLP of a randomly chosen point, they can do that for a= ny point. It of course needs to be a random point, but hash-to-curve achiev= e that. The BIP341 NUMS point (which I suggest using in this context) is the point = whose X coordinate is the SHA256 hash of the generator point G. This guaran= tees that the NUMS point cannot predate G (if it did, it would be possible = in theory that secp256k1's designers actually chose G in function of what w= e call that NUMS point, giving it a DLP known to them). > but frankly I don't see how you can prevent massive "unfreeze" at a latte= r chain "time" of the activation of your tripwire idea, if you can assume t= hat a (even transient) majority of miners might act in coordination with a = cartel of CQRCs. Unfreezing requires a hardfork, and won't be accepted by any existing node = that implemented the tripwire logic. After the EC opcodes within the releva= nt output type are disabled, those spend paths are gone from the perspectiv= e of existing nodes. It's of course always possible to introduce a new output type with ECC opco= des, or new ECC opcodes within existing output types (e.g. using OP_SUCCESS= x). This is always an option the ecosystem has (not miners!), but it won't = affect coins using the older output type/opcodes, which are the ones that m= atter here. --=20 Pieter --=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/= G6JS-1KFsfB7MzyRZH42MhcTp4rb_7M9Xg-1xznpwSg9MUjuI9B4ZSfVZ68S-FTaMjGBQhIpPb2= E9U346X1xN1jzWoQeL5X_0Ju_j81MSAg%3D%40wuille.net.