Bitcoin Core Developer Why is Mingwen considered an attack on Bitcoin

Why is Mingwen Considered a Threat to Bitcoin by Bitcoin Core Developers?

Another Bitcoin Core developer has come forward to support Luke (see previous reports) and oppose engravings.

Bitcoin Core developer and Nostr developer William Casarin posted on the web application habla.news, which is based on Nostr, stating that engravings are an attack on BTC.

Here’s the translation by 0xjs@LianGuai:

“I oppose the idea that ordinals are beneficial to Bitcoin. I decided to revisit the technical knowledge of how engravings work. I started to see Luke’s perspective on how it exploits vulnerabilities in Bitcoin’s anti-data spam mechanism.”

The “standard” way Bitcoin stores data

The standard method of adding “data” to Bitcoin is by using the OP_RETURN opcode. Bitcoin developers noticed that people were storing data (like the Bitcoin whitepaper) in the UTXO set through large multi-signature transactions. The problem is that this set is unprunable and may grow over time. On the other hand, OP_RETURN outputs have proven to be prunable and do not inflate the UTXO.

Here’s an excerpt from the Bitcoin Core v0.9.0 release notes from March 2014, discussing this point:

Regarding OP_RETURN: There has been some confusion and misunderstanding in the community about the OP_RETURN functionality in 0.9 and data in the blockchain. This change is not an endorsement of storing data on the blockchain. The change to OP_RETURN creates a provably prunable output to avoid data storage schemes (some of which have been deployed) where arbitrary data (e.g., images) is stored in TX outputs that are unspendable forever, bloating Bitcoin’s UTXO database. Storing arbitrary data on the blockchain remains a bad idea; it is cheaper and more efficient to store non-currency data elsewhere.

Most of Bitcoin Core’s work focuses on ensuring the system continues to operate in a decentralized manner to fulfill its intended purpose, even if someone tries to abuse it to store data, etc. Bitcoin Core has never encouraged this practice because it’s not designed for storing images and data, but rather for moving digital currency in cyberspace.

To help incentivize people not to do foolish things, OP_RETURN transactions have not become non-standard so that they can be relayed by peers and miners. However, it should be noted that:

– They can only push 40 bytes (later increased to 80, 83, I guess to support larger root Merkle hashes, as this is the only reasonable use case for op_return)
– Bitcoin also added an option called “-datacarriersize”, which limits the total number of bytes for these outputs that users relay or mine.

Why engravings are technically an attack

Engravings disguise data as Bitcoin script program data within the OP_IF block, circumventing the data carrier size limit. Ordinas does not use OP_RETURN and is not bound by the data carrier size limit, so node operators and miners currently have limited control over the total size of data they want to relay and include in blocks. Luke’s Bitcoin Core fork has some options to counter this spam, so hopefully, we’ll see this in Core soon too.

The inscription also utilizes the functions of segwit v1 (witness discount) and v2/taproot (no arbitrary script size limit). Each of these features has its interesting and reasonable reasons for being introduced.

The purpose of the witness discount is to make spending many outputs cheaper, helping to reduce the size of the UTXO set. The inscription takes advantage of this discount to store monkey jpegs disguised as Bitcoin scripts. Remember, Bitcoin is not meant for data storage, so if the Bitcoin developers accidentally make it cheap and easy to forward data, it should be seen as a vulnerability. Hopefully, it can be fixed or at least provide tools for node operators to combat this spam.

What’s next

The interesting thing about this story is that people seem to assign value to images stored on the Bitcoin blockchain and are willing to pay fees to include them in blocks, so both ideology-free miners and people who don’t care about Bitcoin’s health and decentralization are happy to charge and continue moving forward.

Data should not be discounted. If people want to store data, they should pay full price. They should only use op_return and hash values, like opentimestamps or any other reasonable protocol for storing data in Bitcoin.

After analyzing it, I believe this is a very bad data spam attack that Bitcoin developers should address. Ideological developers like Luke actually care about the health and decentralization of the Bitcoin network, and I’m glad to see that.

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

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

Blockchain

10 million bitcoins are "sleeping"! Is it better to have more money laundering parties?

A few days ago Coindesk released a statistic: the number of bitcoins that have not moved for more than a year has exc...

Market

Lawyers acknowledge that part of Tether’s reserves are supported by Bitcoin

“Before the order on April 24… Tether actually invested in products that exceeded cash and cash equivale...

Market

🚀 Smaller Cryptocurrencies Rally as Bitcoin Trades Sideways 🪂

Klyatn and Finschia Foundation have unveiled their plan to merge the two blockchains, creating a powerful Web3 platfo...

Blockchain

The Bitcoin panic index is low, and Coinbase data says that whales are buying.

Today, fear, uncertainty and suspicion (FUD) in the bitcoin market are obvious. But this should not be the case, beca...

Blockchain

QKL123 market analysis | The oil war has ended, US stocks financial reports, data are coming, this week's thunder? (0413)

Summary: Bitcoin rebounded weakly, the market continued to dip, and altcoins were relatively weak. Recently, the glob...

Blockchain

Bitcoin Secret History: What did Satoshi Nakamoto and BM chat in Bitcointalk

Source: Hash Pie Author: LucyCheng In mid-2010, before Satoshi Nakamoto disappeared, not long after BM first came int...