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

In a recent discussion on the Bitcoin Development Mailing List, concerns were raised about the potential inefficiencies that could arise if users need to revert from a new transaction output type back to P2TR due to CRQC-protection goals. This change, if implemented on a large scale, could lead to significant chain capacity problems. There is an ongoing debate about whether it would be better to add a new version of P2TR or another similar solution that remains in a pre-lockdown state, maintaining flexibility while aiming for enhanced security.

The conversation also highlighted a critical viewpoint regarding the disabling of certain functionalities within new output types to uphold security objectives. Specifically, any execution of operations involving elliptic curve (EC) public keys, such as taproot key path spending and OP_CHECK* opcodes with non-empty signatures, should render a transaction invalid. This approach is aimed at preventing the misuse of public keys and ensuring that disabling measures like Tripwire, Miner Lockdown, or potential future softforks are effective across all uses.

Furthermore, there was a proposal to address hybrid signature schemes distinctly at the opcode level rather than through script modifications. The suggested introduction of an OP_CHECKHYBRIDECSQISIGN opcode reflects a preference for making security decisions a matter of consensus among network participants, rather than leaving them to individual discretion. This method would also facilitate the separation of post-quantum cryptography (PQC) scripts from EC scripts at a structural level, reducing the risk associated with mixing these mechanisms in a single script execution, which could lead to errors post-EC-disabling.

Overall, the discussions underline a cautious approach towards integrating cryptographic technologies that rely on assumptions not yet fully trusted within the Bitcoin community. The focus remains on exploring cryptographic methods, particularly those based on hash functions, which require fewer assumptions and may not necessitate hybridization with existing EC techniques.