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

The discussion revolves around the innovative utilization of large scriptPubKeys for script caching in Bitcoin, particularly in the context of complex smart contracts. The example given is a hypothetical future version of lightning with a 9,000 byte script required for every uncooperative close. In such a scenario, caching this script and invoking it by reference could be highly beneficial. This could potentially be achieved by incorporating the script into the consensus through a soft fork as a new opcode or more flexibly, by storing it in the existing database, namely the utxo set, and accessing it via its 36-bit txid/vout reference.

A suggestion is made to mitigate the permanent expansion of the utxo set by having such outputs expire after approximately 100,000 blocks and increasing the "weight" of creating these utxos tenfold. This approach is economically feasible only if the script is used around 40 times before expiration. The use of the utxo set for this purpose would simplify upgrades since it negates the need for rescanning blocks to populate a new script cache database upon upgrading to a node version that supports this feature.

However, concerns are raised regarding the significant increase in the utxo set bloat should a scriptPubKey be divided across multiple utxos. Each utxo not only includes the scriptPubKey but also additional data like a key, an amount, a coinbase flag, a height, and likely extra indexing data for efficient lookups. Splitting a 10kB script into multiple entries would considerably increase the overhead, thus making it a less effective approach. It's argued that this strategy doesn't offer any positive prevention against undesirable outcomes but rather exacerbates issues for other users.

Furthermore, the argument that breaking up data might mitigate regulatory scrutiny is dismissed. The analogy suggests that just as different formats for storing images do not exempt them from regulation, similarly segmented or structurally altered data would not circumvent regulatory oversight. This part of the discussion underscores the complexity of managing data within Bitcoin’s framework, hinting at the broader challenges of balancing innovation with practicality and regulatory compliance.