Retrospective of the OP_Return Debate in 2014: Dapps vs. Bitcoin Transactions from the Ordinals Discussion

Retrospective of the OP_Return Debate in 2014: Dapps vs. Bitcoin Transactions

Author: BitMEX Research

Link: https://yakihonne.com/article/naddr1qq25uwz4x355vve4g9nhvv2cgdyxudjp89nh2q3qdaperk4tmar36n4c6spcujdwt0ljc5um5lzykwgdsqkkzwveww5sxpqqqp65wvz5cp4

The 2014 OP_RETURN controversy was a significant split in the industry, with many similarities to today’s Ordinals debate. Looking back, the OP_RETURN controversy is particularly meaningful today.

Some Bitcoin enthusiasts and Bitcoin developers did not want this kind of activity on the Bitcoin blockchain and successfully prevented activities like OP_RETURN. At the same time, promoters of other chains such as Ethereum may have used and exaggerated the Bitcoin developers’ apparent stance to help make their ecosystem more attractive.

Overview

We are often asked why Dapps such as decentralized exchanges are typically built on Ethereum rather than Bitcoin. After all, it is possible to build Dapps on top of Bitcoin, such as decentralized exchanges, domain name systems, or alternative tokens. There are of course several reasons for this, such as: i. Ethereum’s more flexible native scripting language makes building Dapps easier; ii. Ethereum’s faster block times make Dapps more user-friendly, or iii. Bitcoin’s more conservative block size limit results in potentially higher fees for Bitcoin. All of these factors do have an impact, but we believe their impact is often exaggerated. The most important factor is cultural. Some Bitcoin enthusiasts and Bitcoin developers did not want this kind of activity on the Bitcoin blockchain and successfully prevented it. This seems to have happened primarily around March 2014, and what happened during that time is the subject of this article. At the same time, promoters of other chains such as Ethereum may have used and exaggerated the Bitcoin developers’ apparent stance to help make their ecosystem more attractive.

Counterparty Protocol

As we mentioned in our September 2020 report, Counterparty was launched in early 2014. Counterparty is a protocol layer on top of Bitcoin that supports features such as creating new tokens and trading those tokens on decentralized exchanges. The system works by using some Bitcoin transaction data and using it as a feature in the counterparty protocol in transactions between counterparties, such as creating tokens, sending tokens, or bidding on tokens on decentralized exchanges.

In short, initially, CounterBlockingrty used the Bitcoin opcode OP_CHECKMULTISIG to include CounterBlockingrty-related data in the Bitcoin blockchain. This opcode was intended to be used for verifying the signature of a payment script hash (P2SH) multisig transaction. An example of a CounterBlockingrty transaction from July 2014 can be found here. The transaction sent Bitcoin back to the address it came from and also had three additional outputs, with output scripts containing data related to the counterparty protocol. In this case, it was creating a new token called TICKET. Using OP_CHECKMULTISIG could be considered a hack, as this was not the expected usage of the opcode. CounterBlockingrty now uses Bitcoin’s OP_Return opcode to store data, which is somewhat more in line with developers’ intentions. See this updated CounterBlockingrty transaction, which uses OP_Return, for example.

In early 2014, there was a lot of experimentation, developer activity, innovation, and excitement around CounterBlockingrty, which was ahead of a competing platform called Mastercoin.

What is OP_Return?

OP_Return is a provably unspendable transaction output in Bitcoin. This feature can be used to burn Bitcoin or store arbitrary data on the Bitcoin blockchain. Because the data is not part of the UTXO set, storing data in this way is said to help scale Bitcoin, as pruning nodes do not need to store OP_Return data.

Bitcoin’s consensus rules allow for a maximum OP_Return size of 10,000 bytes. For example, in May 2013, someone utilized this feature in the following transaction. The OP_Return output in this transaction contained the lyrics to the 1987 Rick Astley song “Never Gonna Give You Up,” which is associated with the Rickrolling meme.

Prior to 2014, transactions that included OP_Return were non-standard and not relayed by regular Bitcoin nodes. However, if included by a miner, they were considered valid. In March 2014, Bitcoin Core 0.9.0 was released, which included the OP_Return functionality as a standard transaction type, so transactions would be relayed by default. The release notes at the time stated:

This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates provably-prunable outputs, to avoid data storage schemes (some already deployed) where arbitrary data (e.g. images) is stored forever because the cost of pruning such data from the UTXO database is prohibitive. Storing arbitrary data in the blockchain is still a bad idea; it’s more expensive and less efficient to store non-currency data elsewhere.

Source: https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain

Bitcoin Core 0.9.0 only relays transactions with OP_Return data of 40 bytes or less. If the data is larger than this, the transaction is still valid, but it will not be relayed. The initial limit was 80 bytes, but after several debates, the developers eventually settled on 40 bytes.

In 2016, Bitcoin Core 0.11.1 finally raised the relay limit to 80 bytes, and it was further increased to 83 bytes in the 2016 end-of-year Bitcoin Core 0.12.0 release, which is the limit we have today. This means that if you want to make a transaction with an OP_Return output larger than 83 bytes today, you either have to mine your own block or send it directly to a miner.

OP_Return War

On March 20, 2014, Jeff Garzik, one of the major contributors to Bitcoin at the time, began posting on the CounterBlockingrty board of the Bitcointalk forum. Jeff criticized CounterBlockingrty’s use of blockchain space.

So far, I haven’t seen a blockchain data dump scheme that can’t be safely replaced with a simple hash. You don’t need to store data in the blockchain. That’s pure intellectual laziness. Timestamping a hash (data) is just as secure and more efficient. Plus, a secondary chain can be proved to be linked to Bitcoin:

Source: https://bitcointalk.org/index.PHPtopic=395761.msg5796379#msg5796379

Jeff went on to say:

CheckMultiSig obviously applies to ECDSA public keys, not arbitrary data. Using the operation for something other than its intended purpose can have negative, possibly unexpected or unknown consequences, which is not surprising. CounterBlockingrty transactions are not “according to the Bitcoin protocol,” they go through because it was never expected to be used in this way.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827189#msg5827189

Some people might find it strange that Jeff has such a view, as in 2017 he seemed to be a “big block supporter,” and this conservative view on the use of block space seems inconsistent with the big block view. However, this obvious contradiction did not exist in 2014. At that time, Jeff’s views were to some extent endorsed by almost all active developers, including those who later became big block leaders. As far as we know, there is no simple mapping between people’s views on block size limits and this issue. Jeff was a highly respected developer at the time, and this article attracted great attention from CounterBlockingrty developers and users.

A CounterBlockingrty developer going by the moniker “BitcoinTangibleTrust” responded to Jeff as follows:

You are absolutely correct. You do not need to store data on the blockchain. A timestamp hash (data) is just as secure and more efficient. A second-level chain could be proven to be linked to bitcoin. However, according to CounterBlockingrty co-founder and lead developer “PhantomPhreak” below, CounterBlockingrty IS storing data in the blockchain with 256 bytes every three multi-signature transactions. Additionally, all of these multi-signature transactions are processed by miners.

The developer goes on to criticize the Bitcoin developers’ plans to limit OP_Return to 40 bytes instead of 80 bytes:

If OP_RETURN is intended to stop/reduce multi-signature behavior (unused outputs) and thus reduce blockchain bloat, then I am concerned that by reducing the size of OP_RETURN from 80 bytes to 40 bytes, you will unintentionally make multi-signature more attractive to all meta-protocols, and you’ve already reduced the attractiveness of OP_RETURN.

CounterBlockingrty co-founder and lead developer “PhantomPhreak” chimes in:

The idea is we store the data in a second blockchain and put the hashed timestamp of that data into Bitcoin which would be less than 40 bytes as well. We didn’t do this not because of “intellectual laziness” but rather the complexity of implementation. CounterBlockingrty is not a computer science project; it was designed to be as simple as possible to speed up development. Even if we have to store data in a multi-signature output instead of a too-small OP_RETURN output. In this field, worse is definitely better.

Jeff responded the next day:

This is freeloading. Using full nodes as dumb data storage endpoints is simply an abuse of a completely volunteer network resource. The network replicates transaction data, why not freeride? Mastercoin and CounterBlockingrty did not engage with the existing community, but simply flipped the “on” switch and began using Bitcoin P2P nodes as unwanted data storage. Unused transaction outputs were never intended to be used as arbitrary data storage. The fact that it can be abused does not make it right, or remotely efficient, or the best solution. The UTXO (unused transaction output) database is a fast-access database for the entire network. Every node needs that database to be as small as possible in order to best handle network transactions. Encoding arbitrary data as unused outputs is network-wide abuse, plain and simple. The entire network bears that cost.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5815887#msg5815887

Due to Jeff’s high status in the community, most people in the CounterBlockingrty community seem eager to participate and solve the problem. For example, BitcoinTangibleTrust responded:

