[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 mitigating these rifts by introducing new consensus rules for the OP_RETURN feature, which is used to embed metadata in transactions. The proposal suggests capping the OP_RETURN data size at 83 bytes and limiting it to one output per transaction to align with historical norms, thereby fostering consistency and stability across the network. This approach requires minimal code changes and seeks to address potential new attack vectors without siding with any specific faction within the debate. Majorian's initiative underscores the necessity of refocusing on Bitcoin's development future and healing community divisions by reverting to operational norms before the recent debates intensified.

The discussion also touches upon the broader implications of spam on the Bitcoin blockchain, highlighting that nearly half of the Unspent Transaction Outputs (UTXOs) are considered spam. This issue imposes significant costs on node operators due to the low cost of block space, which spammers exploit. A suggested solution involves implementing a soft fork to reduce block size and introduce UTXO-sharing opcodes like CHECKTEMPLATEVERIFY (CTV) to deter spammers by making spamming activities costlier and encouraging more efficient use of resources among legitimate users. However, the effectiveness of these measures is contingent on whether spammers opt for external data storage methods, which may render complete spam elimination unattainable.

Further complicating matters, the proposal to limit OP_RETURN outputs to 80 bytes per transaction has sparked concern among protocols requiring larger data publications. This limitation could force users towards alternative methods such as bare multisig outputs, increasing transaction fees and contributing to the UTXO set's growth. Such measures could inadvertently push users towards less efficient and transparent solutions, undermining progress made in addressing these issues through previous updates like Bitcoin Core 30.

A notable email exchange on the Bitcoin Development Mailing List involved Russell O'Connor discussing the relationship between Bitcoin and external protocols. The conversation questioned the criteria for accommodating these protocols and the implications of altering Bitcoin's codebase to support specific projects. These discussions emphasized the need for a careful balance between facilitating external projects and preserving Bitcoin's core principles and integrity.

Lastly, the debate highlighted the unintended consequences of restricting OP_RETURN transactions, drawing parallels with workarounds that lead to less efficient solutions and impose additional costs on the entire network. This situation underscores the importance of considering the broader impacts of protocol decisions and the collective burden they place on the Bitcoin ecosystem. Greg Maxwell, Melvin Carvalho, and Martin Habovštiak contributed to this dialogue, offering perspectives on policy, incentives, and the fundamental principles underpinning Bitcoin's design to prevent censorship and ensure the integrity of transactions following consensus rules.