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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/A54QKCjvV0Tnk26mHFZrbAKPHdYh6Ol1XWTetB3y1skuSaoLtBZnvNlYD2hSqQtp6oYt85rqvK4w-JMsDJOm3nPrYgkN94E9jlxxCPZsKZw%3D%40wuille.net.
