[BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.

The exploration of mitigating Denial of Service (DoS) blocks within the context of Bitcoin Improvement Proposal 54 (BIP54) has led to significant discussions among developers, particularly concerning the limitations of scriptPubKey sizes. Initially, the idea to limit these sizes was seen as a direct method to reduce vulnerabilities. However, concerns were raised about its effectiveness and potential negative impacts, specifically regarding what has been termed the "confiscatory surface." These concerns were notably articulated by Russell O'Connor, who critiqued an earlier proposal by Matt Corallo, leading to further examination of how best to address these issues without inadvertently creating new problems.

One of the core objectives of BIP54 was to circumvent these confiscatory risks while still implementing meaningful protections against DoS attacks. Discussions around limiting the size of spent scriptPubKeys emerged as a potential solution. This approach aimed at reducing the confiscatory surface, thereby addressing the critical feedback received. Despite this, the decision was ultimately made not to include such measures in BIP54. The rationale behind this decision centered on two main factors: the complexity these additional measures would introduce and the law of diminishing returns with respect to their effectiveness versus their impact on the confiscatory surface.

The finalized BIP54 includes a significant limitation on sigops, which serves to prevent attackers from disproportionately stalling the network and miners from inhibiting their competition, all while minimizing the confiscatory surface. The conclusion drawn from these deliberations suggests that while further mitigations could technically reduce worst-case validation times, the actual benefits of such reductions, when weighed against the increased confiscatory surface, might not justify their implementation.

Furthermore, the discussion touches upon future possibilities for enhancing network security and efficiency through proposed changes in a "cleanup v2" update. This update would potentially include a consensus-enforced maximum transaction size, a suggestion supported by information available on DelvingBitcoin.org. Although there is no immediate expectation for the realization of this cleanup version, its documentation and consideration are deemed valuable for ongoing development discussions.

Additionally, the email mentions a willingness to revisit and explore alternative mitigation strategies on a semi-private forum, indicating an open door for continued dialogue and development in the face of evolving challenges within the Bitcoin ecosystem. This reflects a broader commitment to iterative improvement and community engagement in the process of enhancing Bitcoin's resilience and operational integrity.