Bitcoin Core developers emphasized the freedom users have to define how they interact with Bitcoin, stressing that this autonomy safeguards the network. In a post published on June 6, 31 signers emphasized that Core prevents automatic updates, ensuring that no single entity imposes changes on users and reinforcing decentralization. 

This announcement, which emphasizes that “the freedom to run any software is the network's primary protection against coercion,” comes as the Bitcoin community grapples with a profound debate about how the network should be used: to transmit monetary value or as a storage system for arbitrary data. 

The opposing camp, critical of the Bitcoin Core announcement, considers non-monetary uses of Bitcoin, such as registrations, to be “spam” and an attack on the network's original purpose: to be decentralized, hard money.

The Core signatories' approach

The statement, backed by developers Antoine Poinsot, Gloria Zhao, and Pieter Wuille, details the responsibility of Bitcoin Core, the most widely used Bitcoin client, to optimize the software to efficiently validate and relay transactions and blocks.  

According to the signers of the message, this client includes policies to prevent denial of service (DoS) attacks and facilitate rapid transaction propagation, which aims to reduce unfair advantages for large miners and encourages decentralization.  

However, developers acknowledge that attempting to block viable non-monetary transactions such as registrations forces users to use alternative channels, weakening Bitcoin's censorship resistance. 

Thus, Bitcoin Core, amidst much debate, accepts as an inevitable reality the non-monetary uses of the network, such as the recording of non-financial data, and recognizes that Bitcoin, as a censorship-resistant system, will be used for a variety of purposes , even if not all users agree.

Update on the current Bitcoin Core debate 

Three days after the recent Bitcoin Core release, Gloria Zhao, one of the lead maintainers of the Bitcoin code, announced in a post on X on June 9 that the next version of the Core client (v.30), scheduled for October 2025, will contain new policies to handle arbitrary limits on OP_RETURN outputs. 

This change means that by default the software will issue warnings when using transactions involving data such as OP_RETURN, keeping the 83-byte limit as a reference, but without imposing a universal increase, leaving the decision to accept more permissive settings to node operators. 

According to Zhao, this update will modify default settings to discourage the use of such transactions, although related adjustment options will remain available with a warning recommending avoiding them, reflecting a flexible but cautious approach. 

Zhao's statement aligns with the closure of pull request (PR) #32359, which proposed removing arbitrary limits on OP_RETURN outputs after a two-year discussion, reopened two months ago with new information. Thus, Core version 30 will not implement the complete removal of the 83-byte limit as a default policy, but will allow users to opt for more permissive settings. 

Thus, a potential increase in the byte limit allowed for OP_RETURN transactions could generate mixed reactions, given that a portion of the Bitcoin community strongly opposes moving Bitcoin away from its purely monetary use. 

The first responses have already arrived 

The proposed increase in the OP_RETURN limit has sparked criticism from prominent members of the Bitcoin community. Self-proclaimed Bitcoin expert Jimmy Song stated that “OP_RETURN outputs larger than 83 bytes will increase significantly, UTXO bloat will continue to worsen, and there will be more garbage on the chain,” expressing concern about the impact on the network.  

For his part, Bitcoin Mechanics, an educator who works for OCEAN Pool and is a promoter of Bitcoin Knots, backed up this stance, stating: “This is correct. What Core has done is completely inconsistent. Removing a spam filter in the hopes that spammers will switch to OP_RETURN without any guarantees is pure wishful thinking.” 

Furthermore, Mechanics, who also believes that a “bug” in the Taproot update allowed for the proliferation of registrations, stated that "Ignoring the fact that having to remove a filter is an acknowledgment that filters work and could have been used to prevent harmful activity in the first place," reflecting a strong distrust of the decisions of the Core developers.