Make pathological transactions with more than 2500 legacy signature operations non-standard

This proposal introduces a consensus limit on the number of signature operations (sigops) in transactions, setting a cap at 2500 sigops to mitigate the risk of denial-of-service (DoS) attacks by limiting the size and complexity of transactions. This measure, while aimed at enhancing network security, raises concerns regarding its impact on the scalability and flexibility of off-chain constructions, which are crucial for increasing transaction throughput on the network.

One highlighted technique involves the use of SIGHASH_SINGLE | ANYONECANPAY for the multi-signing of the first input in a second-stage transaction. This method allows for the addition of a legacy input without affecting the signature hash of the multi-signed "contract" input, even if the legacy input is altered in-flight. Such a strategy is beneficial for unilateral fee-bumping but poses challenges for multi-stage off-chain constructions due to commitments to specific transaction fields that may become malleable.

BIP54 specifically targets the limitation of executable sigops within transactions, excluding coinbase transactions, by counting the CHECKSIG and CHECKMULTISIG operations in both the input's scriptSig and the previous output's scriptPubKey. However, the proposal does not clearly address Segwit spends, which feature an empty scriptSig and contain witness programs without CHECKSIG operations, leading to questions about the accurate enforcement of this sigop limit. The ambiguity surrounding the definition of "legacy" inputs under BIP54 suggests a need for more precise specifications and clarity for developers and use-case designers, particularly in the context of large-scale Coinjoin transactions where the lack of script sanity verification could lead to invalid transactions, introducing new vectors for DoS attacks.

Furthermore, the discussion touches upon the essential role of Segwit inputs in maintaining transaction integrity against ID malleability risks, underscoring their significance in securing off-chain transactions. The conversation also explores the delicate balance required between imposing security measures and ensuring the network's capacity for growth and innovation, particularly in the realm of off-chain solutions. Potential avenues for circumventing the proposed sigop limits through the introduction of new opcodes or SegWit version scripts are considered, highlighting the ongoing dialogue among developers to carefully evaluate consensus rule changes against the network's long-term evolution.

Lastly, the selection of the 2500 sigop limit reflects a cautious approach to prevent invalidating any currently standard transactions under today's Bitcoin Core policy, acknowledging the theoretical possibility of creating a standard yet pathological transaction that would conflict with BIP54. This scenario underscores the importance of preparing for potential DoS attacks against miners who have not upgraded to accommodate BIP54, emphasizing the critical nature of these discussions in safeguarding the network's integrity while fostering future development.