Opposing view: Inscription is a vulnerability that harms the decentralization of the Bitcoin network; Positive view: Inscription is an innovation and makes the Bitcoin network more secure.
Compiled by: GaryMa, Wu Blockchain Blockchain
Opposition: Inscription is a vulnerability that harms the decentralization of the Bitcoin network.
Written by: William Casarin , Bitcoin developer, founder of Nostr Damus
I will be part of a debate panel to refute the idea that inscriptions are good for Bitcoin. I decided to look into the technical details of the inscription. I'm starting to see luke's point about how it exploits a vulnerability in Bitcoin's anti-spam mechanism.
The “standard” way to store data in Bitcoin
The standard way to add "data" to Bitcoin is to call the OP_RETURN opcode. Bitcoin developers noticed people storing data (such as the Bitcoin white paper) in UTXO collections via large multi-signature transactions. The problem is that this collection is not prunable and may grow over time. OP_RETURN outputs, on the other hand, are provably prunable and do not increase UTXO bloat.
The following is an excerpt from the March 2014 release notes for version 0.9.0, which discusses this issue:
Regarding OP_RETURN: There is some confusion and misunderstanding in the community regarding OP_RETURN functionality and data in version 0.9 and the blockchain. This change is not an endorsement of storing data in the blockchain. The change to OP_RETURN creates a provably prunable output to avoid bloating Bitcoin's UTXO database with some already deployed data storage schemes that store arbitrary data (such as images) as transaction outputs that can never be spent. Storing arbitrary data in the blockchain is still a bad idea; it is cheaper and more efficient to store non-monetary data elsewhere.
Much of Bitcoin Core's work is focused on ensuring that the system continues to function for its intended purpose despite decentralization. People try to misuse it to store data, which Bitcoin Core has always discouraged because it is not designed for storing images and data, but for transmitting digital currency in cyberspace.
To incentivize people not to do stupid things, OP_RETURN transactions are not made non-standard so they can be relayed by nodes and miners, but with an additional condition:
- They can only push 40 bytes (later increased to 80, 83, I guess to support larger root Merkle hashes, since that's the only sensible use case for OP_RETURN)
- Bitcoin also added an option called -datacarriersize, which limits the total number of bytes relayed or mined from these outputs.
Why inscriptions are technically a loophole
Inscription bypasses the datacarriersize limit by using OP_PUSH within an OP_IF block to disguise the data as Bitcoin Script program data. Ordinals do not use OP_RETURN and are not bound by the datacarriersize limit, so node operators and miners currently have limited control over the total size of this data they wish to relay and include in blocks. Luke's Bitcoin Knots have some options to combat this garbage data, so hopefully we'll see this in Bitcoin Core in the near future as well.
Inscription also takes advantage of features in segwit v1 (witness discounts) and v2/taproot (no arbitrary script size limit). Each of these features has interesting and legitimate reasons for its introduction.
The purpose of witness discounting is to reduce the cost of spending many outputs, helping to reduce the size of the UTXO set. Inscription takes advantage of this discount to store monkey jpegs disguised as Bitcoin scripts. Remember, Bitcoin is not designed to store data, so at no time did Bitcoin developers intend to make it cheap and easy to relay data, so this should be considered a vulnerability. Hopefully it gets fixed, or at least gives node operators tools to combat this junk data.
Where will the future go?
What’s interesting about this story is that people seem to place a value on images stored on the Bitcoin blockchain and are willing to pay fees to have them included in blocks, so miners who are not ideological and don’t care about the health and degeneration of Bitcoin Centralized people are happy to pay or take a fee and move on.
Data should not be discounted, people should pay full price to store their data. They should just use OP_RETURN and hashes like opentimestamps or any other reasonable protocol for storing data in Bitcoin.
After this analysis, I think this is a pretty bad spam vulnerability that Bitcoin developers should be working on a solution for. I'm glad to see that ideological developers like Luke who actually care about the health of the network and decentralization are doing this.
Positive: Inscription is an innovation and makes the Bitcoin network more secure
Written by: jolestar
Bitcoin developer LukeDashjr's tweet about banning Inscription caused heated discussions. His main reason was that it was a bug and would affect the security of the Bitcoin network.
The debate between bug and feature has far-reaching consequences. If it is a bug, then the version that fixes it is the orthodox version that continues the current version. But if it is a feature, and fixing it means deleting the feature, then the repaired version is a forked version. So it’s worth discussing in depth.
How to measure the security of blockchain networks has always been a controversial topic. A commonly used metric is the number of block producers (miners or validators). The PoW system does not have an advantage in this regard and is often ridiculed by PoS advocates. Do you still remember the article where the 21 nodes used by EOS ridiculed BTC for not being decentralized and secure enough?
A measurement method often used by Bitcoin developers is the number of full nodes. In order to allow personal PCs to run full nodes, the block size and UTXO set must be strictly limited to reduce the cost of full nodes. But how many full nodes are enough? To what extent will inscription affect the number of Bitcoin full nodes? On the contrary, it can be seen from the current statistical chart that probably because of the popularity of Inscription, many people need to interact with Bitcoin RPC, which increases the number of Bitcoin full nodes.
From the perspective of full nodes, it cannot be said that inscriptions have affected the security of the Bitcoin network.
The blockchain is a public ledger. The more people who care about whether the ledger is correct, the more secure the ledger will be. And why do users care about this ledger? Because this ledger records things related to his interests, whether it is BTC or something else, as long as he feels it is valuable, he will care about this ledger.
And the way users care about the ledger is not the only way to run the full node themselves. Users will have this effect as long as they are directly connected to the Bitcoin network. For example, if a user installs an on-chain wallet and views on-chain transactions, the security guarantee is higher than if the user hosts Bitcoin in an exchange or managed wallet.
What we can see is that this wave of inscription craze has obviously brought more direct connections between users and the Bitcoin network (browser wallets), and has brought about the prototype of the DApp application ecosystem (the inscriptions on the website are linked to the psbt chain through transactions), more users are concerned about what is recorded on this ledger (the emergence of blockchain browsers and the number of visits). Therefore, even from a security perspective, inscriptions can improve the security of the Bitcoin network.
At first glance, Inscription does not have much technical content. It simply writes data to the Bitcoin network and relies on a centralized Indexer.
But we can understand it as a Sovereign Rollup that uses Bitcoin as the data availability layer (DA), but in this mode, the client directly writes DA, which can be called DA first mode, and Indexer is equivalent to the modular blockchain. The Bitcoin execution layer, so it can also be considered that Indexer is actually the L2 of Bitcoin.
The shortcomings of this model are obvious. There is no sequencer to package transactions in batches, the user experience is poor, the transaction fees are very expensive, there is no fraud proof, and the security is also questioned. If a technical team designed such a solution, no investors would be willing to invest, but the charm of the market lies in the fact that users have taken advantage of it. Some time ago, the BRC20 balance data on different exchanges were inconsistent. Users reached social consensus through tweets, and finally achieved consistency, which just shows that it is feasible.
But the advantage of this model is that it puts the protocol first and designs the public protocol and data format first. Only the data necessary for the protocol is stored on the chain, and the execution and verification are off-chain. Any team can implement an Indexer to access this L2 execution layer network, and the entire DA data is shared. In Ethereum's L2 solution, each L2 is equivalent to encircling a piece of land on the DA of L1, each seizing space, and the data is not shared.
This will present a completely different competitive situation. Because the space of any L1 is always limited, if L2 fails to open up a new space that users can trust, then the expansion has not actually been achieved.
Therefore, Inscription is the discovery of the value of Bitcoin as DA. At the same time, the gameplay of Indexer shows a new L2 construction approach, which is of great significance to the Bitcoin ecology. It is a Feature, not a Bug.
possible solutions
Of course, the problem of UTXO set expansion that Bitcoin developers are worried about also exists. But it is not unsolvable, because the Inscription Protocol is an off-chain consensus protocol. As long as Indexer and the community reach a consensus, there can be many solutions. I will write down a few here.
1. Use Hash to replace the content of the inscription. Now the inscription contains various media files, json, etc., which are relatively large in size. But in fact, as long as the indexer layer matures, it is completely possible to only write Hash to L1, and the original content is saved in the Indexer or the user's wallet.
2. Design a set of protocols to support the migration of inscriptions between on-chain and off-chain. When the inscription is migrated off-chain, it is equivalent to being destroyed in L1, and the UTXO is also consumed. If you want to return to the chain again, the user needs to provide the signature aggregation of the Off-chain transfer so that Indexers can verify it.
Another way is to use a sparse Merkle tree verification method like Taproot to achieve on-chain and off-chain migration. I originally designed a migration plan for Ethereum NFT, but unfortunately, NFT on Ethereum is defined through Interface, not a data object model, so it is difficult to take advantage of it, and this model of Inscription is very suitable. Interested friends can also check out this link:
https://github.com/rooch-network/rollup-nft
I won’t write any more plans. What I want to say is that technology is an ecosystem and it needs to grow with user use and feedback. Many innovations are not planned and designed by developers in front of the computer, but emerge from random attempts and collision with user feedback.
To quote a sentence I wrote in "Language is a Decentralized System": To accept that a system is decentralized, you have to accept that it will evolve into things you don't like, and you also have to accept various aspects of its evolution. A failed attempt.
future
Most of the assets issued by these protocols now belong to the category of meme coins. Whether meme coins can transform from a limited-time game into a long-term game system mainly depends on the game among several parties:
1. Are early profit-making participants willing to continue to invest in the ecosystem and provide application scenarios for assets, similar to Bitcoin's early holders investing in various infrastructures. If everyone cashes out, it's just a meme game.
2. Whether the infrastructure provider can provide such space and scenes. On the one hand, this depends on the capabilities provided by infrastructure such as Bitcoin L2. On the other hand, it is also affected by the attitude of the Bitcoin community, including Bitcoin core developers.
