Bitcoin Developers vs. Inscriptions: A Long-Standing Dispute
TechFlow Selected TechFlow Selected
Bitcoin Developers vs. Inscriptions: A Long-Standing Dispute
Bitcoin Core developers have long opposed inscriptions and have clearly stated their intention to take action. However, given that the inscription market has already tied together the interests of miners, exchanges, and users, the situation is注定to be a multi-party tug-of-war, making progress inevitably difficult.
Navigating Web3 tides with focused insightsBy Trustless Labs
Today, Bitcoin Core developer Luke took to the X platform to voice his opposition to the Ordinals inscription protocol, directly labeling it as an attack on Bitcoin. He argued that inscriptions are exploiting a vulnerability in Bitcoin to flood the network with spam data.
This statement quickly sparked intense discussion and widespread attention within the Bitcoin community.
Origins of the Controversy
In fact, skepticism from Bitcoin Core developers toward inscriptions is not new. After SegWit, the block size limit was effectively increased to 4MB. In February this year, a block measuring 3.96MB was mined, of which 3.94MB—nearly 99.5%—was attributed to Ordinals-related transactions. During the surge in popularity of inscriptions in May, concerns were raised on Bitcoin-dev about non-standard Taproot transactions consuming excessive block space. An email thread highlighted how projects like BRC-20 generated massive transaction volumes, causing severe congestion on the BTC network and preventing "real Bitcoin transactions" from being confirmed promptly.
Luke labeled protocols like Ordinals as "worthless," asserting they severely impair Bitcoin's core function as a peer-to-peer electronic cash system. The email also referenced the same mitigation approach he mentioned in his recent tweet: introducing a censorship mechanism at the client level to force nodes to drop non-standard Taproot transactions, thereby preventing their relay and ultimately halting inscription activity.
Proposed Upgrades and Consequences
According to Luke’s tweet, the proposed restrictions would primarily involve setting specific policy parameters in the Knots client:
-datacarriersize:
-
This parameter limits the amount of data that can be embedded in OP_RETURN output scripts. Such data is stored within the UTXO outputs. Existing protocols like Omni and Colored Coins use OP_RETURN to embed metadata, and the Runes protocol within the inscription ecosystem also relies on OP_RETURN for data indexing.
-
The current default value is 83 bytes. Luke suggests setting it to 0 immediately in existing clients to prevent nodes from relaying any transaction containing OP_RETURN data, and plans to change the default to 42 in the upcoming Knots 25.1 release.
-maxscriptsize:
-
This parameter restricts the maximum script size that nodes will relay. The Ordinals protocol stores inscription data within Taproot scripts to enable indexing.
-
Once enforced, nodes will no longer relay Taproot transactions whose script exceeds the threshold, impacting both minting and transferring of Ordinals.
-
Luke has already introduced this parameter in version 25.1 and set its default to 1650.
It is evident that Luke’s proposed upgrade path aligns with his earlier suggestion in the Bitcoin-dev mailing list—to add filters in clients to block non-standard Taproot transactions. If miners adopt these code changes, nodes across the network would refuse to relay Taproot transactions with script sizes exceeding the set threshold (default 1650 bytes), making some Ordinals transactions unable to propagate normally.
However, this update only introduces data size limitations for OP_RETURN and Taproot scripts within the Knots client, giving node operators the option—but not the obligation—to reject certain inscription-related transactions. It does not fundamentally prevent nodes from relaying or miners from including such transactions in blocks. Moreover, the original Bitcoin Core Taproot upgrade did not impose corresponding checks on witness data size.
Based on current code analysis, the default maximum of 1650 bytes still accommodates typical token transfer operations. Therefore, under this current restriction model, BRC-20 related activities cannot be fully blocked. Further limitations may depend on future modifications to policy parameters by Luke.
Future of the BTC Ecosystem
Although debates over inscriptions have existed for some time, Luke’s latest stance has triggered significant reactions within the community, especially given the current boom in BTC’s ecosystem. Discussions about the future direction of Bitcoin have reignited.
In response to this event, mining representative Shenyu shared his perspective: Bitcoin is not solely developer-driven; upgrades require miner support, otherwise developers would need to fork independently.
Furthermore, Luke’s proposed filtering of what he calls “spammy inscription transactions” remains at the client level for now. To completely ban inscription transactions at the protocol level, changes would need to be incorporated into Bitcoin Core itself—or even introduced via a BIP (Bitcoin Improvement Proposal). Luke himself acknowledges that this “vulnerability” cannot be resolved before the V27 upgrade.
Several community KOLs have also voiced their opinions, with some firmly opposing the move:
Manwu Yuxian also commented that “there’s no need to patch this”:
These responses suggest that significant portions of the community still support the inscription ecosystem, recognizing the substantial momentum it has brought to BTC’s development and mining economy. Notably, community proposals to create a Layer2-like “inscription chain” received positive feedback from Luke.
In summary, while this debate has cast a wide net and Bitcoin Core developers have long opposed inscriptions and are now taking concrete action, the entrenched interests of miners, exchanges, and users tied to the inscription market mean progress will likely be contentious and incremental. Meanwhile, Taproot Assets—often seen as the more “legitimate” approach due to its minimal on-chain footprint—will remain unaffected by these upgrades and may unlock further potential going forward.
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
@TrustlessLabs
