Relax OP_RETURN standardness restrictions

The intricacies of software changes, especially in a complex ecosystem like Bitcoin's, highlight the challenge of predicting every potential impact on users' systems. The recent discussion brought forward by Boris Nagaev underscores this point, emphasizing the difficulty in foreseeing how each user's unique infrastructure might interact with new updates. For instance, some users operate on devices with limited resources, necessitating optimizations such as filtering out specific types of transactions that do not use OP_RETURN to manage their mempool efficiently. These optimizations are critical for maintaining operational stability without overburdening their system's capacity.

Nagaev further illustrates the potential issues that could arise from abrupt changes, using the example of systems that rely on pulling mempool transactions via RPC from Bitcoin Core. These systems may have built assumptions around OP_RETURN outputs, such as allocating static buffers, which could lead to crashes if an output is larger than expected. Addressing these types of issues can be time-consuming and challenging, pointing to the necessity of providing a grace period for operators to adjust their systems accordingly.

The argument for keeping certain options available, even if their usage is discouraged, revolves around offering flexibility and preventing disruption. By leaving settings in place for an additional release cycle, developers and operators are afforded the opportunity to update their systems gradually, mitigating the risk of unforeseen complications. This approach acknowledges the diversity of use cases and configurations within the Bitcoin network, opting for a more cautious and inclusive strategy towards development changes.