From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 18 Aug 2026 07:41:58 -0700 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wwL0n-0004Sz-Ew for bitcoindev@gnusha.org; Tue, 18 Aug 2026 07:41:58 -0700 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-6b12ae7394csf580443eaf.1 for ; Tue, 18 Aug 2026 07:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1787064111; x=1787668911; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=8KgynXB2dcQOSoDklWBvdScbkYvgq91oqXLwzDggVCk=; b=Sewtcmf7mRyoaaUDoyEZq+0Zg7qp8JKpJbksmwPNLv2d6lmJgF8ViaGHyS6l5KvZKs yefd/gUEdivRHk2E6PNBT810tGv68WESE6AeeM82dnMq3YsMZEW++3AsCfxbtsn1wnXN fXp+SVQSZMVZ1DSmsWLWv8J+95wIFFZh5Dhxax9B7ERLb2UmVSihNd37mu/8BuJjSDSe ehYUhDiAiteoYwGz8QVMcd1w9GiRkWGkX4h/saC2eWsh58WQpu+dhZ14ZDki+u6l/A7y EbhQkEsrm1NmEgvfVetvpTKKGVuemg/fy7W5Hjqj+943QFI2Whndl6X/nxulqQ1n8Wo3 zi3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787064111; x=1787668911; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=8KgynXB2dcQOSoDklWBvdScbkYvgq91oqXLwzDggVCk=; b=YfdTRkZE9hEZGZSZbKgWnbO2pmXhmc9SQn50RM6ISpM9+DvsKtaw0dA/jGCh/YEXdy qhdJeRKvc/k+hf0N8iUHDgvtxrlt6vq1hUfFz5du4kaYLf4ypXnHZqABBj8xtAwXLQM4 HRiUAnBebTQuy9Wuu4qCmsXXuzY1lzzSIkx1MZ/a8P/yyUZ/ntfGW9sK4w5jXxxalECb bOgcVn+qqV1Kka9TPNDQ5hDE8wUP9h6WhIDqE9mZz1z02qN40eydX8EhXrMO+/Ou+nCD ovPgCGp+pxXG+34irY5gb1TADCHT1ZH6l1FXQV3QYobK3iS9Aim/fXLoQZV06ej0Z+6A QlyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787064111; x=1787668911; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=8KgynXB2dcQOSoDklWBvdScbkYvgq91oqXLwzDggVCk=; b=ch3EfKK+jK1E2xWklMaEzdQR9C8EMMahbHOe7evELk/bCFF/JIzD6GL2Vm7DfNfetW EvXE+SalqSM0qRhd0rEdhoAnX1BO9l4LH3qeUSIQUOjIW1OxU0Cdn/2mqDVZCrOHtxjX UJbIvKGxZo1Hpgct6UGb/3Eg9D2fYUsVCFbp0dcrwTgJPFtqzP0+E573YHw6VjpLgaXS zzh0X8tpT87DBnwL1j2WhKlhPT2DpQ8x0XolesSdRyShY1BaV/v70LxEYv3NwkqPZ2U1 A5x6tNJdNGwUd3M/SGdxy2EWiLO5kdxWAKdwk7d8B7W9mIwrZ2T4p5o68qCtTHHAY1dH Junw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AHgh+Rp+LYUdsdalsrjYydzORe0dgkJJGIDrkrTg8foJnNXflC6Ary5F2c2EkCshPItjq7DfhXEBQqQn3oQC@gnusha.org X-Gm-Message-State: AOJu0YzJ4Hpi7IgeqVqeOhEn07hY+zDSTrv3Y0hHah9Hud07CGY5Yb2+ fhJmZKSDTsBGDYQlyqt9IPoIhKAJvfuSpsp+467nvgNChoUH896qcdui X-Received: by 2002:a05:6820:619:b0:6b1:332a:9185 with SMTP id 006d021491bc7-6b1332aa765mr1931330eaf.28.1787064110843; Tue, 18 Aug 2026 07:41:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdf1E2t0//sdZh8LRwDQz4lSnSUOYf8vN3zQ1NW2Smrb5A==" Received: by 2002:a05:6820:220f:b0:6b0:5edf:6386 with SMTP id 006d021491bc7-6b0c48bb433ls6436323eaf.0.-pod-prod-02-us; Tue, 18 Aug 2026 07:41:43 -0700 (PDT) X-Received: by 2002:a05:6808:6804:b0:4b2:8dbe:b596 with SMTP id 5614622812f47-4b2974563a1mr8498394b6e.2.1787064103856; Tue, 18 Aug 2026 07:41:43 -0700 (PDT) Received: by 2002:a05:690c:a642:b0:80b:2194:fea2 with SMTP id 00721157ae682-82320fd1896ms7b3; Tue, 18 Aug 2026 07:36:49 -0700 (PDT) X-Received: by 2002:a05:690c:88c:b0:7db:ccda:a409 with SMTP id 00721157ae682-8412d51834dmr41663217b3.9.1787063809001; Tue, 18 Aug 2026 07:36:49 -0700 (PDT) Date: Tue, 18 Aug 2026 07:36:48 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com> References: <002f2395-7d5d-4cb6-852c-e991aa1f0eb3@app.fastmail.com> <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com> Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_321608_381307020.1787063808639" X-Original-Sender: ekaggata@gmail.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: 2.6 (++) ------=_Part_321608_381307020.1787063808639 Content-Type: multipart/alternative; boundary="----=_Part_321609_204838202.1787063808639" ------=_Part_321609_204838202.1787063808639 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (re-sending 2 messages after sending them to the wrong location!): Right, so: the QCAP thread was about a canary rather than a full tripwire,= =20 and doing DKG (optionally) plus DLEQAG, rather than NUMS. You're=20 saying/thinking (are you?): do NUMS on 192 bit, then, when proof is=20 published, activate the consensus change. But that would mean validating=20 the ZKP in consensus right? It'd presumably be simpler than literally=20 implementing the 192 bit curve in consensus (doesn't sound very simple!),= =20 just for this one action. And it's more realistic than the idea of having a= =20 trusted setup to create a small dlog in secp256k1 (because trusted setup in= =20 consensus is not going to fly in bitcoin). But it *would* mean having a ZKP= =20 verifier inside our consensus. Heck, if we can do that, we can do lots of= =20 other nicer things :)=20 So tell me if I'm wrong, but I don't think the fact that it doesn't have to= =20 tie to spending of a specific utxo is the thing: I think the thing about=20 'tripwire' is creating a consensus rule, which means validating nodes have= =20 to agree. I tended, after our earlier discussion on this, to come to the=20 conclusion that a 192 bit tripwire would be 'nice' but doesn't seem to be= =20 practical. Could have it as a canary still, ofc. But probably only 256 bit= =20 is going to work as a tripwire? 2nd message: Oh wait, it's much simpler (not perhaps in character, but concretely): we= =20 don't need to talk about some general ZKP system here, right. If we all=20 agree on a 192 bit curve, and a NUMS point on that curve, then in the=20 OP_RETURN (say), we just need to put the point's dlog and consensus nodes= =20 only have to do a single scalar multiplication on that curve to verify. That's so much simpler that I almost change my mind, i.e. that really is a= =20 simple extra consensus rule, but I wouldn't be surprised if the engineers= =20 still say, no, we should definitely not do that (dependencies?). After all= =20 there is something very ugly about one-off consensus rules like that that= =20 are completely unconnected with bitcoin's central design. Has there been=20 any such thing before? Maybe that one about the repeated block hash? (even= =20 if I'm right, a bug fix like that in the existing rule set, is very=20 different). Not commenting on the gate-scaling because I'm completely clueless about=20 how the scaling works / will work (and don't know if anyone knows).=20 Obviously it's *plausible* that the gap between these two cases will be=20 small. Cheers, waxwing/AdamISZ On Tuesday, August 18, 2026 at 3:17:32=E2=80=AFAM UTC-6 conduition wrote: I'm hesitant to say I support a 192-bit canary outright, but I like the=20 idea and I think more research is needed to confirm whether it would work,= =20 or if such a system would be over- or under-sensitive (i.e. triggered too= =20 late by the first powerful quantum computer, or triggered exceptionally=20 early by a classical attack). I'm especially interested in any attempts to= =20 estimate a rough time delta between the "secp192r is broken" and "secp256k1= =20 is broken" events. I suppose that's more a question for the QC experts (not= =20 me). I'll have a go anyway. Based on logical qubit count estimates in the google paper=20 (see=20 page 7), a QC needs at least 4.5 * n qubits to crack a curve of n bits=20 (with a practical Toffoli gate count). So secp192r1 might be broken by more= =20 than 192 * 4.5 =3D 900 logical qubits. Breaking secp256k1 requires at least= =20 1200. So how difficult would it be for a QC to scale from 900 to 1200 qubits? If= =20 we assume QC scaling will follow moore's law (if it ever scales at all),=20 then that's worrisome: less than half a doubling of margin. The first QC=20 that breaks secp192r1 might very well also be able to break secp256k1. Also: I read the QCAP thread=20 ,=20 and my initial impression is that using DLEQAG proofs to share the secret= =20 among a trusted group is overkill: If breaking a 192-bit curve such as=20 secp192r1 suffices to prove "QCs are coming" and so activate a soft fork,= =20 then why go through the effort to map that statement to secp256k1? We can= =20 just use a secp192r1 canary proof on its own as a self-contained=20 cryptographic statement published on-chain. Then the proof can use a NUMS= =20 point generated in some honest fashion, same as for secp256k1. Nodes could= =20 activate the canary as soon as they see the canary proof published anywhere= =20 on-chain (e.g. OP_RETURN). As discussed before in this thread, there's no= =20 need to tie the canary specifically to a Bitcoin UTXO being spent. regards, conduition =20 --=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/= f6565311-f62e-4210-8c15-93830c3f71cbn%40googlegroups.com. ------=_Part_321609_204838202.1787063808639 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (re-sending 2 messages after sending them to the wrong location!):
Right, so: the QCAP thread was about a canary rather than a full tripwir= e, and doing DKG (optionally) plus DLEQAG, rather than NUMS. You're saying/= thinking (are you?): do NUMS on 192 bit, then, when proof is published, act= ivate the consensus change. But that would mean validating the ZKP in conse= nsus right? It'd presumably be simpler than literally implementing the 192 = bit curve in consensus (doesn't sound very simple!), just for this one acti= on. And it's more realistic than the idea of having a trusted setup to crea= te a small dlog in secp256k1 (because trusted setup in consensus is not goi= ng to fly in bitcoin). But it *would* mean having a ZKP verifier inside our= consensus. Heck, if we can do that, we can do lots of other nicer things := )

