What are the developers' arguments for and against the PR to "filter" Bitcoin inscriptions?
TechFlow Selected TechFlow Selected
What are the developers' arguments for and against the PR to "filter" Bitcoin inscriptions?
Regarding the topic of whether inscriptions should be "banned," this article summarizes the views from both sides of the developer community.
Navigating Web3 tides with focused insightsCompiled by: gloria
Translation: GaryMa, Wu Shuo Blockchain
Background
In September 2023, Bitcoin developer Luke Dashjr submitted a PR to the Bitcoin Core GitHub repository proposing an update to the "datacarriersize" parameter to filter transactions like "inscriptions" that carry novel script data. The underlying belief was that inscription transactions constitute a vulnerability exploit and should be fixed and prohibited.
By default, Bitcoin Core limits the number and embedded data volume of OP_RETURN outputs in unconfirmed transactions, with a default value of 80 bytes. Users can modify this data limit via the -datacarriersize configuration option. However, this option currently only applies to OP_RETURN outputs.
The proposed change would allow users who configure -datacarriersize to not only restrict data volume in OP_RETURN outputs but also limit the amount of data embedded in witness data.
It should be noted that this PR does not implement a comprehensive method to identify "arbitrary" embedded data within witness data (as there is currently no definitive way to do so). It primarily checks for the OP_FALSE OP_IF ... OP_ENDIF structure commonly used for handling inscription data.
Although extensive discussions followed on the PR, Bitcoin Core code maintainer achow101 officially closed it on January 5, 2024. In his final comment, achow101 stated that the PR (proposed by Luke) was clearly controversial and, in its current state, had no hope of reaching a conclusion acceptable to all parties. At this point, he saw no reason to keep it open and continue sending notifications that perpetuate endless, deadlocked debates.
Another Bitcoin Core code maintainer, gloria, has compiled the arguments from both sides of the developer community regarding this topic. Translated below by Wu Shuo.
Arguments Supporting the Prohibition of "Inscriptions"
1. "Ban inscriptions—they are spam transactions"
These types of transactions serve use cases such as ordinals, NFTs, data carrying, or other non-financial applications. This traffic constitutes "spam," disrupting Bitcoin's utility for payments due to high transaction volume and fees.
● Such spam transactions make Bitcoin’s core purpose increasingly difficult to use.
● Embedding data represents deception and abuse of taproot scripts.
● The ability to embed random bytes is a "bug."
● If Bitcoin is money (which it is!), then non-monetary transactions should be minimized as much as possible.
● Cheering for ordinals comes from Ethereum\anti-Bitcoin extremists; those calling for “changing Bitcoin culture” are time-wasting trolls.
● This is a misuse of the network, which was designed for financial transactions (as indicated by the whitepaper, naming, and code), and data storage was never an intended use case.
● This leads to "network congestion" and "higher fees or slower processing times"—a form of "DDoS attack."
● The issue isn't inscriptions per se, but the high transaction fees they generate.
● The Bitcoin network needs immediate protection against spam transaction attacks.
2. "Inscriptions and embedded data harm the network"
These types of transactions increase costs for node operators and somehow damage the network.
● The transactions targeted by this PR are one of the significant cost burdens borne by ordinary node operators.
● These transactions affect network decentralization by increasing node operation costs.
● They result in disproportionate and excessive large-scale data being stored directly on the blockchain.
3. "Prohibition meets user demand"
Clearly, users have demands and specific use cases, so Bitcoin Core should provide this option. Otherwise, people will write and run their own patches, which may be insecure.
● Node operators need a built-in option to ignore all modern forms of data carrying so they don’t have to manually patch their nodes.
● If developers don’t help node operators protect themselves from such attacks, they might resort to improper means to strengthen defenses.
● I want control over my mempool policy—I want to decide what constitutes a spam transaction and what doesn’t.
● If miners believe Bitcoin is money and not just a permissionless, immutable blockchain, they will indeed filter spam transactions to keep the monetary network usable—thus miners would want this feature.
4. "This simply fixes datacarriersize to work as intended"
We already limit data carrying in OP_RETURN. This should apply to all methods of embedding arbitrary data in transactions. This has always been the "intended" purpose of -datacarriersize, so this is a "bug fix."
● luke-jr believes that -datacarriersize failed to update with segwit and taproot to cover other data-carrying methods—an oversight he defines as a bug/vulnerability.
● Bitcoin Core has already standardized that inserting more than 83 bytes of arbitrary data or inscriptions is a workaround bypassing this limit—therefore, this is a bug fix.
● Spam transactions have been filtered at various layers of code for over a decade. All this PR does is extend an existing datacarriersize limit to another form of data carrying—an obvious unintended loophole.
● If we’re not limiting arbitrary data stored in transactions, then what is the purpose of the data carrier limit?
● The purpose of this standardization rule was never limited to data contained in raw scriptPubKey, but rather to all forms of arbitrary data.
Arguments Against Banning "Inscriptions"
1. "This won’t stop inscriptions"
This will not stop inscriptions. Since it lacks incentive compatibility, miners (and of course inscription users) are unlikely to adopt this policy, meaning it would have little effect in preventing these transactions.
● If only Ocean Pool uses this and remains relatively small, it will have no impact. Even if widely deployed, circumventing it is easy.
● Long-term, this is incentive-incompatible for miners.
● Miners are unlikely to give up that revenue stream. Censoring these transactions only encourages the development of private mempools.
● Ordinal transactions will eventually enter the blockchain by bypassing the mempool, rendering this PR ineffective in solving or mitigating the issue.
● To some extent, this attempts not only to avoid monitoring these transactions but also to block their usage, which at best causes such transactions to bypass nodes implementing this rule, or worst-case leads to direct submissions to miners—a serious risk toward mining centralization.
● Inscription enthusiasts can maintain the propagation of inscriptions on the network by ensuring a minority of nodes do not filter them.
● Clearly, blocks built from filtered mempools will inevitably have lower total block rewards compared to templates built from all unconfirmed transactions. This means any miner filtering inscriptions reduces their own income, benefiting non-filtering miners instead.
2. "We cannot write code to detect all embedded data"
Generally, we cannot prevent transactions embedding arbitrary data. Inscriptions exist among numerous ways of embedding data (which we can never fully cover). It's better to preserve the most efficient methods—the ones with minimal impact on network resource costs.
● There is no universal method to filter all current and future data-carrying techniques. This would trigger an endless cat-and-mouse game in critical code paths.
● Attempting to block all types of data embedding will make this code increasingly complex. Each instance puts immense pressure on maintainers to quickly push forward 'stopping spam.'
● As far as I know, there is no reasonable way to stop people from storing arbitrary data in witnesses without incentivizing worse behaviors and/or breaking legitimate use cases.
3. "This change could be harmful"
This PR changes the default mempool policy and could be harmful to independent node operators and the network.
● Excluding transactions that will be mined is harmful to nodes. The purpose of participating in transaction relay and maintaining a mempool is to predict what the next block will look like. Deliberately excluding transactions with very clear (albeit foolish) economic demand undermines this capability.
● Ultimately, users running this patch still process blocks containing inscriptions. They only impair their fee estimation, slow down block validation, and reduce their usefulness to other nodes.
● Changing default policies is generally dangerous. Making previously standard transactions non-standard means some people may find accessing their funds more difficult. By changing defaults instead of making it opt-in, it represents a potentially disruptive and unwelcome behavior shift for miners relying on Bitcoin Core to build block templates... This would represent a mild form of confiscation and should be avoided.
4. Other Arguments Against the PR
● Generally, using mempool policy to block usage is now ineffective, even though it has historically been used this way. While non-standardness has been used in the past to block certain expensive operations, I believe:
○ This is far less relevant now that full blocks have become routine, as it won’t reduce node operating costs anyway.
○ It is powerless to stop transactions that already have a market, paying tens of BTC in fees daily.
● Attempts to "censor" transactions based on use cases are inappropriate. Free markets determine Bitcoin’s use. We have no right to dictate how people should use Bitcoin. If you believe your design is more elegant, go build it, and let the free market decide which is better.
● Bitcoin is a decentralized, permissionless network... anyone can use their bitcoins however they wish, regardless of how objectionable the use may seem.
● This alters the function of -datacarriersize. Beyond changing default policy, it bundles together OP_RETURN output size rules and new restrictions on data embedded in redundant script code, making it impossible to configure your node to match the default policy of versions 26.0 and earlier.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@glozow
