From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 18 Aug 2026 10:31:00 -0700 Received: from mail-ot1-f59.google.com ([209.85.210.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwNeO-0006zb-CI for bitcoindev@gnusha.org; Tue, 18 Aug 2026 10:31:00 -0700 Received: by mail-ot1-f59.google.com with SMTP id 46e09a7af769-7ebe970a21fsf87476a34.2 for ; Tue, 18 Aug 2026 10:31:00 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787074254; cv=pass; d=google.com; s=arc-20260327; b=Aen3aWyZhEogkYatU/TKSPREXX9ornkLarSgc7itWD2ka3lKTsBAX3rRXFuIe6CNij lISVbPudMziSpKZDmKweSSK+8P8J5tbD9OKegv9/DUPGLVWnsr03LX4QJQ8hXnON+7/W YbfPFqo7x0kYRNmmQwtyN1d2H+PJhaybY6BS3Zyy60TD9ZVoXQ1OmSpCivnWv8czogV7 WdH4sN2bj/3wADb88g2fi091i0pqIiJZKNY4dd+CyQCvL1QBo2j9OVUg426H/cF1ndxP dNfQ0tE7CTCydR4+UsiVDErvJhexLf3++ZIm0xyn2c/2ans8+yY9jKn9wcI3Ou+t6owq 7QGw== 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=OYinJA1Cx0H9lRVfREH6UhILbbqa00cFPHeGoxqSSQg=; fh=ECphyB5KCCi1d/wgmbljJjGLpEqUbnnCDk6D3ZoaMHc=; b=sN8+lYkaDyi7qnmwIgcLpVwTWbcRPTLWhMXh8J1P8ORV4NplWABqxXPND3bB4v029s QugzsOtVaiGLz7VHZCeBvj0I8DFTM9TPEyTtfI4as8SMEgtGJ2DVgY+Xii8xNs/Bmb67 n/2KSGXvLFCVyCqjDBxAy6x/fuabhvJd5H+T8NUZhR4lAy5baBUHfb7kOMqC9vPjN+Py i8gTkWnaBhj5RwFD4A2wyIW2P6v26EYwpdn9N369G679g476leOhWMmBu+6FLxZT4Wbp p3WWY7Rl9bCVBmXSvyEamPq8v75s/aFG8uloSCBqrbFiXHzzr58eYppjNdkOvYcUeTHj SBOA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=YacImEqs; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.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=1787074254; x=1787679054; 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:content-type :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 :content-type; bh=OYinJA1Cx0H9lRVfREH6UhILbbqa00cFPHeGoxqSSQg=; b=Xy1teFQ76qgSrzjgwW8aGJr7zWjQXmv74NwLyZntOAeyqFaZbkJKcN0XLt+L2cXWms phUHZEdUf4sgiiUHteK+q7iK9wzXlL0SUzGILmQB6BXWNZx4sdtCX/koSkt0R9rWF6eb 5Ae6rlvEC/yq0k4bv6m8UiiogWrkrtBaXbUm6NryZZe+i5T9oH0oqpV45w8fOFfCuij1 fTcq71GMrpUW7r3CtqOnQXsGVtKT0T3ywLb3JfhyWs92BoDoBTwPw+ct3bU4cLEI2k3V 8s8nqltiQXFh04q8GiT0WX/0/6qOcjXspa3Rnt/dCRcOZteIpLYCv7mPGykv0m508Z78 EKjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787074254; x=1787679054; 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:content-type :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:content-type; bh=OYinJA1Cx0H9lRVfREH6UhILbbqa00cFPHeGoxqSSQg=; b=Etx6IeK48vvJhLNhgtCw7RCxJPAiF5deGLsPE4pTxTavfERYpLOTRaBcMvdXlvs+Gc E3MtGiYQy2xqKhhEaVRFPOHZtRClPRuKgfkKbV1M42xDcgxYv8Z109sp062f9VEqmRzP pHott0QIjg0TV/rBGEKn+U/w9WGssneOgY0FKwXWIX4LyKU1sgSLcdKJlXbja5NTJpGD m90Cw8/VRpnvQiulHYEumBrYbi8LJFLSr8CchoSscKf4cvyIj7ou5tQsfn+EwElHxEsA pVqnqd602Q6Q4H9obwTUI59s+ufkqoogImL0oUT4PIASgYbO/bzdwYDkumxfUWPEqEgx RNNA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AHgh+RrRcgXc1dSRG++pwL8G+PJKYmV3pwxcRk7TAOk7hAZMdMV67ZmVzmV+gumWHmmL6pJw1RkJ232DB42P@gnusha.org X-Gm-Message-State: AOJu0YwbXLsD/pA9uyg89e8T3qqpN4nnu79ceDOI197RnI0qB9nislTv 6hvGpEJdnAdaJxzw6yNWbKFsxLN1JTB/6TCD2NSQ0WrTIheB1OoqO2tZ X-Received: by 2002:a05:6820:4ded:b0:6a1:4040:97cd with SMTP id 006d021491bc7-6b11dce831bmr8516189eaf.3.1787074253790; Tue, 18 Aug 2026 10:30:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLddQuTs5f4XKz/dG5n+v36Oj3ghJlNiqwnJbAlt2D8HY+g==" Received: by 2002:a05:6820:1f96:b0:6b1:2ad7:d8e4 with SMTP id 006d021491bc7-6b12ad7f242ls692327eaf.0.-pod-prod-01-us; Tue, 18 Aug 2026 10:30:48 -0700 (PDT) X-Received: by 2002:a05:6808:4f47:b0:496:11f1:f2ad with SMTP id 5614622812f47-4b29745293emr8964093b6e.6.1787074248795; Tue, 18 Aug 2026 10:30:48 -0700 (PDT) Received: by 2002:aa7:d056:0:b0:69c:20b8:fa6f with SMTP id 4fb4d7f45d1cf-6a3f938e80cmsa12; Tue, 18 Aug 2026 10:20:24 -0700 (PDT) X-Received: by 2002:a17:907:6d1e:b0:c20:f85f:e7c6 with SMTP id a640c23a62f3a-c218b0b63a1mr537374666b.8.1787073623294; Tue, 18 Aug 2026 10:20:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787073623; cv=none; d=google.com; s=arc-20260327; b=SvLlCx79THN2/Kjt8AgPVH3KtSy/0SoDJercdb3zTTA3Tel9jlv+BY0PCbiSu4PpgA LATofgczAVy3phGAWT4s5J/mtnYV0t7JxT8brlxyWkJJDiH5/9bDWm4wEa9FbY9Oip2K lK2w8lDRN2rnl+seGlV9NrnlUPVQXlwdonHgF5oIZdXK/cxvVzlE6E39z0gTXzN2YHRh QpRWbUunopKghcV9Qw5p5qbbfHgsP0f1gD/SW2fay148kJ+ytnzDFNC3h0ZmZVc2JqcM V1chJWtldQX3i7Irher+c3dkw6uQYMM4GdNhRsv6bRztDKNUz5fyyHHSaah03ZDdmYii 2u2w== 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=WOIFMV912TRLsEiCyZOH62ycZTS7YdbxO95HJxcpIR4=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=iqRJQRjb9fea2utrxBqX7NNn5PDuWSsNMY39VflSNB6qOY23xZ9wKdXI/feOZqxEs9 NmgAN/mlY3azDADbJ+XTlm4TaaHHxOQ0QY+K0g13TRLe0g8V3o2lqlDe9XBHNkmV1X/g 4nHwm+tGnk4rNnXY+80Czlj7thitvLU3KiiA2ExbvC8xZc6+Vi2XCoPogH5dM6HsWaCg jZxK5dWo+9gD35bHA1CWeLfQPN9WoUPP90eXLwHl/eYgcPke9nyRKfAYxaa18GkSjQLh PVxZaYw5bSPql0Twl8M9MJ5Rm/QvqyyqzSqqyO54DM7oM9WqPSGExP9yYc5LsucYIjWK 0vYw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail header.b=YacImEqs; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.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-106117.protonmail.ch (mail-106117.protonmail.ch. [79.135.106.117]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-c217fd91cb6si11837666b.1.2026.08.18.10.20.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 10:20:23 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.117 as permitted sender) client-ip=79.135.106.117; Date: Tue, 18 Aug 2026 17:20:17 +0000 To: waxwing/ AdamISZ From: Pieter Wuille Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Message-ID: In-Reply-To: References: <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com> Feedback-ID: 19463299:user:proton X-Pm-Message-ID: 6d0622ce72eb080dd8df6c38280fa5f4b02ab782 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=YacImEqs; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 79.135.106.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, I'm unconvinced the complexity of a 192-bit canary is worth it. Picking a c= urve and a NUMS point on it are not hard, but very little of libsecp256k1's= code can be reused (even field arithmetic is optimized specifically for th= e secp256k1 prime). A more generic implementation is possible of course, bu= t it's still a pretty big piece of engineering for what is IMO very little = gain. There is a pretty fundamental difference between a secp256k1 Tripwire and a= canary for weaker curves, in that the former isn't intended to be predicti= ve. Its purpose is setting a codified upper bound on when ECC (within PQC o= utput types) is expected to be disabled. While it's certainly possible it's= actually triggered by a cooperative CRQC, that's not how I expect ECC disa= bling to happen (instead I expect a community consensus-changing effort, ef= fected through Miner Lockdown or otherwise). The Tripwire just sets an unam= biguous expectation that disabling is intended by Q-day. I don't think the presence of a 192-bit canary changes this expectation muc= h. 192-bit ECDLP broken (or breakable) is certainly a legitimate reason for= panic, but nothing prevents that information from being used at the human = layer without it needing to have been part of consensus rules. Relatedly, something I don't know is how "similar" a canary needs to be to = the real secp256k1 ECDLP for people to bother building/programming/running = a QC for it. This is of course a question that exists for secp256k1 itself:= whether a *cooperative* entity with the capability of building a secp256k1= -ECDLP QRQC would bother doing so. But it's even more tenuous for weaker pr= oblems, if they're not so much weaker that they're trivial. This makes me w= onder about using a subgroup of a very related curve: for example y^2 =3D x= ^3 + 3 (mod 2^256-2^32-977) has a subgroup of order ~2^187.11, which would = use all the same finite field arithmetic and almost the same multiplication= logic (only doubling is affected). Keeping the field modulus the same does= mean the q-bit count is unaffected though, only the gate count decreases (= proportional to logarithm of group order). Like other weaker-curve construc= tions, I don't think this is worth it, but want to throw the idea out there= . I also don't think optimizing for multi-target ECDLP adds much. My understa= nding is that Shor's doesn't benefit from multiple targets? I'm not opposed= to giving freedom of finding (m,x) such that H(m) =3D x*G, but I don't see= why that would encourage a cooperative CRQC to work on breaking it. Regarding using the BIP-341 H itself as canary, I don't think that's a prob= lem if the ECDLP break proof is a Schnorr signature (as opposed to revealin= g the DLP itself). But it also makes sense to be as conservative as possibl= e here; it may make sense to make a selection of hash functions, feed them = all as much input as possible (the genesis block is a good idea, the existi= ng generator G, maybe a block hash from a time when the activation paramete= rs are decided, or even a block hash when the block goes live as suggested = by Tadge though that adds hash-to-curve logic to consensus too), and then X= OR (or hash) all hash results together. >From a simplicity standpoint, I think just having a "a UTXO with scriptPubK= ey X is spent" is ideal, because it reuses all existing block and transacti= on validation logic, and just adds a trivial trigger. It's not compatible w= ith any weaker curve construction of course, or with AJ's H-dependent DLP p= roof which could enlist non-cooperative CRQC, but I don't think that's wort= h complicating matters for. Cheers, --=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/= td8wPWxRVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCB= W66z4g-Vc2fsSoo-Qxfm8Lcnd384Uink%3D%40wuille.net.