BIP-444: the temporary soft fork dividing developers and the…

The proposal to limit arbitrary data on Bitcoin sparks debate over censorship and network security.

The Bitcoin community finds itself at the center of a debate surrounding Bitcoin Improvement Proposal 444 (BIP-444) — a proposal aiming to implement a temporary soft fork to limit the amount of arbitrary data that can be included in timechain transactions.

The controversy emerged following the release of Bitcoin Core v30 this month, which removed the maximum data size previously allowed via OP_RETURN in standard transactions. Despite the discussion that preceded the launch, adoption of the new software has been slow according to Bitnodes data: currently, 6.5% of reachable nodes are running version 30.

The BIP-444 proposal, published on October 24, stems from concerns among some Bitcoin community members about potential legal risks for node operators. The main fear is that illegal material – such as child sexual abuse content – could be uploaded to the timechain, creating legal liabilities for anyone running a full node.

“If the blockchain contains content that is illegal to possess or distribute, node operators are forced to choose between violating the law (or their conscience) or shutting down their node,” the proposal document states. “This unacceptable dilemma directly undermines the incentive to validate, leading to inevitable centralization and posing an existential threat to Bitcoin’s security model,” it reads.

On line 261, the document declares that “there is a moral and legal impediment to any attempt to reject this soft fork.” Then, from line 270 to 272, it continues:

“Rejecting this soft fork may subject you to legal or moral consequences, or could result in you splitting off to a new altcoin like Bcash. However, strictly speaking, you are free to choose.”

According to the terms of the proposal, the soft fork would implement several technical restrictions:

• OP_RETURN outputs would be limited to 83 bytes;
• most other scriptPubKeys would be limited to 34 bytes;
• a limit of 256 bytes would be imposed on individual data push sizes;
• unused or undefined script versions would be invalidated;
• a maximum size would be introduced for Merkle trees embedded in Taproot outputs;
• OP_IF would be banned within Tapscript, effectively removing the Ordinals inscription method.

These changes would result in a soft fork where transactions previously considered valid would become invalid. However, the proposal specifies that this modification would be temporary, lasting approximately one year. This period would allow developers to evaluate and implement alternative approaches for managing arbitrary data on the timechain.

The proposal was written by “Dathon Ohm”, an account created on GitHub and X just a few days before publication, with no apparent prior history in Bitcoin development.

Luke Dashjr, a well-known Bitcoin developer and outspoken critic of Ordinals, expressed support for the proposal, stating on X that it is “already on track with no technical objections.” Dashjr noted that “it isn’t intended to be an ideal solution, only good enough and super simple to buy time to design a long term solution.”

Critics of the proposal argue that arbitrary data has existed on Bitcoin since the genesis block, and that restricting the methods used to embed arbitrary data amounts to censorship, violating Bitcoin’s fundamental principle of permissionless use.

Last September, Leonidas, a prominent figure in the Ordinals community, stated that miners and mining pools representing over half of the network’s hash rate had confirmed they would accept any consensus-valid transaction with appropriate fees.

“There is no meaningful difference between normalizing the censorship of JPEG or memecoin transactions and normalizing the censorship of certain monetary transactions by nation-states,” Leonidas wrote. “Both would set very dangerous precedents.”

Peter Todd, a Bitcoin developer, stated on X:

Jameson Lopp, co-founder and chief security officer of Casa, raised several criticisms of the proposal. Lopp pointed out that the document does not define what content is legally or morally objectionable and highlighted that legal experts disagree on what liability node operators might face.

“By running a node you consent to the consensus rules of the network. If you don’t consent, you can simply not run a node.” Lopp wrote in a comment.

The proposal has not yet been submitted to the Bitcoin Development Mailing List, a required step for BIP drafts to gather further feedback before pursuing any serious path toward consensus.

The post BIP-444: the temporary soft fork dividing developers and the community appeared first on Atlas21.

Generated by RSStT. The copyright belongs to the original author.

Source