Bitcoin Soft Fork Controversy! BIP-444 Data Restrictions Spark Review War

Bitcoin Improvement Proposal 444 (BIP-444) calls for developers to limit the amount of arbitrary data that can be attached to network transactions, sparking intense debate within the community. The proposal was released last week, shortly after the Bitcoin Core v30 update, which effectively removed the data limit for adding to typical Bitcoin transactions using the OP_RETURN function.

Core Technical Limitations of BIP-444 Proposal

(Source: Stacker News)

The proposal was written by “Dathon Ohm,” who joined GitHub and X just a few days before submitting the proposal and has no apparent Bitcoin development experience. Although the author's background raises questions, the proposal directly addresses the data bloat issue currently facing Bitcoin. According to the proposal's terms, OP_RETURN outputs will be limited to 83 bytes, and most other scriptPubKeys will be limited to 34 bytes, effectively preventing the inclusion of large scripts or data blocks in outputs.

The proposal will also limit the size of individual data pushes, rendering currently unused or undefined script versions invalid to prevent circumvention of the limits. More critically, the proposal will restrict the size of the Merkle tree embedded in Taproot outputs and prohibit OP_IF in Tapscript, thereby directly terminating the Ordinals inscription method. Ordinals is a technology for creating NFTs and tokens on Bitcoin, which has sparked significant controversy in recent years and is regarded by critics as “spam.”

The main technical limitations of BIP-444:

OP_RETURN Limit: From unlimited return to 83 bytes

scriptPubKey Limit: Most types are limited to 34 bytes

Taproot Merkle Tree Limitations: Prevent large data embedding

Prohibit Tapscript OP_IF: Directly terminate the Ordinals engraving method.

Invalidate Undefined Script Versions: Block Potential Bypass Paths

These changes will lead to a soft fork, and previously valid transactions will become invalid. However, the proposal requests that this change be temporary, lasting about a year. This period will provide Bitcoin developers with sufficient time to assess and implement alternative methods for arbitrary data storage on the blockchain. The proposal states: “The explicit temporality of the soft fork further emphasizes that it is a targeted intervention aimed at alleviating a specific crisis, rather than a commitment or proposal for new development directions.”

The concept of a “temporary soft fork” is quite rare in the history of Bitcoin. Most soft forks are permanent technical upgrades, such as SegWit or Taproot. A temporary soft fork means that these restrictions may be removed or replaced by a more robust long-term solution after about a year. This design attempts to strike a balance between addressing the immediate crisis and avoiding hasty decisions.

Supporters' Concerns: Legal Risks of Illegal Content

The core argument supporting BIP-444 is to protect node operators from potential legal liabilities. After the removal of the OP_RETURN data limit in Bitcoin Core v30 update, anyone can pay the appropriate fee to upload arbitrary-sized data to the Bitcoin blockchain. This raises a serious concern: illegal content may be permanently recorded on the immutable blockchain.

The proposal states: “If the blockchain contains content that is illegally held or distributed, node operators will be forced to choose between violating the law (or going against their conscience) and shutting down their nodes. This unacceptable dilemma directly undermines the incentives for validation, leading to inevitable centralization and posing an existential threat to the security model of Bitcoin.”

This concern is not entirely fabricated. In 2018, German researchers discovered possible links to illegal content on the Bitcoin blockchain. Although this content is not directly stored on the chain, its existence has sparked discussions about the legal responsibilities of node operators. In certain jurisdictions, even passive storage of data containing illegal content may violate the law.

The decentralized security model of Bitcoin relies on tens of thousands of independent nodes worldwide. If node operators shut down their nodes due to concerns about legal liability, the level of decentralization of the network will decrease, potentially leading to centralization risks. This centralization does not stem from technical flaws but from legal and ethical pressures, making the issue even more complicated.

The Bitcoin developer Luke Dashjr, who has long been known for opposing Ordinals, expressed support for the proposal and pointed out on X that the proposal “is progressing well with no technical objections.” Dashjr wrote on X: “This is not an ideal solution; it is just to buy time to design a long-term solution that is good enough and super simple.” Dashjr also denied in other posts that he is the author of the proposal.

Critics of the Opponents: The Dangerous Precedent of Agreement-level Review

Critics of the proposal generally believe that arbitrary data in Bitcoin has existed since the network's genesis block, and preventing the addition of arbitrary data is tantamount to censorship, violating Bitcoin's core principle of permissionless use. User Leonidas, a well-known figure in the Ordinals community, claimed in September that miners and mining pools accounting for more than half of Bitcoin's hash rate told him they would accept any valid Bitcoin transaction that conforms to the consensus, along with appropriate fees.

Leonidas wrote: “Normalizing the censorship of JPEG or memecoin transactions is no different in substance from normalizing the censorship of certain currency transactions by nation-states. Both would create very dangerous precedents.” This argument touches on the core of Bitcoin philosophy: censorship-resistance. If Bitcoin developers can restrict certain types of transactions because they dislike certain uses, can this power also be used to censor other types of transactions?

Jameson Lopp, co-founder and Chief Security Officer of the Bitcoin security storage company Casa, offered some critical comments on the proposal, pointing out that it does not define what issues exist legally or ethically, and added that legal experts have differing opinions on the responsibilities that node operators will face. In a comment, Lopp wrote: “Running a node means you agree to the network's consensus rules. If you disagree, you can simply not run a node.”

Lopp's criticism points to a core flaw in the proposal: it assumes the existence of a universally accepted definition of “illegal content,” but in reality, this definition varies greatly across different jurisdictions. Political speech that is legal in one country may be considered illegal in another. If Bitcoin begins to restrict transactions based on content legality, who will decide what is legal?

Moreover, the slow adoption rate of the Bitcoin Core v30 update is also noteworthy. According to Bitnodes data, about 6.3% of accessible nodes are using the software. This means that the vast majority of nodes have not yet upgraded to the version that removes the OP_RETURN limit. In this situation, is pushing for a soft fork too hasty?

The proposal has not yet been distributed to the Bitcoin development mailing list, which is a necessary step for the BIP draft to gather more feedback and move towards acceptance. However, the proposal has already sparked a series of comments and debates on X and other forums, showing that there are profound divisions within the Bitcoin community on this issue. The ultimate outcome of this debate will significantly impact the future development direction of Bitcoin.