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.

Exactly. Also, the canary proof need not be the NUMS discrete log itself, it could also be a signature proving knowledge of the dlog without revealing it outright. Dlog exposure is simpler and faster to verify; Signature allows the first QC to identify itself later. (IDK if useful)

Right, so: the QCAP thread was about a canary rather than a full tripwire

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.

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 think the presence of a 192-bit canary changes this expectation much. 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.

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).

From the google paper:

Given broad progress across multiple hardware architectures, the safe assumption is that there may be little time between the breaking of 256-bit ECDLP and the breaking of 1024-bit ECDLP.

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.

This makes me wonder about using a subgroup of a very related curve: for example y^2 = 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 constructions, I don't think this is worth it, but want to throw the idea out there.

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.

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.

Also found this related paper which proposes an incremental ladder of canaries using NUMS points on a sequence of curves of increasing size: https://arxiv.org/pdf/2508.14011

I also don't think optimizing for multi-target ECDLP adds much.

Strongly agree.

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).

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.

In the extreme case, if every transaction in the mempool contained the canary proof as an OP_RETURN, then censoring miners would receive no fee revenue at all - they would have to mine empty blocks.

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?

regards,
conduition

On Tuesday, August 18th, 2026 at 1:30 PM, Pieter Wuille bitcoin-dev@wuille.net wrote:

Hi all,

I'm unconvinced the complexity of a 192-bit canary is worth it. Picking a curve 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 the secp256k1 prime). A more generic implementation is possible of course, but 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 predictive. Its purpose is setting a codified upper bound on when ECC (within PQC output 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 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.

I don't think the presence of a 192-bit canary changes this expectation much. 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 problems, if they're not so much weaker that they're trivial. This makes me wonder about using a subgroup of a very related curve: for example y^2 = 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 constructions, 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 understanding 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) = 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 problem if the ECDLP break proof is a Schnorr signature (as opposed to revealing the DLP itself). But it also makes sense to be as conservative as possible 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 existing generator G, maybe a block hash from a time when the activation parameters 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 XOR (or hash) all hash results together.

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. It's not compatible with any weaker curve construction of course, or with AJ's H-dependent DLP proof which could enlist non-cooperative CRQC, but I don't think that's worth complicating matters for.

Cheers,

--
Pieter

--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/aWYtPLVPZ3U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/td8wPWxRVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-Vc2fsSoo-Qxfm8Lcnd384Uink%3D%40wuille.net.