Thank you for sharing your thoughts, Jeff. So, would you help us get started interacting with the existing Bitcoin core development community? Acting as responsible partners is in the interest of CounterBlockingrty, because we need the Bitcoin blockchain if we are to survive. Can you tell us how to get started collaborating on these issues?

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5816031#msg5816031

Another CounterBlockingrty developer raised another point:

Is there a way for the bitcoin protocol to prevent XCP from using it in a way that doesn’t break anything else?

If Bitcoin developers cannot prevent transactions related to XCP opponents, perhaps this opposition is not important and CounterBlockingrty can continue to use Bitcoin without permission. Bitcoin developers and former mining pool operator Luke-Jr then entered into a debate:

Miners should filter out abusive behavior.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5816503#msg5816503

Luke-Jr then suggested using a merged-mining sidechain-type structure to build these types of systems, which would avoid blockchain bloat.

The problem is not with new layers, but with imposing on people against their will. New layers can be completed on the basis of choice, without polluting the blockchain and forcing non-participants to store data.

Luke was also asked why Bitcoin developers reduced the expected size of the OP_Return relay to 40 bytes, while the originally proposed limit was 80 bytes. Luke responded with the following three points:

Too many people thought OP_RETURN was a feature that should be used. It never had that intent, it was just a way to “keep the window unlocked so we don’t need to replace the glass when someone breaks in.” That is, to reduce the damage caused by people abusing Bitcoin.
40 bytes are enough to meet all legitimate needs for binding data to transactions: you get 32 bytes for a hash, plus 8 bytes for some kind of unique identifier (which is actually unnecessary!).
The original 80-byte proposal was intended for 512-bit hashes, but was determined to be unnecessary.

Luke-Jr continued:

With mining returning to decentralization, I hope we’ll see tolerance for abuse/spam transactions reduced, whether it’s the OP_RETURN variant or some other variant. If someone actually has a valid, necessary use-case to store transaction hashes with, then miners should obviously seriously consider mining it.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5817170#msg5817170

At the time, Luke’s pool also began filtering out CounterBlockingrty-related transactions. Fear and uncertainty began to build in the CounterBlockingrty community at this point. They needed OP_Return for 80 bytes, otherwise they would be forced to continue using the OP_CHECKMULTISIG opcode. Given Luke’s comments, it seemed unlikely that it would reach 80 bytes. Additionally, some were concerned that developers might even further reduce the restrictions, which could result in CounterBlockingrty being pushed out of the network. Bitcoin developers didn’t seem particularly friendly to CounterBlockingrty, so some may have thought that continuing to use the Bitcoin protocol would be difficult.

On March 25, 2014, Ethereum’s co-founder Vitalik Buterin weighed in, believing that the debate should be more around fees, and that if you pay enough fees, then your transaction should be included legitimately in a block. Today, Ethereum’s fee algorithm is highly complex, with different fee buckets and rates for many different blockchain use cases, fundamentally solving the OP_Return problem. One could argue that SegWit on Bitcoin also alleviates the problem to some extent.

“This is a problem with the protocol, the OPRETURN battle,” he said. “In an ideal world, the concept of ‘abuse’ would not exist; fees would be mandatory and carefully designed to closely match the actual cost imposed on the network by a given transaction. If you can pay the fee for what you’re doing, you should be able to do it, no questions asked.”

Source: https://www.coindesk.com/markets/2014/03/25/developers-battle-over-bitcoin-block-chain/

On March 27, 2014, CounterBlockingrty changed the way transactions were made to bypass Luke-Jr’s mining filter. However, the following day Luke commented:

Good news! Adding a filter to block this useless thing took less than 5 minutes and 1 line of code.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5955613#msg5955613

Luke-Jr also compares CounterBlockingrty to a form of abuse:

This is abusive, because you force others to download/store your data based on their free choice. Every full node must download the full blockchain (trimmable or not!). Every full node agrees to download and store financial transactions. Not every full node agrees to store anything else. For this, you need 100% consensus, not just some subset (i.e. not miners; not developers) or even majority. Additionally, anyone is free to store data not in the blockchain. Putting it in the blockchain has no benefit, just you imposing it on those who don’t want it. You explain how this is not abusive…

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5826443#msg5826443

The anger of Bitcoin developers

As expected, the concerns of Bitcoin developers eventually led to frustration and anger from some CounterBlockingrty developers and users. We include some of their comments below. First, a user named “porqupine” commented on Luke-Jr’s mining pool blocking CounterBlockingrty transactions:

