Bitcoin Core developers have long been opposed to inscriptions and have made it clear that they intend to take action. However, considering that the inscription market is bound to the interests of miners, exchanges, and users, it is destined to be a multi-party tug-of-war, so progress will not be very smooth.

Authored by: Trustless Labs

Today, Bitcoin Core developer Luke declared his opposition to the Ordinals class inscription protocol on the X platform, directly viewing it as an attack on Bitcoin, believing that inscriptions are exploiting vulnerabilities in Bitcoin to broadcast junk information to the Bitcoin network.

This argument quickly fermented in the Bitcoin community and received a lot of attention and discussion.

Origin of the debate

In fact, Bitcoin Core developers have been questioning inscriptions for a long time. After the block size limit was increased to 4MB following segregated witness, a large block of 3.96MB was mined in February this year, with Ordinals-related transactions accounting for 3.94MB, reaching an astonishing 99.5%. During the period when inscriptions began to gain popularity in May, Bitcoin-dev raised doubts about the large amount of block space occupied by non-standard Taproot transactions, pointing out in a dev-email that BRC-20-like projects generated a huge volume of transactions, causing severe congestion on the BTC network to the extent that "real Bitcoin transactions" could not be properly packaged and added to the chain.

Luke directly referred to protocols like Ordinals as "worthless," stating that they seriously affect the normal use of BTC as a peer-to-peer cryptocurrency. In the email, he also mentioned the method of restricting inscriptions expressed by Luke in this tweet, which is to force nodes to delete non-standard Taproot transactions directly in the client by adding a review mechanism, and nodes will no longer relay such transactions to achieve the purpose of prohibiting inscriptions.

Upgrade plan and consequences

According to Luke's tweet, the restrictions he introduced mainly involve setting the review policy parameter in the knots client:

-datacarriersize:

• This parameter mainly limits the size of data that can be carried in the OPRETURN output script, which is filled in the output of UTXO. In the existing protocols, Omni and Colored both use data filled in OPRETURN to operate, and Runes in the inscription ecosystem also provides data indexing based on OP_RETURN.

• The default value of this parameter is 83 bytes. Luke suggests setting it to 0 directly in the current client to prevent nodes from relaying transactions with OP_RETURN data, and in the upcoming Knots 25.1, the default value of this parameter will be changed to 42.

-maxscriptsize:

• This parameter mainly limits the size of the script in transactions that nodes can relay. The Ordinals protocol provides data indexing by inscribing protocol data in the Taproot script.

• After the parameter takes effect, nodes will no longer relay taprootscript transactions larger than the set threshold through P2P nodes, affecting the Mint and transfer of Ordinals.

• Luke introduced this parameter in V25.1 and set the default value to 1650.

It can be seen that the upgrade path mentioned by Luke this time is consistent with his idea mentioned in the Bitcoin-dev email of adding a filter in the client to filter out abnormal Taproot transactions. If miners also accept this change in the current code, nodes will reject Taproot transactions with script sizes larger than the set (default 1650 Bytes) in the network, and some Ordinals transactions will not be properly broadcast.

However, this update only restricts the size of the data carried in OP_RETURN and TaprootScript in the Knots client, giving node maintainers the choice to reject some inscription-related transactions, but it does not fundamentally restrict nodes from relaying and miners from packaging such transactions. Moreover, the Taproot upgrade in Bitcoin Core does not perform relative validation on the size of Taproot witness data.

According to the code, in the current Knots code version, the default maximum value of 1650 bytes can support token transfer requirements, so the current restriction mode cannot completely prevent BRC-20-related operations. More attention is needed for Luke's further changes to the policy.

Subsequent development of the BTC ecosystem

Although the debate over inscriptions has been going on for a long time, Luke's statement has caused a great reaction in the community today, and the community has begun to vigorously discuss the subsequent development of the BTC ecosystem.

In response to this event, the fish, representing the miners, expressed their opinion that Bitcoin is not developer-led, and miners need to support the corresponding upgrades, otherwise, unless the developers fork themselves.

At the same time, the review and filtering of "junk transactions" related to inscriptions proposed by Luke currently only remains at the client level. If inscriptions transactions are to be completely banned at the protocol level, updates need to be added to Bitcoin Core, and it may even need to be introduced in the form of a BIP. Luke himself also admitted that this "vulnerability" cannot be avoided before the V27 upgrade.

Several KOLs in the community have also voiced their opinions on this matter, with some voices saying "definitely not agree":

Misty Cosine also stated "no need to fix":

From this, it can be seen that the community still has a positive view of the inscription ecosystem and acknowledges the huge development momentum that inscriptions have brought to the BTC ecosystem and mining. The community's idea of creating a "inscription chain" similar to Layer2 has also received positive feedback from Luke.

In summary, although the scope of this discussion is very broad, Bitcoin Core developers have long been opposed to inscriptions and have made it clear that they intend to take action. However, considering that the inscription market is bound to the interests of miners, exchanges, and users, it is destined to be a multi-party tug-of-war, so progress will not be very smooth. At the same time, the Taproot Asset, which has always been seen as "orthodox," will not be affected even after the upgrade due to its small on-chain footprint, which may release more potential.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。