Relax OP_RETURN standardness restrictions

In a recent exchange among Bitcoin developers, a discussion unfolds around the challenges of mitigating spam on the blockchain and enhancing the network's efficiency. The core of this debate revolves around how to best encode data within Bitcoin transactions without exacerbating existing issues like UTXO set bloating or incentivizing alternative relay networks that could fragment the mempool and potentially centralize the network.

A proposal had been made to whitelist certain script forms for transaction encoding; however, this approach is critiqued for its inability to address the fundamental issue of spam. The critique points out that regardless of the method used to encode data (be it through whitelisting script forms or utilizing unspendable public keys as suggested in the Citrea white paper), the system remains vulnerable. This vulnerability arises from the ease with which individuals can manipulate parts of a transaction, such as grinding the first N bits of every public key or encoding information in the nonce, at trivial costs, particularly for bridge systems. Furthermore, there's an argument that systems designed around creating 'art' through scarcity might actually benefit from such constraints, thus complicating the spam issue further.

The conversation also touches upon previous proposals and their limitations. It's indicated that relying solely on standardness rules, which go against financial incentives, isn't effective. This brings to light the necessity for consensus changes as the only viable solution to these challenges, albeit acknowledging the slow and cumbersome process of designing, implementing, and deploying such changes within the Bitcoin network.

In addressing potential solutions, the dialogue critiques the idea of increasing the OP_RETURN limit. Although seen as less damaging than alternatives like UTXO set bloating with fake public keys or enabling large-scale bypassing of the default mempool settings, increasing the limit is not without its issues. Specifically, concerns are raised about how such an increase might lead to compact block relay failures due to mempool fragmentation and potentially drive the network towards centralization. The discussion highlights how custom-but-public relay networks, though not contributing directly to centralization, might still cause significant fragmentation within the mempool.

Lastly, the email points out a lack of clarity regarding the specific problem being addressed and the nature of the "damage" being referred to. It even questions the feasibility of proposing a decrease in block size as a solution, despite anticipating minimal support for such a measure. This exchange underscores the complexities involved in making protocol-level adjustments to Bitcoin, where the balancing act between maintaining decentralization, ensuring efficiency, and preventing spam requires careful consideration of various technical and community-driven factors.