Giving teeth to expected EC disabling: P2XX(-T)(-ML)

[Pieter Wuille]

Hi all,

In parallel to the threads[1][2][3] discussing the P2TRv2 and P2MR
concepts, I'd like to talk about the possibility of codifying in the
consensus rules the (expectation of) the disabling of EC opcodes/paths
within the new output type.

The motivation for this is that while P2TRv2 has a "soft" built-in
expectation of a future softfork that will disable EC opcodes/paths (just
within the new output type itself) at the right time, its consensus rules
are identical to P2TR (with the exception of PQC opcodes, if those aren't
also added to P2TR). Plans and intent of protocol designers are one thing,
but the future ecosystem isn't beholden to those: the only certainty is the
adopted consensus rules themselves. Without confidence that the intended
disabling will happen, it becomes unclear what CRQC-resistance the P2TRv2
type offers. Meanwhile, P2MR as formulated doesn't need/have such an
expectation, but would still benefit from it, as users are otherwise
restricted to (IMO) extremely onerous restrictions on public key sharing.

To some extent, this is an unsolvable problem: we cannot codify plans that
depend on outside-world conditions like CRQCs existing. Still,
approximations exist which can be added as automatic triggers for this EC
disabling, along with the new output type itself:

* Tripwire (P2XX-T): use the presence of a NUMS point spend as trigger
(suggested by Tadge Dryja[4]).

Specifically, as part of the softfork definition, a NUMS point is
picked. Whenever a transaction is mined whose input contains a successful
"<NUMS> OP_CHECKSIG", EC opcodes/paths are disabled within the new
output type, as of the next block.

Note that the tripwire isn't intended as a replacement for the expected
future EC-disabling softfork; instead, it puts an upper bound on that
disabling.

* Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger
the disabling, allowing a faster reaction time to urgent CRQC threats.

Practically, this can be achieved by bundling the expected EC-disabling
softfork with the softfork that introduces the new output type, but
giving the disabling one a separate, and very long or infinite,
activation window. This means that in addition to expecting the future
ecosystem to decide when Q-day is too close, the hashrate majority is
allowed to make that call too. (suggested offline by Sjors Provoost)

* Combination (P2XX-T-ML): trigger EC disabling either through Tripwire, or
through Miner Lockdown.

I believe P2TR-T and P2MR-T are unambiguous improvements over P2TRv2 and
P2MR respectively. This is because:

* With Tripwire, anyone with a CRQC can, without permission, disable the EC
paths/opcodes in the new output type for everyone. Because of that
possibility, disabling is something all users of the new output type need
to be prepared for at all times, and thus the later EC-disabling softfork
cannot be considered confiscatory. That could otherwise be a reason to
oppose the future EC-disabling softfork.

Consider P2TR and P2TRv2. If there are no differences in consensus rules
between them, it is worth asking why the future ecosystem should be
expected to disable EC paths & opcodes in one but not the other, just
based on earlier-stated plans. With Tripwire, disabling EC in P2TR-T is
categorically non-confiscatory, making doing it there an objective
choice.

* Relatedly, for the same reason it likely convinces users and wallet
developers to test, more seriously, the usability of the expected PQC
paths, as not doing so inevitably means risking burning those coins. This
is especially important for P2MR, which has some incentives to use it
beyond CRQC-protecting coins.

* The only downside I see is some additional technical complexity. The
ability to sign with a NUMS point is an unequivocal proof that the
secp256k1 ECDLP assumption no longer holds, and is thus a clear upper
bound on when EC ought not to be used anymore. Note that this differs
from a canary (an idea which has also been discussed) that uses a weaker
curve, as the goal of those is to be predictive. The point here is
specifically to just be an upper bound.

To me, this makes both P2MR-T and P2TR-T more "Later"-style (as I've
defined it in [5] and follow-ups) than P2MR and P2TRv2 respectively, which
I consider an improvement for both. There still is an expectation of a
later softfork that disables the EC paths/opcodes within the PQC output
type, and thus the tripwire isn't actually expected to ever trigger. Still,
I believe that its presence changes the game theory and incentives around
usage of the output type, and future consensus changes.

Of course, it cannot help with deciding what the right time for the
EC-disabling softfork is, but it can help make it happen. The same is true
for the Miner Lockdown idea. I'm a bit more hesitant about that, as it may
be empowering the (collective of) miners too much. They always have the
ability to just disallow EC spends of course, but the Miner Lockdown idea
makes network nodes start enforcing the same rule too, making it
irreversible. On the other hand, it is still opt-in (users deciding to move
coins to the new output type), and this becomes them choosing to give
miners a Lockdown button, which can presumably be used on shorter notice
than the ecosystem can agree on a consensus change (even if it's
pre-planned).

I'd prefer to keep the discussion here just about adding the Tripwire
and/or Miner Lockdown ideas, rather than MR vs TR, as I think this is
orthogonal to the distinction between those.

Thoughts?

--
Pieter

[1]: https://groups.google.com/g/bitcoindev/c/Qy4gwAGTK2w/m/_CjQ8xvdAAAJ
[2]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/T7UWqgnvAAAJ
[3]: https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603
[4]: https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ
[5]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA/m/Gona1fr3AgAJ

[Nagaev Boris]

Hi Pieter,

I think Tripwire is an improvement to all "Later" versions of P2MR,
P2TRv2, and P2TRH. Given coin owners have pre-agreed to later
lockdown, having an upper bound does not harm.

For Miner Lockdown, I see a potential false-positive activation. A
large classical theft may happen, be misinterpreted as a CRQC event,
and miners may lock the EC path with the best intentions, but it turns
out to be a false alarm. Shouldn't there be a mechanism for
reactivation in this case? We have historical examples of bugs causing
large-scale or initially mysterious thefts: Milk Sad, Android
SecureRandom 2013, and the LuBian 2020 theft. A similar event in the
future could be confused with Q-day, and miners could push the button.

Can you elaborate on the scope of EC disabling, please? Does it
disable only the main EC path (e.g. key spend in the case of Taproot
v2) or all EC involving paths? What will happen to scripts using
something else in addition to EC? Some useful constructions may
include an EC opcode, e.g. hybrid EC-PQ signatures or HTLCs. Maybe it
makes sense to disable the main spending path and keep hash-protected
supplementary paths available?

Best,
Boris

