The OP_RETURN debate of 2014 was a significant split within the industry, with many similarities to today’s Ordinals debate. Reviewing the OP_RETURN debate is particularly meaningful today.
-
Some Bitcoin enthusiasts and Bitcoin developers didn’t want to engage in such activities on the Bitcoin blockchain at all, and they successfully prevented activities like OP_RETURN. Meanwhile, promoters of other chains like Ethereum may have leveraged and exaggerated Bitcoin developers’ apparent stance to help make their ecosystem more attractive.
Overview
We are often asked why decentralized applications such as DEXs are usually built on Ethereum and not Bitcoin. After all, it is possible to build DApps on top of Bitcoin, such as decentralized exchanges, domain name systems, or substitute tokens. There are certainly several reasons, 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 restrictions make Bitcoin’s potential costs higher. All of these factors do have an impact, but we believe their impact is often exaggerated. The most important factor is culture. Some Bitcoin enthusiasts and Bitcoin developers didn’t want to engage in such activities on the Bitcoin blockchain at all, and they successfully prevented these activities. This seems to have happened primarily around March 2014, and what happened during that time is the subject of this article. Meanwhile, promoters of other chains like Ethereum may have leveraged and exaggerated Bitcoin developers’ apparent stance to help make their ecosystem more attractive.
CounterBlockingrty Protocol
As we mentioned in our September 2020 report, in early 2014, CounterBlockingrty was launched. CounterBlockingrty is a protocol layer on top of Bitcoin that supports functionalities 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 functionality in counterpart protocols, such as creating tokens, sending tokens, or bidding on tokens in decentralized exchanges.
- Can the “Wave Trader” continue its winning streak with monthly profits of one million dollars?
- SEC considers 19 tokens on Binance and Coinbase as securities, what impact does it have?
- Realio Founder: After three years of struggling to achieve compliance, I am now forced to leave the United States?
In short, originally, CounterBlockingrty used the Bitcoin opcode OP_CHECKMULTISIG to include CounterBlockingrty-related data into the Bitcoin blockchain. This opcode was intended to verify the signatures of a payment script hash (P2SH) multisignature transaction. An example of a CounterBlockingrty transaction from July 2014 can be found here. The transaction sends Bitcoin back to the address it came from and also has three additional outputs, with output scripts containing data related to counterpart protocols. In this case, it’s creating a new token called TICKET. Using OP_CHECKMULTISIG could be seen as a hack, as this wasn’t the opcode’s intended use. CounterBlockingrty now uses Bitcoin’s OP_RETURN opcode to store data, which is somewhat more in line with developers’ intentions. For example, see this updated CounterBlockingrty transaction that uses OP_RETURN.
In early 2014, a lot of experimentation, developer activity, innovation, and excitement was taking place around CounterBlockingrty, which was leading a competitor platform called Mastercoin.
What is OP_Return?
OP_Return is a provably unspendable transaction output in Bitcoin. This feature can be used to burn bitcoins or store arbitrary data in the Bitcoin blockchain. Since the data is not part of the UTXO set, it is said that storing data in this way helps to scale Bitcoin because 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 leveraged this feature in the following transaction. The OP_Return output in this transaction contained the lyrics to Rick Astley’s 1987 song “Never Gonna Give You Up,” which is associated with the Rickrolling meme.
Prior to 2014, transactions containing OP_Return were non-standard and not relayed by ordinary Bitcoin nodes. However, if miners included these transactions, they were considered valid. In March 2014, Bitcoin Core 0.9.0 was released, which included the OP_Return feature as a standard transaction type, so transactions would be relayed by default. The release notes at the time were as follows:
This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates provably-prunable outputs, allowing arbitrary data (such as images) to be stored in the block chain, which can be of use to future applications. Stored data is expensive and users should never store more data than needed or sensitive information, but it is useful for some limited purposes.
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_Returns of 40 bytes or less, and if the data is larger than this, it is still a valid transaction but will not be relayed. The initial limit was 80 bytes, but after much debate, the developers ultimately settled on 40 bytes.
In 2016, Bitcoin Core 0.11.1 finally increased the relay limit to 80 bytes, and it was increased to 83 bytes, the limit we have today, in Bitcoin Core 0.12.0 at the end of 2016. This means that if you want to make a transaction with an OP_Return output that exceeds 83 bytes today, you must either mine the block yourself or send it directly to a miner.
OP_Return War
On March 20, 2014, one of Bitcoin’s main contributors, Jeff Garzik, began posting on the CounterBlockingrty section 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 securely replaced with a simple hash. You don’t need to store data on the blockchain. That’s pure intellectual laziness. A timestamped hash (data) is just as secure and more efficient. In addition, a secondary chain can be proven to be tied to Bitcoin:
Source: https://bitcointalk.org/index.PHPtopic=395761.msg5796379#msg5796379
Jeff went on to say:
CheckMultiSig is obviously intended for 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 “in accordance with the Bitcoin protocol,” they go through because it was never expected to use that feature in this way.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827189#msg5827189
Some may find it strange that Jeff had this view, since he seemed to be a “big block supporter” in 2017, and this conservative view of using block space seems inconsistent with the big block view. However, this obvious contradiction did not exist in 2014. At that time, Jeff’s view was 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 respected developer at the time, and this article attracted great attention from CounterBlockingrty developers and users.
A CounterBlockingrty developer with the pseudonym “BitcoinTangibleTrust” replied to Jeff as follows:
You are absolutely right. You don’t need to store data on the blockchain. A timestamped hash (data) is just as secure and more efficient. A secondary chain can be proven to be tied to Bitcoin. However, according to the explanation of PhantomPhreak [CounterBlockingrty co-founder and chief developer] below, CounterBlockingrty IS using 256 bytes to store data on the blockchain in every third multisignature transaction. In addition, all of these multisignature transactions are processed by miners.
Developers continue to criticize Bitcoin developers’ plan to limit OP_Return to 40 bytes instead of 80 bytes:
If OP_RETURN is intended to stop/reduce multisignature behavior (unused outputs) and thus reduce blockchain bloat, then I’m worried that by reducing the size of OP_RETURN from 80 bytes to 40 bytes, you will inadvertently make multisignature more attractive to all meta-protocols, and you have already reduced the attractiveness of OP_RETURN.
Chief CounterBlockingrty Developer and Co-Founder, named “PhantomPhreak”, chimes in:
The idea here is that we store data in a second blockchain and stick the hash of that timestamped data into Bitcoin, those hashes will also be less than 40 bytes. The reason we didn’t do this is not “intellectual laziness” but rather the complexity of implementation. CounterBlockingrty is not a computer science project; it’s designed to be as simple as possible to speed up development. Even if we had to store data in multisignature outputs instead of too-small OP_RETURN outputs. In this field, worse is definitely better.
The next day Jeff responds:
This is freeloading. Given that the overwhelming majority (>90%) of Bitcoin blockchain applications are currency usage, using full nodes as dumb data storage terminals is simply abusing the voluntary network resources. The network replicates transaction data, why not freeride? Mastercoin and CounterBlockingrty didn’t engage with the existing community, they 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 doesn’t make it right, or remotely efficient, or the best solution. The UTXO (unspent transaction output) database is a fast-access database for the entire network. Every node needs that database as small as possible to best handle network transactions. Encoding arbitrary data as unused outputs is network-wide abuse, plain and simple. The entire network bears this 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 engage and solve the issue. For example, BitcoinTangibleTrust responds:
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 CounterBlockingrty’s interest because we need the Bitcoin blockchain if we are going 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 a 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 can’t stop the opponent’s relevant transactions, perhaps this opposition is not important, and CounterBlockingrty can continue to use Bitcoin without permission. Bitcoin developers and Luke-Jr, the operator of the mining pool at the time, then debated:
Miners should filter out abuse.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5816503#msg5816503
Luke-Jr then suggested that a merged-mining sidechain-type structure could be used to build such systems, which would avoid blockchain bloat.
The problem is not the new layer, but the imposition of people’s will. The new layer can be completed based on the choice of joining without polluting the blockchain and forcing non-participants to store data.
Luke was also asked why Bitcoin developers reduced the expected OP_Return relay size to 40 bytes, while the original limit was 80 bytes. Luke responded with the following three points:
-
Too many people think OP_RETURN is a feature that should be used. It was never intended to be just a way to “keep the window unlocked so we don’t have to replace the glass when someone breaks in”. That is, reducing the damage caused by people abusing Bitcoin.
-
40 bytes are sufficient to meet all legitimate needs for binding data to transactions: you get 32 bytes for the hash, plus 8 bytes for some kind of unique identifier (which is actually not necessary!).
-
The original 80-byte proposal was intended for 512-bit hashes, but was determined to be unnecessary.
Luke-Jr continued:
With the return of mining decentralization, we hope to see a reduced tolerance for abuse/spam transactions, whether OP_RETURN variants or other variants. Now, if someone has a valid, necessary use case for actually storing hash values with transactions, then obviously miners should seriously consider mining.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5817170#msg5817170
Luke’s mining pool also began filtering transactions related to CounterBlockingrty. Fear and uncertainty began to build in the CounterBlockingrty community at this time. They needed OP_Return for 80 bytes, otherwise they would be forced to continue using the OP_CHECKMULTISIG opcode. Given Luke’s comments, it seems unlikely to reach 80 bytes. In addition, some people are concerned that developers may even further reduce the restriction, which may cause CounterBlockingrty to be separated from the network. Bitcoin developers seem to be not particularly friendly to CounterBlockingrty, so some people may think that it may be difficult to continue using the Bitcoin protocol.
On March 25, 2014, Vitalik Buterin, the main founder of Ethereum, interjected, believing that the debate should focus more on fees. If you pay enough fees, then your transaction should be legally included in the block. Today, Ethereum’s fee algorithm is very complex, with different fee buckets and rates for many different blockchain uses, which fundamentally solves the OP_Return problem. Some argue that SegWit on Bitcoin has also alleviated this problem to some extent.
This is a protocol error, and the OPRETURN battle is such a problem. In an ideal world, the concept of “abuse” simply does not exist; fees will be mandatory and carefully designed to closely match the actual cost of a given transaction to the network,” he said. “If you can pay for what you are doing, then 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 transaction method to bypass Luke-Jr’s mining filter. However, Luke commented the next day:
Good news! It took less than 5 minutes and 1 line of code to add a filter to block this useless thing.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5955613#msg5955613
Luke-Jr also likened CounterBlockingrty to a form of abuse:
This is abusive, because you force others to download/store your data according to their free choice. Every full node must download the entire blockchain (pruning 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), even a majority. Additionally, anyone is free to store data not in the blockchain. Putting it on the blockchain has no benefit, you just impose it on people who don’t want it. Explain to me how this is not abuse…
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5826443#msg5826443
Anger from Bitcoin Developers
As expected, concerns from Bitcoin developers were met with frustration and anger from some CounterBlockingrty developers and users. Below are some of their comments. First from a user named “porqupine” commenting on Luke-Jr’s pool blocking CounterBlockingrty transactions:
Good on you for promoting the cat catching mice game instead of responsibly working on finding solutions like the developers are. Do you realize you’re also talking about net neutrality? And trying to put transactions that people should and shouldn’t be doing on the blockchain in private hands. What’s the next sanction against people you don’t like? Sanctioning nodes broadcasting transactions in countries/regions whose foreign policy you don’t agree with?
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5955738#msg5955738
porqupine continued on March 21st, 2014:
Wait until it decides: every node agrees to store X type of data instead of Y type of data. Maybe I don’t agree to store drug money, illegal drugs and weapons, human slavery transactions either. You’re basically denying protocol neutrality and deciding what the protocol should and shouldn’t be used to store, and not just speaking in the first person, but using the pronoun Us, giving the impression that you’re speaking for 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 block certain use cases over others.
I can’t believe this attitude. I thought there were no owners of Bitcoin. I thought I and about a million other people were the owners
PhantomPhreak, co-founder of CounterBlockingrty, said:
First, CounterBlockingrty transactions are financial transactions. Secondly, every full node agrees to download and store the Bitcoin blockchain. That means transactions that comply with the Bitcoin protocol, CounterBlockingrty transactions clearly do. For God’s sake, Satoshi embedded a political message in the genesis block…you have a much narrower view of possible uses for Bitcoin than others do.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5826770#msg5826770
He or she goes on to say:
Bitcoin has done a lot of things that it wasn’t originally intended to do. Yes, we would love to use more elegant solutions than we currently have. CounterBlockingrty was initially designed to use OP_RETURN outputs to store all of its message data, and I thought that was very elegant and the least impactful on the blockchain. We plan to have all message formats revolve around the 80-byte limit that Gavin announced on the official Bitcoin blog. We use only multi-sig outputs because we have no other choice. We don’t want to extend the Bitcoin protocol. We want to do things completely within it, and as simply and directly as possible in order to gain benefits in stability, security, etc.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827473#msg5827473
Also, 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” says:
If you don’t want to store it, then don’t, it’s pretty simple, don’t use Bitcoin, don’t download the blockchain, your scott-free. However, my concurrence implies that I believe Bitcoin not only has transactional functionality, but based on that fact that nobody owns it and that there is an OP_RETURN functionality, I don’t understand why the feature should be eradicated just because you don’t want to store data that you are already free to choose to store.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827897#msg5827897
“Anotheranonlol” says:
I really can’t understand how CounterBlockingrty transactions aren’t financial transactions? I also can’t understand the viewpoint that says because one out of a thousand nodes doesn’t want to accept the data, it should be banned by default. It seems that CounterBlockingrty has come up with a solution to this problem that allows for a decentralized, trustless solution after the recent nightmare that was mt.gox and the massive amounts of hackings, thefts, shut downs, and losses that have resulted from storing your balances on centralized entities.
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 is already and is being used for this purpose. Anyone running a Bitcoin node should already know this, and if they don’t, it should be part of the notification that appears when they install Bitcoin-QT (if there is one; I don’t remember seeing it). Any Bitcoin transaction may be just simple fund flow, or it may be a love letter, or it may be a detonator for a bomb. Eliminating this possibility would stifle Bitcoin.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5827749#msg5827749
Baddw continued:
Many of the greatest developments in the history of computing (actually, human technological history) have been the result of people discovering things their inventors never intended. Fortunately, most inventors are not so protective of their inventions and do not object to others using them for new things. Those who do find themselves 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, so 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. However, others may have a different view.
Merged Mining Sidechains
Throughout the OP_Return debate, CounterBlockingrty and opponents of blockchain expansion often mention some form of merged mining sidechain as a solution for Dapps. In fact, it is said that Satoshi Nakamoto liked this path and supported it for the domain name system in December 2010:
I think BitDNS has some potential to be a completely separate network and separate blockchain, but share CPU power with Bitcoin. The only overlap is letting miners search for proof-of-work for both networks simultaneously.
Source: https://bitcointalk.org/index.PHP?topic=1790.msg28696#msg28696
Implementing these Dapp systems as sidechains presents many difficulties, and our understanding of these weaknesses is better in 2014 than it was in 2014, when many people simply thought they would work.
-
Complexity – one of the biggest weaknesses is the complexity of implementing and building sidechain solutions. In order to launch the protocol early and gain market share, these projects do not have time to establish sidechains and a merged mining system with Bitcoin.
-
Bitcoin as 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 trustless bi-directional pegs. This is a big weakness for many Dapps, such as they may want to use Bitcoin as the primary trading pair on a decentralized exchange. This weakness in 2014 was not well understood, and many people just assumed it could work somehow.
-
Limited scaling benefits – the advantages of using sidechains may vary depending on the use case. For example, if building a decentralized exchange, every bid, ask, and match may require all the security guarantees of the main chain. With so much main chain usage, the scaling benefits of the sidechain system may be very limited for every possible action of each user on the exchange. Submitting bids on-chain locally may only use about 90 bytes, and storing the order information hash and the structure and overhead that needs to be identified may use about 50 bytes on-chain, so not much space is saved.
In March 2014, Counterparty developer (xnova) outlined his opposition to sidechains as follows.
Additionally, unless I am missing something here, we still need to parse data out of blocks from the second blockchain (assuming it is a Bitcoin or Bitcoin derivative implementation) to get at our stored data. Thus: * It will not enable SPV-type Counterparty clients, as Counterparty offers colored coins functionality (i.e. DEx, betting, asset callbacks, dividends, and margin contracts) * It will decrease the security of Counterparty transactions. This will greatly increase implementation complexity (i.e. increase opportunities for errors and vulnerabilities) for the only dubious benefit of * slightly reducing our storage requirements for the blockchain (i.e. reducing each transaction by maybe 20-40 bytes?). I just don’t see what the point of this is here. One other thing: Counterparty could bring huge benefits to Bitcoin, and this will be even more apparent if/when Ethereum (and other similar non-Bitcoin meta “2.0” coins) come into view. At least from my personal sense, Bitcoin is likely going to need products in its ecosystem that have this functionality to effectively compete with Ethereum and (future) crowdsourced functionality lists and appeal — or risk being left behind, at least among investors and financial market operators, who provide the ability to bring billions or even trillions of dollars into the Bitcoin ecosystem as it gains more recognition, trust, and thought leadership.
Source: https://bitcointalk.org/index.PHP?topic=395761.msg5799174#msg5799174
It seems that some of the people who support sidechains as a solution are not particularly interested in many Dapp applications and have not tried them. Therefore, they have never considered the complexity of building a distributed exchange and the security required for almost every action of each user. Most Bitcoin developers seem to be open to what they are interested in and clearly know 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 remained scarce. The point of this article is to emphasize that the main driving force behind this situation is not necessary fees or Ethereum’s virtual machine and stronger technical capabilities, but rather that many Bitcoiners and Bitcoin developers do not want Dapps on Bitcoin, they are not interested in these features of Bitcoin. Some Bitcoin supporters believe that most Dapp activities are associated with unsustainable scams, or for security or other reasons, such 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 complete blocks and higher fees, and 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 a certain extent. Nevertheless, whether Bitcoiners care enough about these protocols on Bitcoin, let alone whether anyone is really building and using them, remains an open question.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
