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

In a recent discussion on the Bitcoin Development Mailing List, several proposals were put forward to address concerns related to the size and efficiency of transactions within the Bitcoin network. A key suggestion involved imposing new limits on components of transactions to ensure they occupy less space, thereby reducing the burden on nodes. Specifically, it was proposed to cap new scriptPubKeys at 83 bytes or less, with a preference for even smaller sizes like 34 bytes. This measure is aimed at minimizing the storage requirements for Unspent Transaction Outputs (UTXOs), which represent a significant overhead for network nodes. The rationale behind this stringent limit is that larger data elements can be hashed instead, with the caveat that a broken SHA256 algorithm would necessitate a hard fork of the network.

Further restrictions were suggested for script data pushes, limiting them to 256 bytes except in cases involving BIP16 redeem scripts. Additionally, undefined witness versions, including taproot annexes and OP_SUCCESS* operations, would be declared invalid unless legitimized through a soft fork. This approach intends to prevent misuse while maintaining network flexibility for future upgrades. The taproot control block might also see its size limited to 257 bytes, drastically reducing the maximum number of scripts it can contain from the current excessively high figures.

The use of OP_IF within Tapscript was another target for potential restriction, as its utility is questioned within the context of taproot's design, where it has been prone to abuse. These proposed changes could be implemented as part of a temporary soft fork that would automatically expire after a set period. This strategy is designed to provide a stopgap solution, allowing time for the development of more permanent fixes and the assessment of their real-world impacts without permanently foreclosing on future enhancements that rely on upgradable mechanisms.

An alternative approach to directly limiting transaction component sizes would involve adjusting the block weight metric to allow for exceeding these limits at a higher byte-per-weight cost. This method could include a temporary adjustment, potentially incorporating a rolling window for adjustments, to accommodate the evolving needs of the network. Another innovative proposal suggests modulating transaction fees based on coin-days-destroyed or coin-age, penalizing rapid transaction turnover more heavily than less frequent settlements to discourage UTXO bloat while considering the implications for network health.

The conversation indicates openness to community feedback and collaboration on developing a Bitcoin Improvement Proposal (BIP) and corresponding code to implement these changes, should there be sufficient support within the community.