From: Pieter Wuille <bitcoin-dev@wuille.net>
To: conduition <conduition@proton.me>
Cc: waxwing/ AdamISZ <ekaggata@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Wed, 19 Aug 2026 22:16:51 +0000 [thread overview]
Message-ID: <Bx0LA0afwRjPIcEol98t7ztodzX7mIBeA1kGLV-rAicu4IuGBkME3A-UzBC5KJOawIciVn1CW3bCILlyVpMJU_MAgqV5OBjSFQiZrX60fb4=@wuille.net> (raw)
In-Reply-To: <FhcVTVM6flM4OpPCZpaGbC3msQG9kG48uvyz6T4qdNv8iAq-clhoMmNmRWSSWs78hug3KZSsKG3Mi2lZIzo5PFY-WvbvxdA0Ssj-G2HCz2o=@proton.me>
Hi,
On Tuesday, August 18th, 2026 at 10:32 PM, conduition <conduition@proton.me> wrote:
> Oh I misunderstood. So to be clear, a "canary" is just a social signal that should push consensus to activate a soft fork, whereas a "tripwire" is an unattended system that automatically triggers a change to consensus rules.
I like that terminology.
> > While it's certainly possible it's actually triggered by a cooperative CRQC, that's not how I expect ECC disabling to happen (instead I expect a community consensus-changing effort, effected through Miner Lockdown or otherwise). The Tripwire just sets an unambiguous expectation that disabling is intended by Q-day.
>
> In the absence of evidence, I expect this fork to be highly contentious or delayed until hard evidence is available.
I don't disagree, but I also do expect hard evidence to become available, unless we're actually taking about scenario where a CRQC appears out of nowhere, and in that case there are really no good outcomes.
> I agree but for a different reason on top. Given the polynomial efficiency of Shor, and the massive time/money investment needed to build quantum computers, we have no reason to expect anyone will build a QC that can break 192-bit curves but not 256-bit curves. There is actually incentive not to do so, especially if breaking a 192-bit curve will cause the Bitcoin network (the most ripe target to pay off QC investors) to react by locking itself down.
> Think of it this way: If you have the mans to build a stable 900 logical-qubit quantum-computer, why not spend the extra time and money to build a 1200 logical-qubit quantum computer? Is a 1.5x factor improvement really so hard at this point? If you do expend the effort, then at least you stand a chance to make some money (e.g. by decrypting old internet traffic on behalf of the NSA).
You seem to be talking about an adversarial CRQC here? Those won't trigger any tripwire, nor publish any canaries.
There is a pretty weird philosophical point here: as far as I'm aware, at this point, there isn't really any application for CRQC-capable hardware except breaking classical cryptography. So beyond scientific curiosity, the only incentive to build one is either adversarial, or to prove it's possible to build one before one lands in adversarial hands. And the better migrated the world is (including Bitcoin...) for PQC, the lower the incentives for both get.
> I think I'm coming to the conclusion that a 256-bit ST-ECDLP tripwire is the way to go, because at least then the canary is unambiguously dead, and it's time to stop using secp256k1, whereas 192-bit curves leave a shred of doubt.
Agreed.
> Really interesting idea there. Small correction: I believe Shor's space (qubit) requirements are dominated primarily by the group order that we are searching for the dlog within, not by the size of the field used for the the elliptic curve group operation. I'm pretty sure the field size would affect runtime complexity (gate count), but not qubit count requirements. (Happy to be corrected). If I'm correct, a group order of approx 2^187 would need approx 842 qubits (at least) to break.
My friendly neighborhood LLM believes the qubit count is primarily a function of the field size (to represent curve coordinates), while the gate count grows with larger with the group (because point multiplication needs more additions), but I am by no means an expert.
> Still, as previously discussed, I'm unsure if a canary which is only slightly harder to break would be meaningful. It'd be nice if we could find some problem which quantum computers of, say, 150 qubits could do, but which classical computers cannot (feasibly) solve. Then we might have a reasonably predictive canary which could be solved by cooperative.
Agreed.
> > From a simplicity standpoint, I think just having a "a UTXO with scriptPubKey X is spent" is ideal, because it reuses all existing block and transaction validation logic, and just adds a trivial trigger.
>
> I would like to make a case that we should expend the extra effort and not bind the canary to a specific UTXO. I will point to Antoine's game theory arguments about reorgs and miner collusion with CRQCs.
>
> If we tie the canary to a specific UTXO, or even to any UTXO with a specific script, then this makes miner censorship of the canary proof very easy: Just block spends of that UTXO (or of any UTXO unlocking the chosen script).
I hadn't considered that. But if miners are actively blocking a security feature (as this effectively is), I think we're in UASF territory already.
> If, on the other hand, we had nodes check something almost as simple, like for example "check every 32-byte OP_RETURN to see if it happens to be the dlog of the NUMS point", then any user can choose to include the proof in their transactions at relatively little cost. Any miners who want to censor the canary proof will have to also censor any such transactions, and so they lose out on the potential fee revenue of the entire TX by doing so.
I think this is pretty unrealistic. Most user software won't have the ability to include a tripwire in an OP_RETURN (this includes all kinds of higher-level / layer-two constructions that need cooperation to build transactions). It further also relies on this happening at a time when fee income is substantial.
> I'm not sure if this incentive is meaningful when compared to the potential bribes that a miner could be offered by a CRQC, but still it is worth considering. It does have the down side that it will slow down block validation slightly (one EC mult per 32-byte OP_RETURN). Maybe this could be accounted for somehow in the sigops budget?
Yeah, these concerns are why I like just triggering on a scriptPubKey, because all cost accounting is dealt with already. That said, I don't think this is a particularly strong point; if there are good reasons to do the trigger through an OP_RETURN, there are probably fairly easy ways of doing that too.
On Wednesday, August 19th, 2026 at 11:36 AM, waxwing/ AdamISZ <ekaggata@gmail.com> wrote:
> Smaller group *canaries* (not tripwires) are still interesting I think. Not amazing, but maybe quite valuable.
Agreed. I think formalized or not, this will effectively be how the ecosystem decides it's time to disable ECC.
> Good point about signature, I wasn't considering that, earlier. If you publish (R, s) with truly random R=kG choice you are not leaking more than what already existed with the pubkey H; that's true if HVZK holds and assuming the ROM (except it has to be "QROM" now, right).
Right.
> However! There might be a non-technical reason to avoid H directly: it's a bit like toxic waste in powers-of-tau and similar: suppose a whitehat organization is targeting a tripwire. If that dlog knowledge is exposed (in the process of creating a valid signature) it has to be destroyed "trustfully", since it'll allow spending of all kinds of coins[1]. This comment is only relevant of course if there is a CRQC which costs 2 months and $100m to run, if it's easy to find a specific dlog whenever, then nothing to talk about.
>
> So yeah I would go with the abundance of caution, myself; don't see how it hurts.
Yeah.
I think the important choice is whether to cater to adversarially-constructed proofs or not. I believe we should not, but:
If yes: use AJ's construction of providing BIP-340 signature on point of the form rG+H with arbitrary r, and arbitrary message. This is incompatible with using UTXO trigger, and needs H (or derivation from H).
If no: no reason to specifically use H, or even support multiple targets. Just pick an "as random as possible" fixed point, are require spending a scriptPubKey with it, or publishing its DLP, or publishing a signature for it.
Cheers,
--
Pieter
--
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/Bx0LA0afwRjPIcEol98t7ztodzX7mIBeA1kGLV-rAicu4IuGBkME3A-UzBC5KJOawIciVn1CW3bCILlyVpMJU_MAgqV5OBjSFQiZrX60fb4%3D%40wuille.net.
next prev parent reply other threads:[~2026-08-19 22:18 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
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 [this message]
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='Bx0LA0afwRjPIcEol98t7ztodzX7mIBeA1kGLV-rAicu4IuGBkME3A-UzBC5KJOawIciVn1CW3bCILlyVpMJU_MAgqV5OBjSFQiZrX60fb4=@wuille.net' \
--to=bitcoin-dev@wuille.net \
--cc=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=ekaggata@gmail.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