> --
> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/yHRpA2LEJ2AugT4W2KiWO3ggSims4GuHBkr6rWtE-e1uVC2wh3ZqD4bUDyxXq1iEuPrezhZZeqDoG7uBLNvjbW0sk_UTorI1Pkz6LcKhXRA%3D%40wuille.net.



--
Best regards,
Boris Nagaev

[Sjors Provoost]

Hi Boris and Pieter,

I agree that the potential for premature activation is a downside of Miner Lockdown. It could come with a very long window (years) between signalling and activation. That way users who consider it premature can mass migrate back to P2TR, only to return to P2TRv2 / P2TMR at a moment of their choosing.

In the other direction, there's a a positive incentive to not wait too long: the 100 block coinbase maturity makes them more vulnerable to short-range attacks (for P2TRv2, but not P2TMR).

I think it's important that a proposal involving the eventual trimming of its own spending paths, includes the activation mechanism(s) for such trimming. At least some of the mechanisms.

I'm also worried that miners don't want to carry such heavy burden of responsibility, and deal with political pressure (in both directions). In that case they would oppose inclusion of ML in the two-stage proposal, and that would be very useful to learn early on.

- Sjors

> Op 26 jun 2026, om 05:40 heeft Nagaev Boris <bna...@gmail.com> het volgende geschreven:
>
> Hi Pieter,
>
> I think Tripwire is an improvement to all "Later" versions of P2MR,
> P2TRv2, and P2TRH. Given coin owners have pre-agreed to later
> lockdown, having an upper bound does not harm.
>
> For Miner Lockdown, I see a potential false-positive activation. A
> large classical theft may happen, be misinterpreted as a CRQC event,
> and miners may lock the EC path with the best intentions, but it turns
> out to be a false alarm. Shouldn't there be a mechanism for
> reactivation in this case? We have historical examples of bugs causing
> large-scale or initially mysterious thefts: Milk Sad, Android
> SecureRandom 2013, and the LuBian 2020 theft. A similar event in the
> future could be confused with Q-day, and miners could push the button.

> [...]

> Best,
> Boris
>
>
> On Thu, Jun 25, 2026 at 1:31 PM Pieter Wuille <bitco...@wuille.net> wrote:
>>
>> Hi all,
>>
>> In parallel to the threads[1][2][3] discussing the P2TRv2 and P2MR
>> concepts, I'd like to talk about the possibility of codifying in the
>> consensus rules the (expectation of) the disabling of EC opcodes/paths
>> within the new output type.

[...]

>> Specifically, as part of the softfork definition, a NUMS point is
>> picked. Whenever a transaction is mined whose input contains a successful
>> "<NUMS> OP_CHECKSIG", EC opcodes/paths are disabled within the new
>> output type, as of the next block.
>>
>> Note that the tripwire isn't intended as a replacement for the expected
>> future EC-disabling softfork; instead, it puts an upper bound on that
>> disabling.
>>
>> * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger
>> the disabling, allowing a faster reaction time to urgent CRQC threats.
>>
>> Practically, this can be achieved by bundling the expected EC-disabling
>> softfork with the softfork that introduces the new output type, but
>> giving the disabling one a separate, and very long or infinite,
>> activation window. This means that in addition to expecting the future
>> ecosystem to decide when Q-day is too close, the hashrate majority is
>> allowed to make that call too. (suggested offline by Sjors Provoost)
>>

[...]

[Pieter Wuille]

Hi Boris,

See responses inline below.

On Friday, June 26th, 2026 at 5:41 AM, Nagaev Boris wrote:

> For Miner Lockdown, I see a potential false-positive activation. A large
> classical theft may happen, be misinterpreted as a CRQC event, and miners
> may lock the EC path with the best intentions, but it turns out to be a
> false alarm. Shouldn't there be a mechanism for reactivation in this case?
> We have historical examples of bugs causing large-scale or initially
> mysterious thefts: Milk Sad, Android SecureRandom 2013, and the LuBian
> 2020 theft. A similar event in the future could be confused with Q-day,
> and miners could push the button.

I agree that's a concern, but of course, if this happens, no coins are
lost, just inefficient to access. As Sjors mentions, it's possible for
users to move back to P2TR temporarily, but that of course goes counter to
the CRQC-protection goal, and if it happens at scale, chain capacity
problems may cause chaos.

Adding the ability to revert is a possibility, but I'm not sure it's all
that much better than realizing there is also the possibility of adding a
new P2TRv3 / P2MRv2 / ... that is in a pre-lockdown state?

> Can you elaborate on the scope of EC disabling, please? Does it disable
> only the main EC path (e.g. key spend in the case of Taproot v2) or all EC
> involving paths?

I agree with Antoine that it necessarily must disable all usage of EC
inside the new output type, so that includes taproot key path spending (if
present), and making any execution of an OP_CHECK* opcode with a non-empty
signature for an EC pubkey cause the transaction to be invalid. Anything
else falls short of the goal of making it possible for users to keep
sharing public keys. This should be the case for all disabling, whether
through Tripwire, Miner Lockdown, or a future softfork.

> What will happen to scripts using something else in addition to EC? Some
> useful constructions may include an EC opcode, e.g. hybrid EC-PQ
> signatures or HTLCs. Maybe it makes sense to disable the main spending path
> and keep hash-protected supplementary paths available?

My thinking is that hybrid signature schemes, if desired, should be dealt
with at the opcode level, and not the script level. That is, there would be
(only) an OP_CHECKHYBRIDECSQISIGN opcode, not an expectation to use both
OP_CHECKSIG and OP_CHECKSQISIGN. My reason for this is that I think the
question of what level of security is appropriate (i.e., whether schemes
should be protected with a layer of EC hybridity) should be a consensus
decision, not an individual one.

Thinking about it, maybe that means it makes sense to completely separate
PQC scripts and (pure-)EC scripts at the script leaf level, by having
separate script leaf versions for them. That rules out some potentially
useful ways of using conditionals that have PQC and pure-EC branches, but
those do seem pretty error prone (as mixing the two within one execution
trace would be unusable post EC-disabling).

Practically, my thinking is that due to the low cryptographic assumptions
needed for hash-based schemes, those wouldn't need hybridization with EC
(though the statefulness of some variants is worrying). I don't think
schemes relying on other assumptions feel ready in terms of confidence for
adding to Bitcoin to me, but that can change.

Cheers,

--
Pieter

[conduition]

Hi Pieter,

Thanks for voicing this, I'm generally very supporting of the tripwire idea. It's an easy win for any PQ output type.

I have a few comments on the specifics.

> Specifically, as part of the softfork definition, a NUMS point is picked. Whenever a transaction is mined whose input contains a successful "<NUMS> OP_CHECKSIG", EC opcodes/paths are disabled within the new output type, as of the next block.

Mining an on-chain spend isn't the only option. The signature by (or discrete log of) the NUMS point is itself a sufficient and succinct proof that EC spending ought to be disabled. We don't need a trustless "honeypot"/"reward"/"bounty" for the CRQC, since we're already assuming the CRQC is cooperative. We don't need the "tripwire proof" to be included on-chain except for posterity (i.e. nodes bootstrapping after Q-day, to know when to enact the new consensus rules retroactively). All a validator node today needs is to see the signature/discrete log of the NUMS point, anywhere, at any time, to know that EC spending ought to be disabled immediately.

It could be in an OP_RETURN, it could be a new field in a block, it could be a simple P2P message or just seeing a TX containing the tripwire proof appear in the mempool. Maybe requiring the tripwire proof to be mined is simple to implement for validators, but relying on that alone runs the risk of miners censoring or purposefully delaying the inclusion of the tripwire proof in a block. So it might be worth the extra complexity engineering of a more highly reactive solution.

I'm not sure what the best option here is yet, but I just wanted to point out the tripwire doesn't have to be a UTXO spend, and we should discuss more options and their trade-offs.

> Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger the disabling, allowing a faster reaction time to urgent CRQC threats.

I'll echo the others' concerns here about early activation, and add that miners may actually be incentivized to trigger this activation early if given the chance, since doing so will massively pump their fee revenue (though perhaps at a cost to the price of Bitcoin itself). This could be more of a concern as the subsidy drops lower and miners with sunk cost seek to recoup their up-front hardware investment.

Generally I think this is a good idea though, and might be worth the risk especially because, as you stated, early activation will not confiscate any meaningful amount of coins. But it should also be possible for nodes to reject a bad-faith early activation.

The more important question is, how do you propose to technically achieve this? How does "majority hashpower" enact the disabling? My fear is that the reaction time will actually be very slow, because for us to measure "majority hashpower" we typically measure this over an epoch of many blocks. Otherwise a random minority miner could luck their way into a few blocks that signal for EC disabling, and so trigger the fork early.

The activation window would need to be spread out, and the further it is spread out the less time miners have to react, if they even react at all.

> I agree with Antoine that it necessarily must disable all usage of EC inside the new output type, so that includes taproot key path spending (if present), and making any execution of an OP_CHECK* opcode with a non-empty signature for an EC pubkey cause the transaction to be invalid. Anything else falls short of the goal of making it possible for users to keep sharing public keys. This should be the case for all disabling, whether through Tripwire, Miner Lockdown, or a future softfork.

This will confiscate coins held in hybrid scripts and in multisigs whose parties use different sig-schemes, e.g. <ec_pubkey> CHECKSIG <pq_pubkey> CHECKSIG.

I would suggest to enforce the disabling by running spend validation as normal, but failing at the end if EC-checksig operations have occurred without any PQ-checksig ops. This also implicitly disables P2TR-style key-spending and Boris' EC recovery scheme in P2TRH and P2MR, because such spends wouldn't involve a PQ signature.

> My thinking is that hybrid signature schemes, if desired, should be dealt with at the opcode level, and not the script level. That is, there would be (only) an OP_CHECKHYBRIDECSQISIGN opcode, not an expectation to use both OP_CHECKSIG and OP_CHECKSQISIGN.
>

> Practically, my thinking is that due to the low cryptographic assumptions needed for hash-based schemes, those wouldn't need hybridization with EC (though the statefulness of some variants is worrying).

In the SHRINCS proposal we elect not to introduce a hybrid EC+PQ signature scheme, for a few reasons:

- Complexity & fragility. A hybrid scheme necessitates a brand new Schnorr signature scheme because combiners like Bird-of-Prey don't use Schnorr as a black-box. Expands the scope of implementation a lot.
- Lack of value. Strong unforgability (one of the main selling points of hybridization) is not security-critical because witnesses don't affect TXIDs anymore. At best a hybrid scheme would provide a minor ~5%-10% improvement in witness size over a naive scripting approach, and this is still less efficient than keeping keys compartmentalized in isolated spending paths.
- Redundancy. Deploying SHRINCS as a standalone opcode is already needed for post-Q-day spending, so taking that opcode as a-given, users will already have access to hybridization techniques by using hybrid scripts.
- Security. Standalone SHRINCS uses fewer cryptographic assumptions than BIP340. Adding Schnorr hybridization thus hedges only against implementation flaws or state reuse, both of which can be effectively mitigated against.

We thus concluded that deploying a hybrid scheme doesn't seem to offer much unique value, and comes at the expense of great risk and effort in adding a new checksig algorithm, which very few people will use anyway since they have much cheaper options (separate leaf scripts).

I suspect hybrid script users will exist, but will likely be limited to major custodians, high-security vaults, and other such address-reusers. Dedicated hybrid signature algorithms may be desirable in the future with other signature schemes, but I doubt we'll be doing this with SHRINCS anytime soon.

regards,
conduition

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw%3D%40wuille.net.
>

[Anthony Towns]

On Thu, Jun 25, 2026 at 05:42:35PM +0000, Pieter Wuille wrote:
> * Tripwire (P2XX-T): use the presence of a NUMS point spend as trigger
> (suggested by Tadge Dryja[4]).
>
> Specifically, as part of the softfork definition, a NUMS point is
> picked. Whenever a transaction is mined whose input contains a successful
> "<NUMS> OP_CHECKSIG", EC opcodes/paths are disabled within the new
> output type, as of the next block.

A slight variant of this approach would be to have a 128 byte value
"aRsm", such that P = N+a*G, N is the BIP-341 NUMS point, and Rs is a
BIP340 signature of m by P. That would allow the victim of post-quantum
theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire,
in addition to someone who has direct access to a CRQC.

I think it could make sense to have the tripwire be included in the
block via the coinbase witness commitment output, rather than having it
be locked to a transaction, so you only having to check the coinbase for
the magic rather than every transaction. That would require a separate
P2P message to relay the necessary ECDL-break proof to miners, and would
probably need stratumv2 or a getblocktemplate update in order for the node
to be able to tell pools to actually include that info in the coinbase.

> * Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger
> the disabling, allowing a faster reaction time to urgent CRQC threats.

> The same is true
> for the Miner Lockdown idea. I'm a bit more hesitant about that, as it may
> be empowering the (collective of) miners too much. They always have the
> ability to just disallow EC spends of course, but the Miner Lockdown idea
> makes network nodes start enforcing the same rule too, making it
> irreversible.

Some potential ways of making that less dangerous:

* Have it require a 100% signalling threshold, instead of 90%/95%
* Have it have a longer signalling period (4032 blocks?)
* Have it be continually soft-forked out (URSF-style):
a) 100% signalling activates it, at any time
b) as at 2026-07-01, 100% signalling is invalid prior to 2026-12-31
c) as at 2026-10-01, 100% signalling is invalid prior to 2026-03-31
d) as at 2027-01-01, 100% signalling is invalid prior to 2026-06-30
e) as at 2027-04-01, danger signs! 100% signalling remains valid after
2026-06-30
f) as at 2027-07-01, signalling actually starts
(alternatively, if three to six months lead time was too long,
a secondary soft-fork could be done on as soon as the danger
signs appear that indepdently disables EC spends immediately,
and also forces 100% signalling from 2027-07-01 for backwards
compatibility)

Cheers,
aj

[Antoine Riard]

Hi Pieter,

Thanks for your work on this subject.

While I was reading your explanation of the technical idea of
disabling EC paths, notably of miner lockdown, it came to my
mind, that I'm not confident that what you're proposing can
even be made technically robust.

If I'm understanding correctly your proposal, e.g for the tripwire
idea, a well-constructed nothing-under-my-sleeve point would be
picked up [0] and then used as an automatic trigger to disable the
new output type (e.g P2MR).

The real problem is more while the restriction would be introduced
as a soft fork, i.e restraining the validity space of the consensus
information space with new verification rules, due to the numerous
hooks introduced by P2TR (the annex, the leaves versioning, etc)
re-employed directly by P2MR.

Based on those hooks, I could see how a majority collective of miners
could re-introduce a soft-fork to re-enable the validity of the
EC-disabled paths to allow the coins to be spent by a CQRC actor,
(or whatever a cartel of CRQC actors lobbying a collective of miners).

Saying that we should just assume the 51% of miners acting for the
long term interest of the network at all times is a not a serious
security assumption. It might have to be some astute designed soft-fork
with a layer of indirection to re-introduce the coins, but frankly
I don't see how you can prevent massive "unfreeze" at a latter chain
"time" of the activation of your tripwire idea, if you can assume
that a (even transient) majority of miners might act in coordination with
a cartel of CQRCs.

I did echo in the past my opposition to "freeze" the coins on the mail
thread you're mentioning, so of course I might look on your proposal
with a more adversarial lense. I do note at least the idea to make the EC
disable wrapped in P2MR only, somehow that would be introducing an opt-in
mechanism for the users and not applying the tripwire disablement to users
who do not agree with this consensus rule for their coins.

Back to the central point, in a consensus world where there are many
upgradeability consensus rules, and as you're observing yourself we
cannot predict what would a collective of miners in the future, I do
not see how a EC "forever" disable path can be implemented robustly.

There is something that doesn't work in terms of game theory.

If the miners are economically rational actors, and it's technically
possible to design a soft-fork to re-introduce the "freeze" coins
why the miners are not going to collude with CRQC actors, if a CQRC
machine ever becomes a reality...

Best,
Antoine
OTS hash: 0c4f7a46103facb2e7e49586d7e8a267be3c7cb611db5961f306aaea19c332ac

[0] A cryptographically-leaning mind can note the first difficulty
here. Quid if it's not a "real" nothing-under-my-sleeve point...

[Pieter Wuille]

Hi list,

Some responses inline below.

On Friday, June 26th, 2026 at 2:20 PM, conduition <condu...@proton.me> wrote:

> Mining an on-chain spend isn't the only option. The signature by (or discrete log of) the NUMS point is itself a sufficient and succinct proof that EC spending ought to be disabled. We don't need a trustless "honeypot"/"reward"/"bounty" for the CRQC, since we're already assuming the CRQC is cooperative. We don't need the "tripwire proof" to be included on-chain except for posterity (i.e. nodes bootstrapping after Q-day, to know when to enact the new consensus rules retroactively). All a validator node today needs is to see the signature/discrete log of the NUMS point, anywhere, at any time, to know that EC spending ought to be disabled immediately.
>
> It could be in an OP_RETURN, it could be a new field in a block, it could be a simple P2P message or just seeing a TX containing the tripwire proof appear in the mempool.

There are multiple variations of what the tripwire proof could look like, and I don't think the details matter as much. However, it must be part of the chain or it's not available to consensus rules. Just seeing a ECDLP breakage proof is not enough, because enforcing nodes need to be in agreement about which blocks it applies to. And without being in the chain, there is no way to guarantee all nodes see the proof at the same time w.r.t. blocks, and discrepancies will leak to forks.

The options I know of:

* Using a spend of a known-to-be-NUMS transaction output (as my original mail proposed). I like this because it needs no infrastructure, and has no DoS concerns as it's just a normal transaction.

* Just publishing the DLP in a transaction (e.g. OP_RETURN with a specific marker). This is smaller than a full transaction input + signature.

* Similarly, but publishing in the coinbase, and requiring relay using a separate message. Less places a node needs to check, but I'm concerned about the difficulty of testing infrastructure that relay of such a message works.

* Either of the two above options, but with AJ's (sig + msg + tweak) proof form, which could be used to prove P2TR key-path spends with NUMS internal key by unknowing malicious CRQCs. It's neat, but I'm not sure catering to non-cooperative CRQCs is all that relevant, because (a) if thefts are happening, I think it's all too late anyway and (b) Malicious CRQCs aren't likely to go after P2TR outputs first, probably, including for this reason. Maybe it discourages them from stealing P2TR though, which may be a reason to consider it...

> Maybe requiring the tripwire proof to be mined is simple to implement for validators, but relying on that alone runs the risk of miners censoring or purposefully delaying the inclusion of the tripwire proof in a block. So it might be worth the extra complexity engineering of a more highly reactive solution.

That is a fair concern, but it's inevitable. Miners are by definition the decider of the ordering of events as far as the consensus rules are concerned. This includes when the trigger happens.

> > Miner Lockdown (P2XX-ML): allow a hashrate majority/threshold to trigger the disabling, allowing a faster reaction time to urgent CRQC threats.
>
> I'll echo the others' concerns here about early activation, and add that miners may actually be incentivized to trigger this activation early if given the chance, since doing so will massively pump their fee revenue (though perhaps at a cost to the price of Bitcoin itself). This could be more of a concern as the subsidy drops lower and miners with sunk cost seek to recoup their up-front hardware investment.

That's a fair concern. A related one is that if the activation of the trigger is at a time with a juicy mempool full of ECC spends, it may encourage miners to not include the trigger, or if one does, for others to reorg it. I think this can partially mitigated by having a delay of something in the order of days between activation and actual enforcement (for both tripwire and miner lockdown).

> The more important question is, how do you propose to technically achieve this? How does "majority hashpower" enact the disabling? My fear is that the reaction time will actually be very slow, because for us to measure "majority hashpower" we typically measure this over an epoch of many blocks. Otherwise a random minority miner could luck their way into a few blocks that signal for EC disabling, and so trigger the fork early.

BIP9, with modified parameters, probably? It'd be conditional on the consensus change that introduces the P2XX-ML output type, which would be the real softfork activation. The lockdown just reuses the same signalling infrastructure, but isn't a consensus change. I haven't really thought about what the parameters need to look like.

> The activation window would need to be spread out, and the further it is spread out the less time miners have to react, if they even react at all.

I'm not sure what you mean here.

> This will confiscate coins held in hybrid scripts and in multisigs whose parties use different sig-schemes, e.g. <ec_pubkey> CHECKSIG <pq_pubkey> CHECKSIG.
>
> I would suggest to enforce the disabling by running spend validation as normal, but failing at the end if EC-checksig operations have occurred without any PQ-checksig ops. This also implicitly disables P2TR-style key-spending and Boris' EC recovery scheme in P2TRH and P2MR, because such spends wouldn't involve a PQ signature.

I don't think self-crafted hybrid schemes should be something to cater to, but that approach works, indeed. PQC scripts could also be just a separate script leaf version, which has no ECC opcodes from the start.

> We thus concluded that deploying a hybrid scheme doesn't seem to offer much unique value, and comes at the expense of great risk and effort in adding a new checksig algorithm, which very few people will use anyway since they have much cheaper options (separate leaf scripts).

I agree that SHRINCS doesn't need hybridization.

On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns <a...@erisian.com.au> wrote:

> A slight variant of this approach would be to have a 128 byte value "aRsm", such that P = N+a*G, N is the BIP-341 NUMS point, and Rs is a BIP340 signature of m by P. That would allow the victim of post-quantum theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire, in addition to someone who has direct access to a CRQC.

Indeed, I had considered something similar, but see above for why I'm not convinced supporting non-cooperative CRQCs is that useful.

Also, in my view the tripwire isn't really a security feature on itself (it's not expected to trigger...), but more something that sets expectations around the output type for prospective users.

In that sense, the question is really whether supporting non-cooperative CRQCs helps set that expectation more than only cooperative ones, which are definitely easier to support.

> I think it could make sense to have the tripwire be included in the block via the coinbase witness commitment output, rather than having it be locked to a transaction, so you only having to check the coinbase for the magic rather than every transaction. That would require a separate P2P message to relay the necessary ECDL-break proof to miners, and would probably need stratumv2 or a getblocktemplate update in order for the node to be able to tell pools to actually include that info in the coinbase.

I worry this is untestable, really. You'd need things like fake-tripwires to be supported through the same message which don't require an ECDLP break, and still propagate. And then that needs DoS protection measures, and ...

On Sunday, June 28th, 2026 at 10:31 PM, Antoine Riard <antoin...@gmail.com> wrote:

> [0] A cryptographically-leaning mind can note the first difficulty here. Quid if it's not a "real" nothing-under-my-sleeve point... Show original message

Due to EC's random self-reducibility, if an attacker has a non-negligible change of finding the DLP of a randomly chosen point, they can do that for any point. It of course needs to be a random point, but hash-to-curve achieve that.

