Hi conduition, > 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. Well, but this brings me right back to my first comment here (not that it is *my* comment, it's been said elsewhere in thread): this tripwire concept is not a defence against an adversary, right; if the first QC is expensive and difficult (likely), and if they decide to be adversarial, they won't be tripping any wires. But surely it follows, that they have just as much incentive to not trip the 256 wire as the 192 wire. Anyway I will try to now avoid further nerd sniping (including against myself) talking about smaller order curves; I do agree with the points raised, that it's not a sufficiently practical idea (given secp256k1's most excellent property, its cofactor of 1, is extremely unhelpful in this particular case! - therefore nice idea, Pieter, with the 'algebraically similar curve but with subgroups', but I'm willing to bet you're right that that doesn't cut it, either) on more than one axis. Smaller group *canaries* (not tripwires) are still interesting I think. Not amazing, but maybe quite valuable. > 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 interesting find, thanks! > 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. Yes that does seem to be better than single utxo. But perhaps the difference isn't that significant in practice? > 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? I agree it doesn't seem very reasonable that there's a way to counter such a huge incentive in *a* miner as one related to a QC break. It also makes me think: that's not how consensus changes usually work, eh. Giving miners the ability to censor an update seems antithetical. It's also weirdly the opposite shape to what you want: it activates with the permission of 1 of N miners (weighted by hashrate), which means it's kind of guaranteed to occur once the proof exists, but could be quite slow. The counterargument might be: that's not going to happen! Once the proof is public, a miner deliberately not mining it is very transparently a bad actor. Not sure. Seems a bit wobbly but not crazy. Pieter, > 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. 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). 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. [1] Uh not actually sure about that. There was a +rG tweak suggested in BIP341 for better privacy. Don't know how widely it was used (curious, in codebases I looked at, it wasn't). Silent Payments BIP352 explicitly carves out H which, I dunno if that proves anything, but it's an example of people tacitly assuming no tweaking happens. If the tweaking was used it would at least limit how much risk exists with H, though not remove it. On Tuesday, August 18, 2026 at 8:37:02 PM UTC-6 conduition wrote: > 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 > bitco...@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+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/td8wPWxRVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-Vc2fsSoo-Qxfm8Lcnd384Uink%3D%40wuille.net > . > > -- 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/baff534c-a392-4af7-8264-998c3390fe84n%40googlegroups.com.