So tell me if I'm wrong, but I don't think the fact that it d= oesn't have to tie to spending of a specific utxo is the thing: I think the= thing about 'tripwire' is creating a consensus rule, which means validatin= g nodes have to agree. I tended, after our earlier discussion on this, to c= ome to the conclusion that a 192 bit tripwire would be 'nice' but doesn't s= eem to be practical. Could have it as a canary still, ofc. But probably onl= y 256 bit is going to work as a tripwire?

2nd message:=

Oh wait, it's much simpler (not perhaps in char= acter, but concretely): we don't need to talk about some general ZKP system= here, right. If we all agree on a 192 bit curve, and a NUMS point on that = curve, then in the OP_RETURN (say), we just need to put the point's dlog an= d consensus nodes only have to do a single scalar multiplication on that cu= rve to verify.

That's so much simpler that I alm= ost change my mind, i.e. that really is a simple extra consensus rule, but = I wouldn't be surprised if the engineers still say, no, we should definitel= y not do that (dependencies?). After all there is something very ugly about= one-off consensus rules like that that are completely unconnected with bit= coin's central design. Has there been any such thing before? Maybe that one= about the repeated block hash? (even if I'm right, a bug fix like that in = the existing rule set, is very different).

Not c= ommenting on the gate-scaling because I'm completely clueless about how the= scaling works / will work (and don't know if anyone knows). Obviously it's= *plausible* that the gap between these two cases will be small.
=
Cheers, waxwing/AdamISZ

