From: Pieter Wuille <bitcoin-dev@wuille.net>
To: Nagaev Boris <bnagaev@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Giving teeth to expected EC disabling: P2XX(-T)(-ML)
Date: Fri, 26 Jun 2026 14:10:39 +0000 [thread overview]
Message-ID: <A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw=@wuille.net> (raw)
In-Reply-To: <CAFC_Vt7OfZ-rztFP5D5ycpxe3ZQOJJbY5cHgEk73OMYAmnDBjQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2026-06-26 14:14 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 [this message]
2026-06-26 18:20 ` 'conduition' via Bitcoin Development Mailing List
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='A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw=@wuille.net' \
--to=bitcoin-dev@wuille.net \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox