From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Tue, 18 Aug 2026 07:36:48 -0700 (PDT) [thread overview]
Message-ID: <f6565311-f62e-4210-8c15-93830c3f71cbn@googlegroups.com> (raw)
In-Reply-To: <22f8b95d-403c-4a3e-ad64-221faf2ea851n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 5125 bytes --]
(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,
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, activate the consensus change. But that would mean validating
the ZKP in consensus right? It'd presumably be simpler than literally
implementing the 192 bit curve in consensus (doesn't sound very simple!),
just for this one action. And it's more realistic than the idea of having a
trusted setup to create a small dlog in secp256k1 (because trusted setup in
consensus is not going 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 doesn'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 validating nodes have
to agree. I tended, after our earlier discussion on this, to come to the
conclusion that a 192 bit tripwire would be 'nice' but doesn't seem to be
practical. Could have it as a canary still, ofc. But probably only 256 bit
is going to work as a tripwire?
2nd message:
Oh wait, it's much simpler (not perhaps in character, 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 and consensus nodes
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
simple extra consensus rule, but I wouldn't be surprised if the engineers
still say, no, we should definitely not do that (dependencies?). After all
there is something very ugly about one-off consensus rules like that that
are completely unconnected with bitcoin'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 commenting 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
On Tuesday, August 18, 2026 at 3:17:32 AM 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 especially interested in any attempts to
estimate a rough time delta between the "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
<https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf> (see
page 7), a QC needs at least 4.5 * n qubits to crack a curve of n bits
(with a practical Toffoli gate count). So secp192r1 might be broken by more
than 192 * 4.5 = 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 margin. The first QC
that breaks secp192r1 might very well also be able to break secp256k1.
Also: I read the QCAP thread
<https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-alert/2498>,
and my initial impression is that using DLEQAG proofs to share the secret
among a trusted group is overkill: If breaking a 192-bit curve such as
secp192r1 suffices to prove "QCs are coming" and so activate a soft fork,
then why go through the effort to map that statement to secp256k1? We can
just use a secp192r1 canary 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 fashion, same as for secp256k1. Nodes could
activate the canary as soon as they see the canary proof published anywhere
on-chain (e.g. OP_RETURN). As discussed before in this thread, there's no
need to tie the canary specifically to a Bitcoin UTXO being spent.
regards,
conduition
<snip>
--
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/f6565311-f62e-4210-8c15-93830c3f71cbn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5801 bytes --]
next prev parent reply other threads:[~2026-08-18 14:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 17:42 [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Pieter Wuille
2026-06-26 3:40 ` Nagaev Boris
2026-06-26 11:06 ` Sjors Provoost
2026-06-26 14:10 ` Pieter Wuille
2026-06-26 18:20 ` 'conduition' via Bitcoin Development Mailing List
2026-07-03 21:23 ` Pieter Wuille
2026-07-04 11:57 ` Sjors Provoost
2026-07-05 21:55 ` Antoine Riard
2026-08-13 3:28 ` waxwing/ AdamISZ
2026-08-14 18:33 ` 'conduition' via Bitcoin Development Mailing List
2026-08-15 14:49 ` waxwing/ AdamISZ
2026-08-15 16:52 ` 'conduition' via Bitcoin Development Mailing List
2026-08-15 18:06 ` waxwing/ AdamISZ
2026-08-16 19:30 ` 'conduition' via Bitcoin Development Mailing List
2026-08-18 14:36 ` waxwing/ AdamISZ [this message]
2026-08-18 17:20 ` Pieter Wuille
2026-08-18 23:04 ` Erik Aronesty
2026-08-19 2:32 ` 'conduition' via Bitcoin Development Mailing List
2026-08-19 15:18 ` waxwing/ AdamISZ
2026-08-19 22:16 ` Pieter Wuille
2026-06-27 4:33 ` Anthony Towns
2026-06-29 2:17 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f6565311-f62e-4210-8c15-93830c3f71cbn@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox