From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Nagaev Boris <bnagaev@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Fri, 26 Jun 2026 18:20:26 +0000 [thread overview]
Message-ID: <Jj-Ozzq4OMo2XaP_Drftu_n7gmEHWC_Dw2bToW9hI8vId-BN3y4hmQSaHh5JY1xTonTyBWKa17vzNH4GMYTkM-CiFw5ZNwRFATdc3OE_lLk=@proton.me> (raw)
In-Reply-To: <A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw=@wuille.net>
[-- Attachment #1.1: Type: text/plain, Size: 10903 bytes --]
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
On Friday, June 26th, 2026 at 8:14 AM, Pieter Wuille <bitcoin-dev@wuille.net> wrote:
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw%3D%40wuille.net.
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Jj-Ozzq4OMo2XaP_Drftu_n7gmEHWC_Dw2bToW9hI8vId-BN3y4hmQSaHh5JY1xTonTyBWKa17vzNH4GMYTkM-CiFw5ZNwRFATdc3OE_lLk%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2026-06-26 18:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 17:42 [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML) Pieter Wuille
2026-06-26 3:40 ` Nagaev Boris
2026-06-26 11:06 ` Sjors Provoost
2026-06-26 14:10 ` Pieter Wuille
2026-06-26 18:20 ` 'conduition' via Bitcoin Development Mailing List [this message]
2026-06-27 4:33 ` Anthony Towns
2026-06-29 2:17 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Jj-Ozzq4OMo2XaP_Drftu_n7gmEHWC_Dw2bToW9hI8vId-BN3y4hmQSaHh5JY1xTonTyBWKa17vzNH4GMYTkM-CiFw5ZNwRFATdc3OE_lLk=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=bitcoin-dev@wuille.net \
--cc=bnagaev@gmail.com \
--cc=conduition@proton.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox