On January 7, Bitcoin Core client developer Luke Dashjr launched the proposal “datacarriersize: Match more datacarrying #28408”. This article summarizes the views of supporters and opponents.
Written by: LINDABELL
On January 7, the proposal “datacarriersize: Match more datacarrying #28408” initiated by Bitcoin Core client developer Luke Dashjr was rejected after discussion by many Bitcoin Core developers. The main goal of the proposal, proposed by Luke Dashjr in September 2023, is to update the Bitcoin Core software so that it can effectively use newer data carrying methods to limit the development of inscriptions.
After reading multiple comments on the proposal, ChainFeeds compiled a summary of the views of supporters and opponents. Supporters mainly emphasized the congestion problems currently faced by the Bitcoin network, especially the poor state of the mempool caused by Inscription transactions and The number of spam transactions continues to increase. Opponents argue that the proposal does not effectively solve the spam problem because miners are unlikely to adopt this strategy due to revenue issues. In addition, the controversy also concerns the complexity of the implementation of the proposal and the code complexity it may bring.
Supporters
Supporters argue that the proposal has nothing to do with the inscription itself, but rather with the network congestion it creates. Bitcoin node Léo Haf pointed out, “The current state of the memory pool is very bad. The number of spam transactions has exceeded 200,000, and it seems that the number is still rising. These spam transactions have seriously hindered the practical application of Bitcoin.” The security of inscription utilization The problem is also the main argument among proponents that this vulnerability will not only lead to increased fees and longer transaction processing times, but also become a potential vector for DDoS attacks. In addition, the degree of decentralization of the network will also be affected, and nodes with fewer computing resources may struggle to meet the growing demand, resulting in a more centralized network topology. Another worrying trend is that if too much and too large data continues to be stored on the Bitcoin chain, it is likely that after a certain point, most block files will only contain endless BRC-20 json data.
From the perspective of network participants, first of all, users face high fees while possessing a certain amount of Bitcoin, which essentially prevents them from normal access to the network. Secondly, for nodes, these transactions increase the node’s operating costs but do not add any added value to Bitcoin itself. Finally, there is no benefit to inscriptions for small miners, as censorship of these transactions will only encourage the development of private mempools.
On the other hand, supporters also argue that this proposal only limits the amount of data carried in OP_RETURN, which has always been the “intention” of -datacarriersize. Supporter wizkid057 said, “Spam filtering has been done at various levels of the code for over a decade, and all this PR does is apply the existing datacarriersize limit to another form of data transfer.”
Opponents
Opponents firmly believe that the proposal does not effectively solve the spam problem. First, miners are unlikely to adopt this strategy because miners using newer versions of Bitcoin Core will lose a significant amount of fees using this PR. Ordinals founder Casey Rodarmor pointed out that in the past ten months, inscription transactions have generated at least more than $100 million in transaction fees.
Bitcoin developer Sjors Provoost emphasized, “If only Ocean Pool uses this PR, it will not have any impact on the entire system. If it is widely adopted, circumvention will become easy and the code will become more complex.”
Bitcoin Optech contributor Murch believes that although inscriptions are silly, they will have less negative impact on the use of witness areas than other ways of embedding data in the blockchain. But there is a problem. The patch of this PR does not prevent the Inscription relay from running. Inscription supporters can still keep the relay running by ensuring that a small number of nodes on the network do not filter Inscription. Moreover, miners who choose to filter inscriptions will receive less income, and eventually miners running the patch will still process blocks that include inscriptions. Therefore, he felt that the PR change would do more harm than good.
Of course, whether code can be written to detect embedded data has also become an important point of debate. Blockstream developer Lisa Neigut said that adding filters to exclude Ordinals transactions from Bitcoin is a fairly complicated method.
In the end, Bitcoin Core developer Ava Chow closed the PR and said that under the current circumstances, it is difficult for the proposal to reach a conclusion that satisfies everyone, so there is no need to continue the discussion. Luke Dashjr has been criticizing Inscription since November last year, but in fact, his negative view of Inscription mainly stems from concerns about the potential risks of the Bitcoin main network, rather than completely eradicating Inscription. It can also be seen from the proposal that Luke Dashjr expects that most nodes will comply with the PR, and does not exclude mining pools willing to package inscription data. Although it will bring some inconvenience to the user experience, it may also spawn some Bitcoin Layer 2 development opportunities.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
The controversy over the ban on inscriptions has settled: Luke Dashjr’s proposal was rejected, where will the controversy go?
Written by: LINDABELL

On January 7, the proposal “datacarriersize: Match more datacarrying #28408” initiated by Bitcoin Core client developer Luke Dashjr was rejected after discussion by many Bitcoin Core developers. The main goal of the proposal, proposed by Luke Dashjr in September 2023, is to update the Bitcoin Core software so that it can effectively use newer data carrying methods to limit the development of inscriptions.
After reading multiple comments on the proposal, ChainFeeds compiled a summary of the views of supporters and opponents. Supporters mainly emphasized the congestion problems currently faced by the Bitcoin network, especially the poor state of the mempool caused by Inscription transactions and The number of spam transactions continues to increase. Opponents argue that the proposal does not effectively solve the spam problem because miners are unlikely to adopt this strategy due to revenue issues. In addition, the controversy also concerns the complexity of the implementation of the proposal and the code complexity it may bring.
Supporters
Supporters argue that the proposal has nothing to do with the inscription itself, but rather with the network congestion it creates. Bitcoin node Léo Haf pointed out, “The current state of the memory pool is very bad. The number of spam transactions has exceeded 200,000, and it seems that the number is still rising. These spam transactions have seriously hindered the practical application of Bitcoin.” The security of inscription utilization The problem is also the main argument among proponents that this vulnerability will not only lead to increased fees and longer transaction processing times, but also become a potential vector for DDoS attacks. In addition, the degree of decentralization of the network will also be affected, and nodes with fewer computing resources may struggle to meet the growing demand, resulting in a more centralized network topology. Another worrying trend is that if too much and too large data continues to be stored on the Bitcoin chain, it is likely that after a certain point, most block files will only contain endless BRC-20 json data.
From the perspective of network participants, first of all, users face high fees while possessing a certain amount of Bitcoin, which essentially prevents them from normal access to the network. Secondly, for nodes, these transactions increase the node’s operating costs but do not add any added value to Bitcoin itself. Finally, there is no benefit to inscriptions for small miners, as censorship of these transactions will only encourage the development of private mempools.
On the other hand, supporters also argue that this proposal only limits the amount of data carried in OP_RETURN, which has always been the “intention” of -datacarriersize. Supporter wizkid057 said, “Spam filtering has been done at various levels of the code for over a decade, and all this PR does is apply the existing datacarriersize limit to another form of data transfer.”
Opponents
Opponents firmly believe that the proposal does not effectively solve the spam problem. First, miners are unlikely to adopt this strategy because miners using newer versions of Bitcoin Core will lose a significant amount of fees using this PR. Ordinals founder Casey Rodarmor pointed out that in the past ten months, inscription transactions have generated at least more than $100 million in transaction fees.
Bitcoin developer Sjors Provoost emphasized, “If only Ocean Pool uses this PR, it will not have any impact on the entire system. If it is widely adopted, circumvention will become easy and the code will become more complex.”
Bitcoin Optech contributor Murch believes that although inscriptions are silly, they will have less negative impact on the use of witness areas than other ways of embedding data in the blockchain. But there is a problem. The patch of this PR does not prevent the Inscription relay from running. Inscription supporters can still keep the relay running by ensuring that a small number of nodes on the network do not filter Inscription. Moreover, miners who choose to filter inscriptions will receive less income, and eventually miners running the patch will still process blocks that include inscriptions. Therefore, he felt that the PR change would do more harm than good.
Of course, whether code can be written to detect embedded data has also become an important point of debate. Blockstream developer Lisa Neigut said that adding filters to exclude Ordinals transactions from Bitcoin is a fairly complicated method.
In the end, Bitcoin Core developer Ava Chow closed the PR and said that under the current circumstances, it is difficult for the proposal to reach a conclusion that satisfies everyone, so there is no need to continue the discussion. Luke Dashjr has been criticizing Inscription since November last year, but in fact, his negative view of Inscription mainly stems from concerns about the potential risks of the Bitcoin main network, rather than completely eradicating Inscription. It can also be seen from the proposal that Luke Dashjr expects that most nodes will comply with the PR, and does not exclude mining pools willing to package inscription data. Although it will bring some inconvenience to the user experience, it may also spawn some Bitcoin Layer 2 development opportunities.