Relax OP_RETURN standardness restrictions

In the ongoing discourse within the Bitcoin Development Mailing List, Greg Maxwell presents a nuanced perspective on the debate regarding the modification of the OP_RETURN output size limits. A key point in the argument is the critique against completely removing the limit, suggesting that such an action might lead to unintended consequences. The current standardness rules, although not entirely effective in deterring unwanted Bitcoin usage, play a crucial role in temporarily inconveniencing users until they find alternative means for transaction relay or use competing services. This mechanism has been somewhat successful in curbing the initial bootstrapping of demand for non-standard transactions.

The discussion gains depth with the mention of inscriptions and how their popularity might have been stifled had there been stringent limits from the beginning. Such examples highlight the delicate balance between too strict limitations and overly lenient policies that could foster unwarranted uses of the network. The conversation further unfolds with the introduction of Citrea's BitVM bridge design, which underscores the practical implications of data storage within transaction outputs. This particular use case exemplifies the need for a forward-thinking approach to standardness rules, ensuring they are flexible enough to accommodate future innovations while being mindful of the potential negative externalities.

Maxwell argues for a rational middle path in setting new limits, advocating for an increase in the size of OP_RETURN outputs but against the complete lifting of restrictions. Proposing a more conservative cap of 1 KB instead of the implicit ~100 KB, the rationale is to maintain a level of control that can be adjusted as necessary without permanently opening the floodgates to all possible uses, some of which might impose significant costs on node operators or exploit the system in unforeseen ways. The emphasis on forward compatibility with unknown future use cases suggests a careful consideration of how changes today might impact the network's evolution. This balanced approach reflects a broader philosophy within blockchain development: the need for flexibility in technological standards coupled with a cautious eye on long-term sustainability and security.