Relax OP_RETURN standardness restrictions

In the realm of Bitcoin and its blockchain technology, there's an ongoing discussion about how to handle the presence of low-value spam transactions. These transactions often fill excess block space, a phenomenon seen as both inevitable and manageable within the permissionless nature of Bitcoin's system. The crux of the issue lies in the transaction fees, which are currently under 3 satoshis per virtual byte (sat/vb). This low fee threshold makes it financially viable for spammers to continue their activities until they recognize the futility in terms of cost versus gain.

The debate extends to the methods used by these spammers, who employ various techniques to encode data into transactions. These encoding practices range from simple to complex, with the more sophisticated methods being undetectable to third parties. Attempts to filter out or block this kind of spam are viewed as impractical. Given the open-ended structure of Bitcoin's blockchain, any effort to create filters for detecting encoded data is seen as a Sisyphean task—potentially lucrative for those paid to develop such solutions but ultimately futile in achieving a spam-free environment.

Historical instances of spam attacks on the Bitcoin network highlight the severity of the issue. Notable events in 2015, such as the July flood attack and subsequent plans by entities like Coinwallet to deliberately congest the network, showcase the disruptive potential of spam. These attacks were particularly damaging because many wallets at the time did not adjust fees based on the transaction's size (measured in vbytes) nor did they support replace-by-fee options, resulting in transactions languishing in the mempool for extended periods.

One proposed solution to mitigate the impact of low-value spam involves preventing these types of transactions from entering the blockchain. However, this approach, potentially involving a temporary reduction in block size, raises concerns about its desirability and feasibility within the ethos of Bitcoin's design. Such measures would fundamentally alter how transactions are managed and could have far-reaching implications for the network's operation and accessibility.

For further reading on the subject and historical context, sources such as the Bitcoin Wiki's article on the July 2015 flood attack, International Business Times' coverage of Coinwallet's planned dust attack, and academic analysis of Bitcoin's resilience to stress testing (Stressing Out Bitcoin) provide valuable insights.