Will the Bitcoin community fork if core developers want to ban inscriptions?

Possible Fork in Bitcoin Community if Core Developers Propose Inscription Ban

Author: Maxwell@LianGuai

On November 7, 2023, the BRC20 token leader ORDI was listed on Binance, and on December 5, ORDI broke through $65. In other words, ORDI has increased more than 10 times in less than a month.

Such a surge has once again sparked controversy in the Bitcoin community over the Ordinal theory and Bitcoin inscriptions.

On December 6, Bitcoin Core developers announced a fix for the Taproot vulnerability to disable Bitcoin inscriptions. As the controversy escalated, the price of the BRC20 token leader ORDI plummeted, dropping from $65 to below $50, a decrease of more than 20%.

• The trend is set, and we are in the midst of a new bull market cycle for BTC.
• Bitcoin Unveiling the Rendezvous of the Digital Age and the Gold Standard
• Bitcoin’s Perfect Imperfection: The Halvening

Bitcoin Core developers fire back: Ordinals and BRC20 are junk mail for BTC

On the morning of December 6, around 9 am Beijing time, Bitcoin Core developer Luke Dashjr tweeted:

“Inscriptions” are using vulnerabilities in Bitcoin Core to send spam to the blockchain. Since 2013, Bitcoin Core has allowed users to set limits on additional data size in their relayed or mined transactions (-datacarriersize). Inscriptions bypass this limit by obfuscating the data as program code.

This bug was recently fixed in Bitcoin Knots v25.1. It took longer than usual due to disruptions in my workflow at the end of last year (completely skipped v24).

Bitcoin Core is still vulnerable to attack in the upcoming v26 release. I can only hope that it will be finally fixed by next year’s v27.

A user asked: So, if the “inscriptions” want to continue, in my opinion, a more environmentally friendly approach would be to create an “inscription chain,” similar to Ethereum’s layer 2. This chain only needs to submit the Merkle root to Bitcoin regularly to operate. Is that correct?

Luke Dashjr replied: Yes, that’s possible. And it doesn’t even need block size limits – each node can set its own limit (or have none at all).

The controversy has been going on for a long time

Back in May 2023, during the previous wave of Bitcoin inscription frenzy, developers in the bitcoin-dev channel were discussing this controversy.

The discussion at the time was initiated by another Bitcoin Core developer, Ali Sherief. Ali Sherief stated that due to the high transaction volume of BRC-20 and other tokens, the Bitcoin network was heavily congested. These “one-value” transactions threatened the smooth and normal use of the Bitcoin network as a peer-to-peer digital currency. Should Bitcoin developers take action?

He argued that the Bitcoin network consists of developers, miners, and users. Considering that miners are largely responsible for the abuse of the system, the harmony of Bitcoin transactions is now being disrupted. Although the developer community has a long history of not meddling, unless absolutely necessary – an example being during the big block/small block war and the SegWit period. Should similar action be taken now, in the form of i) BIP and/or ii) submitting to the Bitcoin Core codebase, to address the vulnerabilities in BIP 342 (which defines the verification rules for Taproot scripts) that have led to these unexpected consequences? Another approach is to enforce this “scrutiny” at the node level and introduce a runtime option to immediately remove all non-standard Taproot transactions.

At the time, Luke Dashjr expressed in the bitcoin-dev channel that action should have been taken months ago. Spam filtering has been a standard feature of Bitcoin Core since its inception. It was a mistake not to extend the existing filters to Taproot transactions.

Bitcoin OG and former CSO of Blockstream, Samson Mow, agrees with Luke’s point of view. He previously stated that epitaphs are clogging the Bitcoin network, and the widespread adoption of Bitcoin is not because people are creating JPEGs and storing them on the Bitcoin chain, but because it is a store of value and a means of transaction.

How significant is the impact after the vulnerability is fixed?

Firstly, Ordinals and BRC-20 will cease to exist.

Luke Dashjr confirmed in a reply on social media that if the Bitcoin Core vulnerability is fixed, it means that Ordinals and BRC-20 will cease to exist.

Other impacts:

Crypto developer Ben77 extensively studied Luke Dashjr’s code in knots (a desktop Bitcoin node) and discovered some key details.

Luke has set two main parameter restrictions in knots for filtering so-called Bitcoin fraudulent transactions:

