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

In a recent discussion within the Bitcoin development community, Greg Maxwell highlighted the robustness of Bitcoin's script extensibility, especially in regards to future cryptographic schemes. This was attributed to the design foresight of incorporating variable-length fields within the annex of proposals, which allows for a wide range of adaptations without compromising the system's integrity. However, Maxwell introduced a novel concept aimed at addressing the issue of spam on the blockchain—specifically concerning "fat" scriptpubkeys that congest network resources.

Maxwell proposed a congestion control mechanism that operates by setting limits on the number of occurrences of a certain type of scriptpubkey during a given block period. This approach involves defining a block period (P), a type of scriptpubkey (T), and a threshold limit (L) for how many times T can appear within P. Should the number of T exceed L within the designated period, any additional transactions involving T scriptpubkey would either invalidate the block or incur a weight penalty for the transaction. This method aims to automatically regulate the blockchain's capacity and prevent the abuse of block space without necessitating a social consensus to define what constitutes "spam."

Moreover, Maxwell touched upon the broader issue of qualitative spam, referring to Claude Shannon's theory of communication to suggest that reducing the size of data payloads might be an effective measure. This acknowledges the challenge of addressing spam through linguistic or non-mathematical means, emphasizing the complexity of distinguishing qualitative spam within the blockchain context.

Lastly, despite recognizing the potential benefits of congestion control and other measures to mitigate spam, Maxwell expressed a preference for prioritizing solutions to more pressing issues within the Bitcoin network, such as the timewarp bug and vulnerabilities associated with old redeem scripts. The discourse suggests a cautious approach towards implementing drastic consensus changes, especially those aimed at spam mitigation, which may inadvertently harm the network.