Relax OP_RETURN standardness restrictions

In a recent discussion among Bitcoin developers, the topic of OP_RETURN restrictions has been revisited with varying perspectives on its potential modification. The conversation highlights the evolving landscape of Bitcoin mining and development, underscoring the infancy of the mining industry and the rapid pace at which companies can rise or fall within it. Drawing from historical parallels in the personal computer industry, the unpredictability of company prominence and user behavior is emphasized, suggesting that flexibility and optionality should be key components in future development strategies. This perspective advocates for maintaining current policies on OP_RETURN to ensure users have as many choices as possible, reflecting a broader principle of designing for maximum configurability.

The debate over OP_RETURN restrictions further delves into the technical implications of altering these limits. It's noted that major miners have already found ways around existing policy limits, which only serve to complicate software adjustments and encourage private submissions, thereby questioning the utility of enforcing stringent restrictions. The argument against tightening OP_RETURN limits is supported by pointing out the inefficacy of Bitcoin Core's standardness rules in deterring unwanted usage amidst sustained economic demand. Instead, such limitations may inadvertently facilitate the emergence of alternate transaction relay networks or direct submission services, potentially imposing greater costs on node operators than simple OP_RETURN outputs would.

Moreover, the discussion acknowledges the challenge of predicting future use cases and the importance of ensuring forward compatibility. By examining specific examples like Citrea's BitVM bridge design, the necessity of a more nuanced approach to OP_RETURN limits becomes evident. While there's agreement on the need to relax these limits, completely removing them is deemed unnecessary. A suggested compromise involves setting a conservative new limit, such as 1 KB, rather than the implicit ~100 KB, balancing the desire for flexibility with the need to prevent potential negative externalities associated with larger output sizes. This cautious stance reflects a broader consensus within the Bitcoin development community to prioritize conservative changes that accommodate future growth and innovation without compromising the network’s integrity or functionality.