datacarriersize: This parameter primarily limits the size of data carried by op-returns, i.e., those that write data in the output section of UTXOs. If this restriction is enabled, the affected protocols will include: Colored coins, OmniLayer, Runes, etc.

maxscriptsize: This parameter limits the TaprootScript-based inscription protocol, where the data is engraved in the witness field of UTXOs. If this restriction is enforced, the affected protocols will include: ordinals, brc20, etc.

It is clear that if Luke’s vision becomes a part of the core, the default restriction values of these two parameters might result in only taprootassets and RGB, which occupy the least on-chain footprint, remaining in the Bitcoin ecosystem.

Crypto researcher Haotian stated:

Inscription is seen as a dusting attack, and in Bitcoin v25.1, miners will be given a switch to decide whether to include transactions that exceed the SIZE limit.

The current inscription market only fattens the pockets of miners, as it gives program configuration parameters for free choice, which is meaningless because no miners will choose it.

If Core developers insist on making miners accept it, future versions might forcefully change the consensus, which means Bitcoin will fork.

Almost all protocols that rely on Taproot script parameters for issuing and transferring assets will be affected. However, previously issued assets by the Atomical Protocol will not be affected in their subsequent transfers because they do not depend on Taproot parameters (but it will affect the issuance of new assets). On the other hand, the subsequent transfers of BRC20 will always require on-chain inscription as a prerequisite and will be globally affected.

Miners have different opinions, and Bitcoin is difficult to fork

Regarding Luke’s proposal, some netizens expressed low feasibility because “most miners will choose to mine inscription transactions as it makes more economic sense. Miners make decisions based on their bottom line, not ideological formations.”

Luke replied, “The operation of Bitcoin assumes that most miners are honest and have no malicious intent. Additionally, for some reason, block spam filters usually charge higher fees. An ideology that pursues short-term profit is just another ideology, and a bad one at that.”

In response to this, the representative of the miners and founder of F2pool, Godfish, stated in the community, “BTC is not ETH, developers don’t have the final say. If an upgrade requires miner votes, and miners vote against it, then it won’t be upgraded. If the developers insist on upgrading, they can fork on their own.”

Therefore, some netizens have detected the taste of the BCH fork in 2017.

As a result, more people have expressed their admiration: questioning Wu Jihan, understanding Wu Jihan, becoming Wu Jihan.

Some netizens have pointed out sharply: in the past, Bitcoin forks were initiated by miners, but now with epigraphy gaining popularity, miners are earning a lot, making them the beneficiaries of epigraphy. Miners don’t want a fork. Blocking someone’s financial path is like killing their parents.

It is unlikely that Bitcoin will fork without computational support.

What do others think?

Yu Xian, the founder of SlowMist, posted on social media that Luke Dashjr’s views as a Bitcoin core developer are a bit provocative. If everything goes as he wishes, future versions of Bitcoin will fix what he considers vulnerabilities: sequence/epigraphy is a vulnerability of Bitcoin, it is a type of SLianGuaim attack. He later tweeted that personally, he doesn’t think it’s necessary to fix this, because the introduction of Taproot (a good thing) accidentally opened this Pandora’s box, which not only brought a bunch of SLianGuaim, but also the vitality of the Bitcoin ecosystem. Of course, if this is fixed, there can be better compatibility solutions to open the Bitcoin ecosystem, then it’s better to endure short-term pain than long-term pain.

Xu Mingxing, the founder of OKX, said, will this force the Bitcoin epigraphy community to migrate to src20 or the Lightning Network Taproot assets? In any case, OKX will continue to build to support the Bitcoin ecosystem.

Conclusion

Due to the balance of power between developers, miners, and users in the Bitcoin ecosystem, even if Bitcoin Core developers decide to fix Taproot and ban epigraphy, it will be difficult to change anything without the support of miners and users.

Moreover, Stratum V2 itself allows miners to customize block templates, so miners who dislike epigraphy can choose not to include epigraphy transactions. Perhaps Bitcoin epigraphy will continue to thrive.

But considering Bitcoin’s performance and positioning, the “SLianGuaim attack” is also a reality. Bitcoin will eventually have to pass the test of “SLianGuaim attack”. Whether Bitcoin can withstand it is up to the Bitcoin community.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!