This is great compared to the responsible developers who are working on finding solutions–you’re playing cat and mouse. You realize you’re also talking about network neutrality? And trying to put into private hands which transactions should and shouldn’t be taking place on the blockchain. What’s your next sanction against some people you don’t like? Sanctioning the broadcast of transactions from nodes in countries/regions whose foreign policies you don’t approve of?

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5955738#msg5955738

On March 21, 2014, porqupine continued:

Wait, when it decides: every node agrees to store X type of data instead of Y type of data. Maybe I also don’t agree to store transactions for money laundering, illegal drugs and weapons, human slavery, etc. You are basically negating protocol neutrality, and deciding what the protocol should and should not be used to store, not just you’re not speaking in the first person, but using the pronoun “us” gives the impression that you’re speaking on behalf of all miners or protocol users as a whole.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5826584#msg5826584

Others expressed concern over why Jeff and Luke had the authority to override others in stopping certain use cases.

I can’t believe this attitude. I don’t know who owns Bitcoin. I thought I and about a million other people owned it

PhantomPhreak, co-founder of CounterBlockingrty, said:

First of all, CounterBlockingrty transactions are financial transactions. Secondly, every full node agrees to download and store the Bitcoin blockchain. That is, transactions that conform to the Bitcoin protocol, CounterBlockingrty transactions obviously do that. For God’s sake, Satoshi embedded a political message in the genesis block… your view of the possible uses of Bitcoin is much narrower than others’.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5826770#msg5826770

They continued:

Bitcoin has done a lot of things it wasn’t intended to do. Yes, we would greatly prefer to use more elegant solutions than what exists now. CounterBlockingrty was originally designed to store all of its message data in OP_RETURN outputs, which I think is very elegant and has minimal impact on the blockchain. We plan to have all message formats be centered around the 80-byte limit that Gavin announced on the official Bitcoin blog. We only use multisig outputs because we have no other choice. We don’t want to extend the Bitcoin protocol. We want to do something completely within it and as simple and direct as possible to gain the benefits of stability, security, etc.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827473#msg5827473

Similarly, we only store financial transactions in the blockchain, and we are paying for the space we are using. Financial transactions in OP_RETURN outputs are no more painful for full nodes to store than anything else.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827688#msg5827688

Another user named “bitwhizz” said:

If you don’t want to store it, don’t, it’s pretty simple, don’t use Bitcoin, don’t download the blockchain, your scott free. However, my agreeing means I believe Bitcoin not only has transactional capabilities, but based on that fact, nobody owns it, and with the OP_RETURN functionality, I don’t understand why that functionality should be eradicated because you don’t want to store data that you can already choose not to.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827897#msg5827897

“Anotheranonlol” said:

I really can’t wrap my head around how CounterBlockingrty transactions don’t constitute financial transactions? I also can’t understand the argument that says it should be left up to default that if 1 node out of 1000 nodes refuses to accept the data then it should be blocked. CounterBlockingrty seems to have come up with a solution after the recent nightmares of mt.gox and the plethora of hacks, thefts, shutdowns, and losses caused by storing your balance on a centralized entity, the solution allows for a decentralized, trustless solution to this problem.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827776#msg5827776

“Baddw” said:

In fact, anyone can store any data in the blockchain at any time. It already is, and is being used for this purpose. Everyone who runs a Bitcoin node should already know this, and if they don’t, it should have been part of the notification when they installed Bitcoin-QT (if there was one; I don’t remember). Any Bitcoin transaction could just as easily be a simple funds transfer, or a love letter, or a trigger to detonate a bomb. Eliminating this possibility would strangle Bitcoin.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827749#msg5827749

Baddw continued:

Many of the greatest developments in the history of computation (indeed, in human technological history) have resulted from people discovering things their inventors never intended them to use it for. Fortunately, most inventors are not so protective of their inventions and do not refuse to let others use them for new things. Those who do find that they are quickly surpassed.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827925#msg5827925

From these comments, it is clear that many CounterBlockingrty users and developers are surprised and disappointed by the stance of Bitcoin developers. Although the project continues, as does Mastercoin, it is likely that some developers have left Bitcoin as a result and are building their protocols on other blockchain systems such as Ethereum. In our view, this moment in 2014 is more important than any other moment. Others may have different views.

Merged Mining Sidechains

Throughout the entire OP_Return debate, opponents of CounterBlockingrty and blockchain bloat often mention some form of merged mining sidechains as a solution for Dapps. In fact, it is said that Satoshi Nakamoto liked this route and supported it for use in a domain name system in December 2010:

I think BitDNS has some potential to be a completely separate network and a separate blockchain, but there needs to be some way for merge mining to be possible. The only overlap is if the miners can search for proof-of-work for both networks simultaneously.

Source: https://bitcointalk.org/index.PHP?topic=1790.msg28696#msg28696

There are many difficulties in implementing these Dapp systems as sidechains, and our understanding of these weaknesses is better than it was in 2014, when many people simply assumed they would work.

Complexity – one of the most important weaknesses is the complexity of implementing and building sidechain solutions. These projects did not have time to create sidechains and merged mining systems with Bitcoin in order to launch protocols and gain market share.
Bitcoin as a native asset – it may not be possible to use non-custodial Bitcoin as operational assets on a sidechain, as it may not be possible to establish a trustless bidirectional hook. This is a major weakness for many Dapps, such as those that may want to use Bitcoin as the primary trading pair for a distributed exchange. This weakness did not seem to be well understood in 2014, and many people simply assumed it could work in some way.
Limited scaling advantages – the advantages of using sidechains may vary depending on the use case. For example, if you were building a distributed exchange, every bid, offer, and match may require all the security guarantees of the main chain. With so many main chain uses, the scaling advantages of the sidechain system may be very limited for every possible action a user takes on the exchange. Submitting bids locally on the chain may only save about 90 bytes, while storing hash order information and identifying structures and overhead may take about 50 bytes on the chain, so not much space is saved.

In March 2014, CounterBlockingrty developer (xnova) outlined his opposition to sidechains as follows.

In addition, unless I’m overlooking something here, we still need to parse data out of blocks in the second blockchain (at least assuming it’s a Bitcoin or Bitcoin-derived implementation) to get at our stored data. So: * It won’t enable SPV-type CounterBlockingrty clients, because of the colored coin functionality (i.e. DEx, betting, asset callbacks, dividends, differential contracts, etc.) CounterBlockingrty offers. * It will reduce the security of CounterBlockingrty transactions. This will greatly increase the complexity of the implementation (i.e. increase the chance of errors and bugs) for only a slight * reduction in our storage requirements for the blockchain (i.e. maybe 20-40 bytes less per transaction?). I’m just not understanding what this gains us here. One last thing: CounterBlockingrty could be huge for Bitcoin, and if/when Ethereum (and other similar non-Bitcoin “2.0” type coins) come into view, this will become even more apparent. At least my personal feeling is that Bitcoin will likely need products with this functionality in the ecosystem to effectively compete with Ethereum and the (future) crowds of functionality and appeal-or risk being left behind, at least in terms of investors and financial market operators-which provides the ability to bring billions or even trillions of dollars into the Bitcoin ecosystem as it gains more recognition, trust, and thought-sharing.

Source: https://bitcointalk.org/index.PHP?topic=395761.msg5799174#msg5799174

It seems that some people who support sidechains as a solution are not particularly interested in many Dapp applications, nor have they tried them. Therefore, they have never considered the complexity of building a decentralized exchange, and the security required for almost every action of each user. Most Bitcoin developers seem open to what interests them, and it is clear what they want: anti-censorship currency, non-political currency, electronic cash, etc.

Conclusion

Around 2014, most developers interested in Dapps focused on building on Ethereum or other systems, rather than on Bitcoin. Ethereum subsequently gained a lot of interest and momentum from developers, while Dapp development on Bitcoin was minimal. The point of this article is to emphasize that the main driving force behind this situation is not necessary fees, nor Ethereum’s virtual machine and Ethereum’s more powerful technical capabilities, but rather that many Bitcoiners and Bitcoin developers simply do not want Dapps on Bitcoin, they are not interested in these features on Bitcoin. Some Bitcoiners deliberately drove away many of these Dapp developers. Some Bitcoin supporters believe that most Dapp activity is related to unsustainable scams, or for security or other reasons, this activity is not desirable on Bitcoin.

Since 2014, many people’s views have changed. Bitcoin needs transaction fees to survive. In the environment after 2016, we have many full blocks and higher fees. It is more common for people to believe that any paid transaction is “legitimate”. Some Dapps on Ethereum, such as exchanges such as Uniswap, or lending protocols such as AAVE and Compound, have been proven to be successful and interesting to some extent. Nevertheless, whether Bitcoiners care enough about these protocols on Bitcoin, let alone whether anyone is actually building and using them, is still an open question.

Retrospective of the OP_Return Debate in 2014: Dapps vs. Bitcoin Transactions from the Ordinals Discussion