The BIP341 NUMS point (which I suggest using in this context) is the point whose X coordinate is the SHA256 hash of the generator point G. This guarantees that the NUMS point cannot predate G (if it did, it would be possible in theory that secp256k1's designers actually chose G in function of what we call that NUMS point, giving it a DLP known to them).

> but frankly I don't see how you can prevent massive "unfreeze" at a latter chain "time" of the activation of your tripwire idea, if you can assume that a (even transient) majority of miners might act in coordination with a cartel of CQRCs.

Unfreezing requires a hardfork, and won't be accepted by any existing node that implemented the tripwire logic. After the EC opcodes within the relevant output type are disabled, those spend paths are gone from the perspective of existing nodes.

It's of course always possible to introduce a new output type with ECC opcodes, or new ECC opcodes within existing output types (e.g. using OP_SUCCESSx). This is always an option the ecosystem has (not miners!), but it won't affect coins using the older output type/opcodes, which are the ones that matter here.

--
Pieter

[Sjors Provoost]

On Fri, Jul 3, 2026, at 23:23, Pieter Wuille wrote:

[...]

> * Just publishing the DLP in a transaction (e.g. OP_RETURN with a
> specific marker). This is smaller than a full transaction input +
> signature.
>
> * Similarly, but publishing in the coinbase, and requiring relay using
> a separate message. Less places a node needs to check, but I'm
> concerned about the difficulty of testing infrastructure that relay of
> such a message works

[...]

>
> On Saturday, June 27th, 2026 at 12:33 AM, Anthony Towns
> <a...@erisian.com.au> wrote:
>
>> A slight variant of this approach would be to have a 128 byte value "aRsm", such that P = N+a*G, N is the BIP-341 NUMS point, and Rs is a BIP340 signature of m by P. That would allow the victim of post-quantum theft via a key-path spend of a BIP341 NUMS IPK to trigger the tripwire, in addition to someone who has direct access to a CRQC.
>
> Indeed, I had considered something similar, but see above for why I'm
> not convinced supporting non-cooperative CRQCs is that useful.
>
> Also, in my view the tripwire isn't really a security feature on itself
> (it's not expected to trigger...), but more something that sets
> expectations around the output type for prospective users.
>
> In that sense, the question is really whether supporting
> non-cooperative CRQCs helps set that expectation more than only
> cooperative ones, which are definitely easier to support.
>
>> I think it could make sense to have the tripwire be included in the block via the coinbase witness commitment output, rather than having it be locked to a transaction, so you only having to check the coinbase for the magic rather than every transaction. That would require a separate P2P message to relay the necessary ECDL-break proof to miners, and would probably need stratumv2 or a getblocktemplate update in order for the node to be able to tell pools to actually include that info in the coinbase.
>
> I worry this is untestable, really. You'd need things like
> fake-tripwires to be supported through the same message which don't
> require an ECDLP break, and still propagate. And then that needs DoS
> protection measures,

I whipped something up last weekend:
https://github.com/Sjors/bitcoin/pull/121

It seems straightforward, but maybe I missed something:
- for test code we use a fake NUMS point, so we can generate "proof" without a quantum computer
- a p2p message floods the proof
- nodes ignore the message if they already have *any* valid proof
- verifying p2p proof candidates might need some rate limiting, but it's as cheap as verifying a transaction signature
- mining code includes the proof in a coinbase op_return, until the freeze activates
- with stratum v2 (and ipc mining clients in general this works out of the box, a small change is needed for getblocktemplate clients)
- since the proof is not in the header, we can't use the normal bip9 style header scan to see if the rule activated. Instead the prototype stores it in a file along with a merkle inclusion proof, which is read when the node restarts.

With this mechanism it doesn't really need to be in the coinbase transaction, but that does seem more convenient and miners can censor it anyway.

- Sjors

[Antoine Riard]

Hi Pieter,

Thanks for the observations.

When I was saying there is a problem with the game theory,
it's that strikingly, any activation of the tripwire logic
would rely on a "flag" transaction being mined in the chain
for the network nodes starting to enforce at the block N or
N+1 or whatever the EC disabling threshold.

Any "flag" transaction can be itself re-orged out of the chain
to purely disable the effects of the EC disabling threshold,
therefore make it null and void as an effect. One might see
it as a competing race between a group of "sunsetting" users
and a (majority) coalition of miners in coordination with a
CRQC adversary, where the latter have an interest and the
hashrate capabilities to do a tx-withold [0].

In pure terms of satoshi fee denominated calculus, empirically
global miners have won an average of $20 B yearly. If we only
consider that P2PK are going to be frozen by the tripwire effect,
as for most of them it might be assumed they will never move to
a safer format, we talk already about 1.7 M of coins or as of
today valuation $107 B (the information is on the chain and can
be verified).

That's $107B can "burn" in revenue or income that a CRQC-enabled
miners coalition to constantly reorg-out the "flag" tx out of the
chain. In other terms, something like 5 years of income, and I
kindly do not count all the loss coins that are likely to amount
to a far bigger "tripwire" neutralization budget.

In the name of what a majority of miners will gracefully let on
the table an opportunity of massive income ?

Leveraging Shor the exploitation might be even done anonymously
as the mining process is done. Not even certainty, by who the
EC-protected coins could be covertly exfiltrated.

That's the most striking problem when you think about the math
with any "tripwire" approach, or even an "hourglass" one relying
on a "flag" transaction [1]. I'm ruling out "checkpoints" and
any other trust-the-dev approach, as that's even worst [2].

As you're introducing post is resounding, what the miners
are saying now, there are no guarantees on how they would use
their hashrate down the road, potentially 10 or 20 years from now.

Beyond, and to answer back your point, I still think you can
manage an escape hatch of the "tripwire" effect, it's all depends
how the script tripwire logic is implemented, but if you have
two OP_SUCCESS of different kinds before your EC CHECKSIG, you
can always have a "soft-fork" after the "tripwire" to return
true on the stack, with an EC or hashlock as a success (I agree
using undefined op_success in a script is not safe at all) [3].
 
Best,
Antoine
OTS hash: 4bc91d8dee1625f6e78b27c88bced8e405f25ef6d3d8fd59be8016db5b0fbe66

[0] See naumenkog's https://www.bitmex.com/blog/txwithhold-smart-contracts
[1] This is sad, as the "hourglass" depending how the parameters are chosen
was a more acceptable trade-off than pure sunsetting.
[2] Given the amounts at stake to sunset, as a group of developers you
would just paint yourself a target, there are more even funds at stake
that Satoshi herself / himself is assumed to have.
[3] There is no security proof in BIP341 on the unforgeability of the
NUMS point, if it binds in the ROM or whatever.

--
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/002f2395-7d5d-4cb6-852c-e991aa1f0eb3%40app.fastmail.com.

[waxwing/ AdamISZ]

This tripwire idea is interesting. Basically "canary in consensus".

I agree it's valuable. In the scenario of adversarial actor(s) gaining access to CQRC first, i.e. no whitehats, only blackhats, obviously nothing to discuss; touching a NUMS ECDL is the last thing they'll do. So I'm slightly worried that the general userbase will not notice that point, instead thinking it's a solid defense when it ... depends.

In the scenario of at least some whitehats, we get wires tripped, or canaries singing. Having it in consensus is nice. The blockchain then does its job of being an unambiguous signal and we can have all the arguments well ahead of time. [1]

On the other hand, we traditionally design such systems adversarially, right, so you could argue that an overfocus on this might be suboptimal - it might be better to do other things.

(Similar comment applies to the 'smaller group canary' - definitely nothing wrong with it, but it is not in itself a defence unless we strongly believe whitehats, and *active* whitehats at that, are keeping up). An obvious question to raise: would we consider tripwiring a 192 bit group break of a similar type (NUMS)? I find that ... plausible?

> The BIP341 NUMS point (which I suggest using in this context) is the point whose X coordinate is the SHA256 hash of the generator point G. This guarantees that the NUMS point cannot predate G (if it did, it would be possible in theory that secp256k1's designers actually chose G in function of what we call that NUMS point, giving it a DLP known to them).

w.r.t. 'This guarantees that the NUMS point cannot predate G' yes based on SHA2 preimage resistance, but: isn't the real point that we're relying on SHA-2 not being a naughty function so that you couldn't find G = a * B and SHA2(G) = b*B for some base B in some feasible computation (sans CQRC of course, as was likely back then!). I have no idea what precise name you give to that property. OK, this is a ridiculous thing to discuss, perhaps, given when SHA2 and secp256k1 were standardized :) And given the encoding choices for our BIP341 NUMS (iirc the same as for Elements back in the day? using uncompressed encoding?) were able to be counted on the fingers of the hand which the sleeve does not cover :)

[1] I take Antoine's point that making it consensus means the miners are involved and there is a non-trivial collusion risk if the stakes are high, but I can't see how this scenario is *worse* than no tripwire?

[conduition]

An obvious question to raise: would we consider tripwiring a 192 bit group break of a similar type (NUMS)? I find that ... plausible?

A 192-bit curve i think should be reasonable as a canary, but consider this: If someone already has a QC that breaks 192-bit ECC, how long until they build one which breaks 256-bit ECC? A day, a week, a year? No way of knowing. If the delay is too long, users may see the canary as a false-positive, and migrate back to vulnerable addresses, and they might even be right. 192-bit canaries are vulnerable to classical attack with work approximately 2^96. We should bear in mind the possibility that such a canary could be activated possibly very early, well before Q-day, possibly even in the absence of any quantum computers.

Ideally we want a short gap between "192-bit is broken" and "256-bit is broken", but not so short as to make the 192-bit canary effectively fungible with a 256-bit canary (because then it's less likely to be activated before theft occurs).

w.r.t. 'This guarantees that the NUMS point cannot predate G' yes based on SHA2 preimage resistance, but: isn't the real point that we're relying on SHA-2 not being a naughty function so that you couldn't find G = a * B and SHA2(G) = b*B for some base B in some feasible computation (sans CQRC of course, as was likely back then!). I have no idea what precise name you give to that property. OK, this is a ridiculous thing to discuss, perhaps, given when SHA2 and secp256k1 were standardized :) And given the encoding choices for our BIP341 NUMS (iirc the same as for Elements back in the day? using uncompressed encoding?) were able to be counted on the fingers of the hand which the sleeve does not cover :)

Anyone can find G = a * B​. Just generate a key and invert your secret key.

P = a * G​

G = a**-1 * P

The hard part is then finding some b such that b*G = SHA256(G).

---------

If we reflect on the requirement that G​ is fixed, we see SHA256(G)​ is also fixed as a pseudorandom challenge point. The reason for using SHA256 instead of, say, picking an arbitary point by committee or using digits of pi or some other trickery, is that hash outputs are supposed to be random and so SHA256(G)​ is (assumably) a random ECDLP challenge. This matches the classical definition of ECDLP more tightly: Given an arbitrary point P​, find p​ such that P = p * G​. The assumption is that if an attacker can factor an honestly-sampled challenge point, they can factor any point. SHA256 is just a stand-in for the "honestly-sampled" part.

However, the following two tasks are actually very different:

1. Given G, find scalar a​ such that a*G = lift_x(SHA256(G))​.
2. Given G, find scalar a​ and message m​ such that a*G = lift_x(SHA256(m))​.

In the case of task 1, if we assume SHA256 output is random, then this is more tightly equivalent to ECDLP, because the point we're trying to factor is a fixed target, as is the one sampled honestly by the ECDLP security game.

In the case of task 2, the attacker can sample arbitrary messages to create multiple target points, and the attacker wins if they succeed in factoring any of them. The attacker can attack all those target points concurrently if they want, and they get a speedup from doing so.

So I believe it is worth disambiguating canaries between the two cases, because they are different security notions. The first (1) I would call single-target ECDLP (ST-ECDLP), and the second (2) I would call multi-target ECDLP (MT-ECDLP).

It's pretty clear that MT-ECDLP is easier to break, because attackers can make progress against more than one target concurrently, and breaking any one is sufficient to win the security game.

For example, say I sample 2 different messages m1​ and m2​, and compute ECDLP target points T1 = lift_x(SHA256(m1))​ and T2 = lift_x(SHA256(m2))​. Then if I sample a random scalar r​ and compute R = r*G​, I have two potential chances of success: R == T1​ OR R == T2​. I can scale up this advantage by generating more targets, T3​, T4​, ... and so on.

MT-ECDLP also admits a more efficient basic unit of computation in brute force attacks (including Grover) by using hashes instead of EC point multiplications. If I instead start by picking scalar t​ and fix the target point T = t*G​, then I can run a brute-force preimage search on SHA256 until I find m​ such that SHA256(m) == x(T)​. This can also be scaled up using a multi-target attack [1].

With ST-ECDLP, we have only a single fixed message m = G​, and so the attacker can't use those multi-target cheat codes. They can parallelize, use pollard-rho or Shor or other algorithms, but they have only a single target point that they must break to win the game.

The method Pieter suggested using for the canary construction is equivalent to single-target ECDLP.

I've heard others (e.g. Tadge in this thread) previously suggest using a script like OP_SHA256 OP_CHECKSIG​ as a canary, where any spend of such a script would trigger the canary. This would be multi-target ECDLP.

I'm not sure which is better. 

• ST-ECDLP is less likely to be triggered early or mistakenly, and is more tightly equivalent to ECDLP. 
  

• MT-ECDLP is more reflective of how real-world attackers behave on Bitcoin (e.g. with thousands-to-millions of public keys available to attack in parallel, and breaking even one is considered unacceptable).

I'm slightly leanings towards a construction like Pieter's, featuring ST-ECDLP, just because I'm not sure what other tricks could be used to potentially trigger MT-ECDLP classically or quantumly.

We could also engineer a compromise between the two, where we limit the number of targets. For example, define the game like this:

Given G​, find scalar a​​ and 32-bit integer i​​ such that a*G = lift_x(SHA256(G || i))​​.

Then the adversary can only attack against at most 2^32 unique target points, and those targets are fixed forever, for any adversary. This is an easier problem than ST-ECDLP, but harder than MT-ECDLP. Maybe call it limited multi-target ECDLP (LMT-ECDLP)?

regards,

conduition

[1]: First, generate a bunch of target points. Sample scalar t​ and compute T0 = t * G​, T1 = T0 + T0, and T2 = T1 + T1, and T3 = T2 + T2​, etc. Why double each point? point doubling is cheaper than addition or multiplication, and still covers the whole curve. Then we run a multi-target SHA256 preimage search over all targets [x(T0), x(T1), x(T2), x(T3), ...]​. If we have n​ targets and curve order N​, then each message hash has an n/N​​ chance of success. If we find a valid message m​, such that SHA256(m) == x(R_i)​ for some target index i​, then we have found T_i = t * 2**i * G = lift_x(SHA256(m))​.

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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f6d78499-d551-45ea-89b1-2b9cbd52f5can%40googlegroups.com.

[waxwing/ AdamISZ]

> A 192-bit curve i think should be reasonable as a canary, but consider this: If someone already has a QC that breaks 192-bit ECC, how long until they build one which breaks 256-bit ECC? A day, a week, a year? No way of knowing. If the delay is too long, users may see the canary as a false-positive, and migrate back to vulnerable addresses, and they might even be right. 192-bit canaries are vulnerable to classical attack with work approximately 2^96. We should bear in mind the possibility that such a canary could be activated possibly very early, well before Q-day, possibly even in the absence of any quantum computers.

Agreed that is unlikely a big delta, in the nature of these things (QCs), between 192 and 256. Including that it's obvious that going very much below 192 means classical attack and therefore bad idea. Which is why I said 192 and not sub 160. What's not obvious is that 192 is worse than 256 here. It may only give us a small amount of extra time, but it won't give us negative extra time. So the tradeoff is, presumably, whether the additional complexity (which is a bit tricky from what I recall [1], but there will definitely be experts out there who can clean it up) is worth it.

The idea of 'people will think it a false positive', disagree, I think the whole tripwire idea is likely a *bit* vulnerable to genpop misunderstanding as I said in my previous post, but this particular thing I don't see it: a 192 bit being broken is *very* likely to cause an appropriate level of panic.

> Anyone can find G = a * B​. Just generate a key and invert your secret key.

> P = a * G​

> G = a**-1 * P

> The hard part is then finding some b such that b*G = SHA256(G).

You slightly missed my point here, I think? The idea is that if you set up two sides that are both sample-able, you can birthday. Like, you keep sampling a on one side and b on the other. Build tables of both sides. Then all you have to do is check whether SHA2 of the LHS ever matches the RHS. This gives you a square root style speedup a la birthday attack. Contrast with if you just fix G, then keep searching for matches: no square root speedup. This is relevant because the hypothetical evil curve-generator who is trying to poison the future H=SHA2(G) has an easier time in doing so, than a future canary-solver who obviously cannot try different values of G :)

About your single-target vs multi-target distinction: interesting point is that Shor can target any specific dlog problem, right. So I do think the ST is the correct version of the problem? But actually I am quite unsure and unclear about those ST, MT, LMT distinctions you're making; specifically I mean, I am very unsure about how they differ in costs.

As for characterizing the problem, I think it's fair to say: if you assumed SHA2 was a proper random oracle then we have with SHA2(enc(G)), something that's very tightly equivalent to ECDLP, which is what we want. If we want to pay attention to the fact that SHA2 is an actual hash function and not an RO, then I think there's some statement like "assuming SHA2 has no structure "matching" secp256k1, then it's tightly equivalent to ECDLP on secp256k1" which is obviously horrendously vague, but would not be very easy to write down properly.

Another observation, probably it already exists up-thread: we obviously don't want to *literally* use BIP341's H on a 256 bit tripwire, because then a Shor-break directly steals a bunch of coins, so what should we use? Maybe SHA2(SHA2(enc(G)) ?

[1] https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-alert/2498/9

[conduition]

This is relevant because the hypothetical evil curve-generator who is trying to poison the future H=SHA2(G) has an easier time in doing so, than a future canary-solver who obviously cannot try different values of G :)

Ah sorry, I thought you were talking about canary solvers, didn't realize you were talking about curve designers. Agreed then, but still seems unlikely that G was chosen this way: https://bitcoin.stackexchange.com/questions/58784/how-were-the-secp256k1-base-point-coordinates-decided

If we have any doubt about that, we could tweak the hash function with some data that is newer than G but still unbiased, e.g. the hash of the genesis block, or the hash of the first block in which the canary goes live (idea credit: Tadge Dryja).

interesting point is that Shor can target any specific dlog problem, right. So I do think the ST is the correct version of the problem?

Yes, I believe so. I don't know of any way to batch Shor's algorithm in a multi-target attack that is any more efficient than a trivial one-by-one attack, so using MT-ECDLP seems like it only serves to makes classical attacks (or Grover's search) easier.

regards,

conduition

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fd947d7c-86fd-407c-98aa-0a63b8be28fan%40googlegroups.com.

[waxwing/ AdamISZ]

As if everything wasn't confusing enough, I also made one very notable error: What I was saying here:

> This is relevant because the hypothetical evil curve-generator who is trying to poison the future H=SHA2(G) has an easier time in doing so, than a future canary-solver who obviously cannot try different values of G :)

is, I'm pretty sure, not correct: the canary-solver only needs 2^128 work anyway (all the normal classical collision finding); it's not like he has to use pure brute force.

> If we have any doubt about that, we could tweak the hash function with some data that is newer than G but still unbiased, e.g. the hash of the genesis block, or the hash of the first block in which the canary goes live (idea credit: Tadge Dryja).

Seems plausible.

I guess two tracks of conversation here; I'm still genuinely curious what people think about 192 bit and whether we can do it practically, because, depending on how it plays out, it might buy very useful time. The delving thread was focused on distributed keygen and ZKP for the canary, but this is obviously way less trustless than NUMS, so perhaps that's the end of that, or perhaps there's something else clever I'm not aware of.

[conduition]

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 (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, 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

[waxwing/ AdamISZ]

(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 (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, 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> 

[Pieter Wuille]

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

[Erik Aronesty]

FWIW: there is a very long thread about this here: https://groups.google.com/g/bitcoindev/c/d7o74e-teNo/m/lLKjufQZAgAJ

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/td8wPWxRVg0rQIdP41uibTvWuIoCvGYpvfX022TaDurf-qu1TMm1TmWogw-JTs4C7Mt-97cvJCBW66z4g-Vc2fsSoo-Qxfm8Lcnd384Uink%3D%40wuille.net.

[conduition]

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.

[waxwing/ AdamISZ]

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.

[Pieter Wuille]

Hi, 

On Tuesday, August 18th, 2026 at 10:32 PM, conduition <condu...@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 <ekag...@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