O= n Tuesday, August 18, 2026 at 3:17:32=E2=80=AFAM UTC-6 conduition wrote:
I'm hesitant to say I support = a 192-bit canary outright, but I like the idea and I think more research is= needed to confirm whether it would work, or if such a system would be over= - or under-sensitive (i.e. triggered too late by the first powerful quantum= computer, or triggered exceptionally early by a classical attack). I'm esp= ecially interested in any attempts to estimate a rough time delta between t= he "secp192r is broken" and "secp256k1 is broken" events. I suppose that's = more a question for the QC experts (not me). I'll have a go anyway.
Based on logical qubit count estimates in the google paper=C2=A0(see page 7)= , a QC needs at least 4.5 * n qubits to crack a curve of n bits (with a pra= ctical Toffoli gate count). So secp192r1 might be broken by more than 192 *= 4.5 =3D 900 logical qubits. Breaking secp256k1 requires at least 1200.

So how difficult would it be for a QC to scale from= 900 to 1200 qubits? If we assume QC scaling will follow moore's law (if it= ever scales at all), then that's worrisome: less than half a doubling of m= argin. The first QC that breaks secp192r1 might very well also be able to b= reak secp256k1.

Also: I read the QCAP thread, and my initial impressio= n is that=C2=A0using DLEQAG proofs to share the secret among a trusted grou= p is overkill: If breaking a 192-bit curve such as secp192r1 suffices to pr= ove "QCs are coming" and so activate a soft fork, then why go through the e= ffort to map that statement to secp256k1? We can just use a secp192r1 canar= y proof on its own as a self-contained cryptographic statement published on= -chain. Then the proof can use a NUMS point generated in some honest fashio= n, same as for secp256k1. Nodes could activate the canary as soon as they s= ee the canary proof published anywhere on-chain (e.g. OP_RETURN). As discus= sed before in this thread, there's no need to tie the canary specifically t= o a Bitcoin UTXO being spent.

regards,
conduition

<snip>=C2=A0

--
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/bitcoind= ev/f6565311-f62e-4210-8c15-93830c3f71cbn%40googlegroups.com.
------=_Part_321609_204838202.1787063808639-- ------=_Part_321608_381307020.1787063808639--