(re-sending 2 messages after sending them to the wrong location!):<br /><br />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 :) <br /><br />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?<div><br /></div><div>2nd message:</div><div><br /></div><div>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.</div><div><br /></div><div>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).</div><div><br /></div><div>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.</div><div><br /></div><div>Cheers, waxwing/AdamISZ<div><br /><div><div dir="auto">On Tuesday, August 18, 2026 at 3:17:32 AM UTC-6 conduition wrote:<br /></div><blockquote style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<div><br /></div><div>Based on logical qubit count estimates in <a href="https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf" target="_blank" rel="nofollow">the google paper</a> (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.</div><div><br /></div><div>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.<br /><div><br /></div><div>Also: I read <a href="https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-alert/2498" target="_blank" rel="nofollow">the QCAP thread</a>, 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.</div><div><br /></div><div>regards,</div><div>conduition<br /><br /></div></div></blockquote><div>&lt;snip&gt; </div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/f6565311-f62e-4210-8c15-93830c3f71cbn%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/f6565311-f62e-4210-8c15-93830c3f71cbn%40googlegroups.com</a>.<br />