[BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies

Majorian, a community member since 2017, has proposed a soft fork aimed at resolving this controversy by implementing new consensus rules. These include limiting OP_RETURN data size to 83 bytes and restricting it to one output per transaction. This proposal is designed to maintain network consistency and stability by adhering to historical norms, thereby addressing concerns over potential new attack vectors without taking sides in the broader argument about Bitcoin's intended functionalities. Majorian's initiative is centered around simplicity and minimal code changes, with the goal of fostering community healing and refocusing on future development.

This discussion extends to the broader issue of spam on the blockchain, where nearly half of all Unspent Transaction Outputs (UTXOs) are considered spam, largely due to the low cost of block space. Proposals have been made to combat this through measures like reducing block size and introducing UTXO-sharing opcodes, such as CHECKTEMPLATEVERIFY (CTV), which could deter spammers by increasing their operational costs and promoting more efficient resource use among legitimate users. However, there's an acknowledgment that completely eliminating spam might be impossible if spammers choose to store data externally and use Bitcoin merely as a representation of ownership.

Another contentious point revolves around the limitations being placed on OP_RETURN outputs, specifically the proposal to cap these at 80 bytes and restrict them to one per transaction. This move has been criticized for potentially forcing users towards alternative, less efficient methods of data publication, such as bare multisig outputs, which could lead to higher transaction fees and an increase in the unspendable UTXO set. Such a shift poses challenges not only in terms of distinguishing between legitimate uses and spam but also in maintaining the blockchain's operational integrity and user experience. Critics argue that instead of solving the intended problems, these restrictions might push users towards solutions that, while uncensorable, could exacerbate issues related to block reconstruction quality and fee estimation.

The conversation is further complicated by questions raised by Russell O'Connor regarding the necessity of accommodating certain protocols that exceed the proposed OP_RETURN limits and the implications of forcing protocol designers to find workarounds. The discussion highlights concerns over the external costs imposed by these workarounds, especially the impact on Bitcoin node operators worldwide due to the unprunable UTXO bloat caused by alternative data publication methods like bare multisigs. The collective cost to the network and its operators is deemed significant, emphasizing the need for solutions that consider the wider ramifications of any changes to Bitcoin's codebase.