Relax OP_RETURN standardness restrictions

In a recent discussion on the Bitcoin Development Mailing List, Greg Maxwell critiques the quality of debate surrounding a proposed change in Bitcoin's data embedding practices. One technically valid concern raised involves the OP_Return function, which uniquely allows for the embedding of long, uninterrupted, arbitrary messages directly into Bitcoin transactions. This poses a potential risk as such data could be stored on individuals' hard drives, potentially complicating future forensic analysis and even leading to false incriminations.

Maxwell acknowledges that malicious embedding of data is already possible and mentions existing countermeasures like the XOR "encryption" of block*.dat files by default in Bitcoin Core to mitigate risks associated with dumb virus detection software. However, he questions whether additional steps should be taken to convert existing block*.dat files to this scheme without necessitating re-downloads.

Furthermore, Maxwell revisits an earlier proposal of his aiming to set strict policy expectations for consensus changes concerning data publication on the blockchain. He suggests limiting allowable data types within the chain (e.g., hash digests, signatures) and requiring proof of authenticity for each data item. Such measures would make unauthorized data publication more expensive and cumbersome, though not impossible. This approach anticipates significant adjustments across the Bitcoin ecosystem, including modifications to address standards to accommodate these new verification requirements.

There's an acknowledgment of the challenges posed by this proposal, notably the complication it introduces for protocol upgrades and the burden it places on the community to adapt. Maxwell points out that while this strategy could deter the casual embedding of data, determined parties could still manipulate transaction elements to bypass these restrictions, albeit at a higher cost. The proposal also contemplates mechanisms to mitigate the impact on future protocol upgrades, such as allowing exceptions for transactions and script types with unknown version numbers and possibly introducing a miner signaling process for accepting new versions. This nuanced take illustrates the complexities involved in balancing innovation and security within the Bitcoin protocol, highlighting the need for thoughtful consideration of any consensus changes.