In their statement, the developers argued that while the new transaction relay policy might lead to more non-financial use cases, protecting censorship resistance is one of the core tenets of the blockchain.
The developers noted that the Bitcoin network is “defined by its users, who have ultimate freedom” to choose whether they utilize the blockchain for financial or non-financial use cases. As such, the Bitcoin core developers are “not in a position to mandate” what software or policies they choose.
Several Bitcoiners have opposed the developers’ opinion, calling it a drift away from the blockchain’s original intended function. On the other hand, some have defended the developers’ viewpoint, leading to a global debate among Bitcoiners.
“The long-standing cap, originally a gentle signal that block space should be used sparingly for non-payment proof of publication data, has outlived its utility.”
The developers argued that users have found ways to circumvent the data limit, which can potentially harm the network. Therefore, “retiring a deterrent that no longer deters” large-data inscriptions will enable the fee market to “arbitrate competing demands.”
In their Friday statement, the Bitcoin core developers defended their decision to remove the data cap for transaction relays. They noted that it is their responsibility to ensure that their software is efficient and reliable, contributing to Bitcoin’s success as a decentralized digital currency. They stated:
“With regards to transaction relay, this may include adding policies for denial of service (DoS) protection and fee assessment, but not blocking relay of transactions that have sustained economic demand and reliably make it into blocks.”
According to the developers, transaction relay has three major goals. This includes predicting which transactions will be mined, which also serves to prevent denial-of-service (DoS) attacks. In DoS attacks, miscreants flood the network with spam transactions, overwhelming the network and preventing it from processing transaction requests from legitimate users.
Additionally, transaction relay also speeds up transaction propagation, which in turn prevents large miners from gaining an unfair advantage. It also helps miners learn about fee-paying transactions, the developers noted. Therefore, they wrote:
“Knowingly refusing to relay transactions that miners would include in blocks anyway forces users into alternate communication channels, undermining the above goals.”
Besides, the Bitcoin node software should not intervene through a data cap where both transaction creators and miners consent to add a large data inscription to a block, the developers noted. This is because Bitcoin was built on the ethos of censorship resistance, they explained, adding that large data transactions are “largely harmless at a technical level.”
The developers clarified, however:
“This is not endorsing or condoning non-financial data usage, but accepting that as a censorship-resistant system, Bitcoin can and will be used for use cases not everyone agrees on.”
They added that while they are aware of the dissent among Bitcoiners, they sincerely believe the move “is in the best interest of Bitcoin and its users.”
“The goals of transaction relay listed are basically all wrong. Predicting what will be mined is a centralizing goal. Expecting spam to be mined is defeatism. Helping spam propagate is harmful.”
He added that the statement portrays the abuse of the blockchain through spam transactions as legitimate use cases instead of treating them as DoS attacks. However, he believes such transactions are the same as DoS attacks.
“Core’s new stance essentially says, “if someone pays enough, any use is valid.” That’s economically naive and ignores Bitcoin’s fundamental purpose as a monetary network.”
“It’s Bit”Coin” not Bit”Bucket” or Bit”Store” or whatever general purpose data store you have in mind. It’s a “peer to peer electronic cash system”.”
The user added that keeping the network focused on its original purpose is not censorship.
“Core Devs are a group saying we can’t force anyone to run code they don’t like, here is our thinking on relay policy & network health.”
