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

The correspondence from Antoine delves into a detailed examination of concerns surrounding the implementation of BIP54, specifically focusing on its implications for signature operations (sigops) within Bitcoin transactions. It is evident from the message that there is skepticism regarding the potential issues posed by the proposed changes under specific threat models. Antoine argues that the perceived problem, which hinges on the sigop limits introduced by BIP54 versus those already existing, may not be as significant as initially thought.

Antoine clarifies that the specifications outlined in BIP54 are designed with the implementer in mind, specifically instructing on counting sigops in both the input scriptSig and the previous output's scriptPubKey. This method of accounting for sigops predates the introduction of Segwit, which mandates an empty scriptSig and restricts the scriptPubKey to pushonly operations. From this perspective, any transaction conforming to these rules would likely encounter the standardness size limit before it would reach the sigop limit imposed by BIP54.

Moreover, Antoine points out that only transactions intentionally crafted to inflate their validation cost—termed pathological transactions—would realistically approach the sigop limit while still adhering to today’s Core policy standards. This suggests that the practical impact of BIP54’s sigop limit on normal Bitcoin transactions might be minimal. For further details, Antoine references the BIP54 documentation available at GitHub, implying that a thorough understanding of the proposal requires engagement with the technical specifics as presented in the document.