Published on: 2023-05-09T17:45:11+00:00
In a recent discussion on the Bitcoin-dev mailing list, the topic of raising the limit on OP_RETURN was brought up. However, it was concluded that imposing limits may not be necessary as people will find ways to work around them and fees will regulate the use of OP_RETURN. The issue of controlling the value of stored data was also raised, with suggestions to store references to data using hashes and/or signatures instead of storing it directly. It was noted that this cannot currently be done with OP_RETURN. The discussion also touched on the issue of freeriders and how to prevent them from impacting the network as a whole and increasing decentralization among miners. Finally, the idea that the market will self-regulate when ordinal meme stuff/BRC20 has zero value was mentioned.Another thread in the Bitcoin-dev email chain focused on concerns about inscriptions being inserted between specific flags. It was explained that this is simply an artificial limitation of the current inscription protocol and there are numerous ways to embed arbitrary data in Bitcoin transactions. The flood of BRC-20 inscriptions happening currently is considered small and could have used other data encoding techniques or OP_RETURN outputs. Blocking these types of transactions is seen as futile. The purpose of this flood of inscriptions is to create a new set of assets via an auction, which does not require any data to be embedded in the chain at all. Blocking such transactions is deemed hopeless by some individuals.The ongoing discussion on the bitcoin-dev mailing list revolves around the limitation of the inscription protocol, which only allows data to be inserted between OP_FALSE and OP_IF flags. One suggestion is to implement a validation check to reject witness scripts that have arbitrary data between these flags, thereby allowing rejection of inscriptions while still benefiting from taproot. However, others argue that blocking such use cases is hopeless as there are countless ways to embed arbitrary data in Bitcoin transactions. They point out that the current flood of inscription transactions is small and could have used alternative data encoding techniques. Additionally, the purpose of this flood, which involves the creation of a new set of assets through an auction, does not require any data to be embedded in the chain. It could have been implemented with normal transactions that are indistinguishable from others.In a message sent on May 8, 2023, a user named Moth proposed the idea of a validation check to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags. The goal is to prevent the network from being overloaded with transactions focused solely on ordinals and BRC-20 tokens while still benefiting from taproot. However, it is noted that there are many other ways to "inscribe" data into the blockchain, making such a validation check ineffective. Some individuals had hoped for a slightly larger OP_RETURN to store a tagged root of a hash-tree for various use cases. These use cases include open timestamps, ION, and Gordian Envelope, which consolidates large sets of proofs into a hash used for L2 proofs-of-inclusion. Concerns have been raised about the inscription technique freeloading on the network mempool, the validation network, and volunteer unpruned full nodes. This has led to increased costs for hosting and maintaining free privacy services. While solutions are sought, it remains uncertain whether raising the limit on OP_RETURN would be a viable solution.There is also a concern that banning the storage of arbitrary/non-functional data could lead to people abusing useful data, causing more harm than good. An example of this is Stamps, which stores Inscription-like data in fake outputs, consuming UTXO set storage. The issue of the UTXO set getting too big is seen as a more significant problem than the chain size increasing. It is unclear whether lifting the size limit for witness scripts as part of Taproot was an oversight. If Taproot is meant to enable large useful scripts, it becomes difficult to define "not useful" in a way that filters out unwanted data. It is suggested that incentivizing people to find workarounds by attempting to censor their current actions may lead to even worse outcomes. The fear is that banning things will only push people to find alternative ways to bypass the ban.One suggestion put forward is to have a validation check to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags. This would prevent the network from being overloaded with transactions focused solely on ordinals and BRC-20 tokens while still benefiting from taproot. However, the author questions whether this validation check is a good idea and whether it was an oversight to allow arbitrary data between these flags when the size limit for witness scripts was lifted as part of taproot. It is important to note that OP_RETURN can currently store arbitrary data up to 80kb.
Updated on: 2023-08-02T09:25:50.032298+00:00