Debate Over Bitcoin Improvement Proposal 444
There’s an ongoing discussion among Bitcoin developers regarding how much arbitrary data should be permitted on the blockchain, leading to a controversial new proposal known as Bitcoin Improvement Proposal 444 (BIP-444).
This proposal, which came out on Friday night, follows the release of Bitcoin Core’s v30 update. This update essentially removes the cap on the amount of data that can be included in a regular Bitcoin transaction via OP_RETURN, as long as fees are paid. Despite the heated debate over changing the byte size limit, the update has been implemented this month, though adoption has been sluggish, with only about 6.3% of reachable nodes using the updated software, according to Bitnodes.
Some Bitcoin users are now pushing to reverse this change, advocating for restrictions on all methods of adding arbitrary data to Bitcoin transactions. They are especially worried about potential legal liabilities facing node operators if illegal content, like child sexual abuse material, were to be uploaded to Bitcoin.
As stated in the proposal, “If a blockchain contains content that is illegal to possess or distribute, node operators will be forced to choose between violating the law (or conscience) or shutting down their nodes. This unacceptable dilemma directly undermines incentives for verification, leads to inevitable centralization, and poses an existential threat to Bitcoin’s security model.”
The terms of the proposal would limit OP_RETURN outputs to 83 bytes, while most other scriptPubKeys would be restricted to 34 bytes. This effectively blocks larger scripts or data blobs. Additionally, it would place limits on the size of individual data pushes, disable certain unused script versions, restrict the size of Merkle trees in Taproot outputs, outlaw OP_IF in Tapscript, and directly inhibit how Ordinals are written.
These modifications would result in a soft fork, making previously valid transactions invalid. However, the proposal emphasizes that these changes are temporary and expected to last around a year. This pause would allow Bitcoin developers the necessary time to explore and implement alternative methods for handling arbitrary data storage on the blockchain.
The proposal’s authors note that “the clearly temporary nature of the soft fork further reinforces that it is a targeted intervention to alleviate a specific crisis, not a promise or a new development direction.”
This proposal was submitted by “Dathon Ohm,” who recently joined GitHub and X just before submitting it and doesn’t seem to have a notable background in Bitcoin development. Attempts to contact Ohm for comments were unsuccessful.
Luke Dash, Jr., a seasoned Bitcoin developer known for his opposition to Ordinals, expressed his support for the proposal, claiming that the process “is progressing smoothly with no technical objections.”
He noted, “This is not intended to be an ideal solution, just enough and very simple to buy time to design a long-term solution.” Dashjr also denied making similar suggestions in other posts.
Critics argue that Bitcoin has allowed arbitrary data since its beginning, and blocking those methods is like censorship, contradicting Bitcoin’s foundational principles. An X user named Leonidas, prominent in the Ordinals community, mentioned earlier this month that miners and mining pools representing over half of Bitcoin’s hashrate indicated they would accept valid transactions with the necessary fees.
Leonidas asserted, “There is no meaningful difference between normalizing the censorship of JPEG or memecoin transactions and normalizing the censorship of specific financial transactions by nation states. Both would set very dangerous precedents.”
Jameson Ropp, co-founder and chief security officer of the Bitcoin storage firm Casa, raised several critical points about the proposal. He mentioned that it fails to define what constitutes legally or morally questionable content, adding that opinions among legal experts vary on the liabilities that node operators could face.
Ropp stated, “When you run a node, you agree to the network’s consensus rules. If you don’t agree, you just don’t run the node.” Attempts to reach Ropp or Dash Jr. for further comments were unsuccessful.
While the proposal has not yet been circulated among Bitcoin development mailing lists—a necessary step for gathering feedback and moving towards approval—it has already sparked significant discussion and comments on platforms like X and other forums.
