A look back at the 2014 OP_Return debate from the Ordinals debate: Dapps vs Bitcoin trading

Original source: BitMEX Research

The ;OP_RETURN; debate in ;2014; was a notable split within the industry and has many similarities to today's ;Ordinals; debate. Looking back, the ;OP_RETURN; debate is particularly meaningful today.

• Some bitcoin enthusiasts and bitcoin developers who simply don't want this kind of activity on the bitcoin blockchain have successfully blocked;OP_RETURN;this kind of activity. Meanwhile, promoters of other chains like Ethereum may have taken advantage of and exaggerated this apparent stance of Bitcoin developers to help their ecosystem gain traction.

Overview

We are often asked the question: Why are Dapps such as decentralized exchanges usually on Ethereum instead of Bitcoin? After all, it is of course 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 it easier to build Dapps; ii. Ethereum's faster block times make Dapps more user-friendly, or iii. Bitcoin's choice More conservative block size limits than Ethereum, resulting in potentially higher fees for Bitcoin. All of the above factors do have an impact, but we believe their impact is often overstated. The most important factor is culture. Some bitcoin enthusiasts and bitcoin developers simply do not want such activity on the bitcoin blockchain, and they have successfully blocked it. This seems to have mostly happened around March 2014, and what happened around that time is the subject of this article. Meanwhile, promoters of other chains like Ethereum may have taken advantage of and exaggerated this apparent stance of Bitcoin developers to help their ecosystem gain traction.

Counterparty protocol

As mentioned in our September 2020 report, in early 2014, Counterparty launched. Counterparty is a protocol layer on top of Bitcoin that enables features such as creating new tokens and trading those tokens on distributed exchanges. The system works by taking parts of bitcoin transaction data and using it in counterparty agreements as a function, such as creating tokens, sending tokens, or making market bids for tokens on a distributed exchange.

More succinctly, at the beginning, Counterparty included Counterparty-related data into the Bitcoin blockchain using the Bitcoin opcode OP_CHECKMULTISIG. This opcode should be used to verify the signature of a Payment Script Hash (P;2 SH) multi-signature transaction. A sample Counterpaty transaction from July 2014 can be viewed here. The transaction sends the bitcoin back to the address it came from, and also has three additional outputs, where the output script is data related to the counterparty agreement. In this case, it is creating a new token called TICKET. Using OP_CHECKMULTISIG can be considered a hack, since that's not the intended use of the opcode. Counterparty now uses Bitcoin's OP_Return opcode to store data, which is somewhat more in line with the developer's intent. For example, see this updated Counterparty transaction that uses OP_Return.

In early 2014, there was a lot of experimentation, developer activity, innovation and excitement around Counterparty, ahead of a rival 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 on the bitcoin blockchain. Since the data is not part of the UTXO set, it is said that storing data in this way helps Bitcoin scale because nodes participating in the pruning do not need to store OP_Return data.

Bitcoin's consensus rules allow a maximum OP_Return size of 10,;000 bytes. For example; in May 2013, this feature was exploited in the following transaction. The OP_Return output in this transaction contains lyrics from Rick Astley's 1987 song "Never Gonna Give You Up," which is related to the Rickrolling meme.

Prior to 2014, transactions containing OP_Return were non-standard and not relayed by normal Bitcoin nodes. However, if miners include these transactions, they are considered valid. In March 2014, Bitcoin Core 0.9.0 was released, which included the OP_Return function as a standard transaction type, so transactions will be relayed by default. The release notes at the time were as follows:

This change is not an endorsement of storing data on the blockchain. The OP_RETURN change creates provably prunable outputs to avoid data storage schemes (some of which are already deployed) that store arbitrary data (such as images) as TX outputs that are never available, bloating Bitcoin's UTXO database. Storing arbitrary data in the blockchain is still a bad idea; it is cheaper and more efficient to store non-monetary data elsewhere.

source:

Bitcoin Core 0.9.0 will only relay transactions with OP_Return of 40 bytes or less, if the data is larger than this, it will still be a valid transaction, but will not be relayed. The original limit was 80 bytes, but after much debate, the developers settled on 40 bytes.

In 2016, Bitcoin Core 0.11.1 finally increased the relay limit to 80 bytes, and in late 2016 the Bitcoin Core 0.12.0 release increased it to 83 bytes, our limit today. This means that if you want a transaction with an OP_Return output of more than 83 bytes today, you have to mine the block yourself or send it directly to the miner.

OP_Return War

On March 20, 2014, Jeff Garzik, then one of Bitcoin's leading contributors, began posting on the Counterparty forum on the Bitcointalk forum. Jeff criticized Counterparty's use of the blockchain space.

To date, I have not seen a blockchain data dump scheme that cannot be safely replaced with a simple hash. You don't need to store data in the blockchain. That's pure intellectual laziness. Timestamped hashes (data) are just as secure, while more efficient. Additionally, a secondary chain can be provably pegged to Bitcoin:

source:

Jeff went on to say:

CheckMultiSig obviously works with ECDSA public keys, not arbitrary data. It should come as no surprise that using an operation for something other than its intended purpose can have negative, possibly unintended, or unknown consequences. Counterparty transactions are not "according to the Bitcoin protocol", they go through because it was never expected to use the feature in this way.

source:

One might think it's odd that Jeff has this view, since he seems to be a "big block supporter" in 2017, and this view of conservative use of block space seems to be at odds with the large block view. However, this apparent inconsistency did not arise at all in 2014. At that time, Jeff’s views were to a certain extent recognized by almost all active developers at that time, including those who later became the heads of large blocks. As far as we know, there is simply no simple mapping between people's perceptions of block size limits and this question. Jeff was a well-respected developer at the time, and this article got a lot of attention from both Counterparty developers and users.

A Counterparty developer with the pseudonym "BitcoinTangibleTrust" replied to Jeff as follows:

You are absolutely right. You don't need to store data in the blockchain. Timestamped hashes (data) are just as secure, while more efficient. A secondary chain can be provably pegged to Bitcoin. However, according to [Counterparty co-founder and lead developer] at PhantomPhreak below, Counterparty IS using 256 bytes to store data in the blockchain in one of every three multisig transactions. Also, all these multisig transactions are processed by miners.

The developer went on to criticize the Bitcoin devs for planning to limit OP_Return to 40 bytes instead of 80:

If OP_RETURN is designed to stop/reduce multisig behavior (unspent outputs) and thus reduce blockchain bloat, then I fear that by reducing the size of OP_RETURN from 80 bytes to 40 bytes, you will inadvertently In making multisig more attractive to all meta-protocols, you've made OP_RETURN less attractive.

Lead Counterparty developer and co-founder known as "PhantomPhreak" chimed in:

The idea is that we store the data in a second blockchain and put hashes of that timestamp data into Bitcoin, and those hashes will also be less than 40 bytes. The reason we didn't do this wasn't "intellectual laziness" but implementation complexity. Counterparty is not a computer science project; it was designed to be as simple as possible in order to increase development speed. Even if we have to store data in multisignature output, not OP_RETURN output which is too small. In this field, worse is definitely better.

Jeff responded the next day:

This is hitchhiking. Given that the vast majority (>90%;) of Bitcoin's blockchain applications are currency usage, using full nodes as dumb data storage terminals is just an abuse of fully voluntary network resources. The network replicates transaction data, so why not free ride? Instead of participating in the existing community, mastercoin and Counterparty simply flipped the "on" switch and started using Bitcoin P;2 P nodes as unneeded data storage. Unspent transaction outputs are by no means intended to be used as arbitrary data storage. The fact that it can be abused doesn't make it correct, or remotely effective, or the best solution. The UTXO (Unspent Transaction Output) database is a fast-access database for the entire network. Each node needs this database to be as small as possible in order to best handle network transactions. Encoding arbitrary data into unconsumed output is a network-wide abuse, plain and simple. The entire network bears this price.

source:

Because of Jeff's high status in the community, most people in the Counterparty community seem keen to get involved and fix the issue. For example, BitcoinTangibleTrust responded:

Thanks for sharing your thoughts, Jeff. So, will you help us start engaging with the existing Bitcoin Core development community? It is in Counterparty's interest to act as a responsible partner because we need the Bitcoin blockchain if we are to survive. Can you tell us how to start collaborating on these issues?

source:

Another Counterparty developer made another point:

Is there a way for the Bitcoin protocol to stop the way XCP uses it without breaking anything else?

If the Bitcoin developers had no way to prevent counterparty-related transactions, perhaps this objection would not matter, and Counterparty could continue to use Bitcoin without permission. Bitcoin developer and then mining pool operator Luke-Jr then entered the debate:

Miners should filter out abuse.

source:

Luke-Jr then suggested that these types of systems could be built using a merge-mined sidechain type structure, which would avoid blockchain bloat.

The problem is not the new layer, but the imposition on people against their will. New layers can be done on an opt-in basis without polluting the blockchain and forcing non-participants to store data.

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

• Too many people think OP_RETURN is a function and should be used. It was never intended as such, just a way of "leaving the windows 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 is enough for all legal needs to bind data to a transaction: you get 32 bytes for the hash, plus 8 bytes for some kind of unique identifier (which is also not really necessary !).
• The original 80-byte proposal was intended for a 512-bit hash, but was determined to be unnecessary.

Luke-Jr continued:

Hopefully, as mining returns to decentralization, we'll see less tolerance for abusive/spam transactions, whether it's the OP_RETURN variant or otherwise. Now, if someone has a valid, necessary use case for actually storing hashes with transactions, then obviously miners should seriously consider mining.

source:

Luke's mining pool at the time also began filtering out Counterparty-related transactions. This is when fear and uncertainty began to build in the Counterparty community. They need OP_Return to be 80 bytes, otherwise they will be forced to continue using the OP_CHECKMULTISIG opcode. Given Luke's comment, it seems unlikely that it will get to 80 bytes. Beyond that, some fear that the developers will lower the limit even further, potentially taking Counterparty off the network. Bitcoin developers don't seem to be particularly friendly to Counterparty, so some may think that continuing to use the Bitcoin protocol might be difficult.

On March 25, 2014, Vitalik Buterin, the main founder of Ethereum, chimed in, arguing that the debate should revolve more around fees, and that if you pay enough fees, then your transaction should be legally included in a 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. One could argue that SegWit on Bitcoin also alleviates this problem to some extent.

This is the fault of the protocol, and the OPRETURN fight is such a problem. In an ideal world, the concept of "abuse" would not exist at all; fees would be mandatory and carefully designed to closely match the actual cost a given transaction imposes on the network," he said. "If you could Pay for what is being done, then you should be able to do it, no questions asked. "

source:

On March 27, 2014, Counterparty changed the transaction method to bypass Luke-Jr's mining filter. However, the next day Luke commented:

good news! In less than 5 minutes and 1 line of code, you can add a filter to block this useless stuff.

source:

Luke-Jr also likened Counterparty to a form of abuse:

This is an abuse because you force others to download/store your data according to their free choice. Every full node must download the full blockchain (prunable 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 (ie, not miners; not developers) or even a majority. Also, everyone is free to store data that is not in the blockchain. There's no benefit to having it in the blockchain, it's just that you're forcing it on people who don't want it. You explain how this isn't abuse...

source:

Anger against bitcoin devs

As one might expect, the concerns of Bitcoin developers were ultimately met with frustration and anger from some Counterparty developers and users. We've included some of their reviews below. First a comment from a user named "porqupine" about Luke-Jr's pool blocking Counterparty transactions:

That's fine compared to its developers who are responsibly committed to finding a solution - you're promoting a game of cat and mouse. Did you realize you were talking about net neutrality too? And trying to put into private hands the transactions that people should and shouldn't be doing on the blockchain. What's the next step in sanctioning someone you don't like? Sanctions for broadcasting transactions at nodes in countries where you disapprove of the government's foreign policy?

source:

On March 21, 2014, porqupine continued:

Wait a minute, when it decides: Every node agrees to store type X data instead of type Y data. Maybe I also don't agree with storing transactions for money laundering, illegal drugs and weapons, human slavery, etc. You're basically negating protocol neutrality and deciding what the protocol should and shouldn't be used to store, not just you' Not speaking in the first person, but using the pronoun Us, giving the impression that you're representing all Miners or protocol users speak as a whole.

source:

Others expressed concerns about why Jeff and Luke have the power to bypass others to block certain use cases.

I can't believe this attitude. I didn't know bitcoins had owners. I thought I and about a million other people were the owners

Counterparty co-founder PhantomPhreak said:

First, Counterparty transactions are financial transactions. Second, every full node agrees to download and store the Bitcoin blockchain. That is, transactions that conform to the Bitcoin protocol, Counterparty transactions apparently do. For god's sake, Satoshi embedded a political message in the genesis block...you have a much narrower view of bitcoin's possible use cases than others.

source:

He or she continues:

Bitcoin does a lot of things it wasn't meant to do. Yes, we'd really like to use a more elegant solution than what we have now. Counterparty was originally designed to use the OP_RETURN output to store all of its message data, which I find very elegant and has minimal impact on the blockchain. We plan to format all messages around the 80-byte limit Gavin announced on the official Bitcoin blog. We only use multisignature outputs because we have no choice. We don't want to extend the Bitcoin protocol. We want to do something entirely in it, and as simple and straightforward as possible, for the benefits of stability, security, etc.

source:

Likewise, 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 a pain for full node storage than anything else.

source:

Another user named "bitwhizz" said:

If you don't want to store it, don't, pretty simple, don't use bitcoin, don't download the blockchain, your scott is free. However, my agreement means that I believe that Bitcoin not only has a transaction function, but based on the fact that no one has it, and there is an OP_RETURN function, I don't see why this function should be eradicated, because you don't want to store. You can already Data of free choice.

source:

"Anotheranonlol" said:

I really can't understand how a Counterparty transaction doesn't constitute a financial transaction? I also can't understand the point of view, because say, 1 node in 1000 is not willing to accept this data and should be banned by default. After the recent nightmare of mt.gox and the numerous hacks, thefts, shutdowns and losses caused by storing your balances on centralized entities, it seems that Counterparty has come up with a solution that allows a go A centralized, trustless solution to this problem.

source:

"Baddw" said:

In fact, anyone can store arbitrary data on the blockchain at any time. It has been and is being used for this purpose. Everyone who runs a Bitcoin node should already know this, and if they don't, it should be part of the notification that came up when they installed Bitcoin-QT (if there was one; I don't recall seeing it). Any Bitcoin transaction could be a simple movement of money, or a love letter, or a trigger to detonate a bomb. Removing that possibility would kill Bitcoin.

source:

Baddw continued:

Many of the greatest developments in the history of computing (and indeed the entire history of human technology) have been the result of people discovering things their inventors had no intention of using. The good thing is that most inventors are not that protective of their inventions, and they don't refuse to let others use them for new things. Those who did, found themselves quickly surpassed.

source:

It is clear from these comments that many Counterparty users and developers are surprised and disappointed by the position of the Bitcoin developers. While the project continues, and so does Mastercoin, it is likely, for better or worse, that some developers have left Bitcoin as a result and built their protocols on other blockchain systems such as Ethereum. In our view, it is this moment of 2014 that is more important than any other. However, others may see it differently.

Merge-mined sidechains

Throughout the OP_Return debate, Counterparty and opponents of blockchain bloat typically refer to some form of merged mining sidechains as a solution for Dapps. In fact, Satoshi Nakamoto is said to have liked this path, and is said to have endorsed it for use in the domain name system in December 2010:

I think it is possible for BitDNS to be a completely separate network and separate blockchain, but share CPU power with Bitcoin. The only overlap is the proof-of-work that allows miners to search both networks simultaneously.

source:

There are many difficulties in implementing these Dapp systems as sidechains, and we understand these weaknesses better than we did in 2014, when many people just thought they could work.

• Complexity - One of the most important 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 build sidechains and merged mining systems with Bitcoin.
• Bitcoin as a native asset - It may not be possible to use non-custodial Bitcoin as an operating asset on a sidechain, as it may not be possible to establish a trustless two-way peg. This is a great weakness for many Dapps, for example they may wish to use Bitcoin as the main trading pair on a distributed exchange. This weakness doesn't seem to be well understood in 2014, and many people just assume it works somehow.
• Limited scaling benefits - the benefits of using sidechains may vary by use case. For example, if a distributed exchange were to be built, every bid, offer, and match would likely require all the security of the main chain. With so many uses of the main chain, for every possible action of every user on the exchange, the scaling advantages of the side chain system may be very limited. Submitting bids locally on-chain might only use about 90 bytes, while storing the hash of the order information and the structure and overhead needed to identify it might be about 50 bytes on-chain, so it wouldn't save much space.

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

Also, unless I'm overlooking something here, we still need to parse out the data from the blocks in the second blockchain (at least assuming it's a bitcoin or bitcoin-derived implementation) to get the data we store . Therefore: * It will not enable SPV type Counterparty clients because of the colored coins features provided by Counterparty (i.e. DEx, betting, asset callbacks, dividends, CFDs, etc.) * It will reduce the security of Counterparty transactions. This would greatly increase the complexity of the implementation (i.e. increase the chances of bugs and bugs), with the only dubious benefit being a slight * reduction in our storage requirements for the blockchain (i.e. maybe 20-40 bytes less per transaction?). I just don't see what that means here. One more point: Counterparty can bring huge benefits to Bitcoin, which will become more apparent if/as Ethereum (and other similar non-Bitcoin meta ";2.0;" type coins) come into view. 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) crowd's feature list and appeal - or risk being eliminated, at least This is true among investors and financial market operators, and this provides the ability to bring billions or even trillions of dollars into the Bitcoin ecosystem as it gains more recognition, trust, and mind-sharing.

source:

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 never considered the complexity of building a distributed exchange, and the need for security for almost every action of every user. Most Bitcoin developers seem to be open to what they are interested in and have a good idea of what they want: censorship resistant money, non-political money, electronic cash, etc...

in conclusion

After 2014 or so, most developers interested in Dapps focused on building on Ethereum or other systems, not on Bitcoin. Ethereum subsequently gained a lot of developer interest and momentum, while Dapp development on Bitcoin was minimal. The point of this post is to emphasize that the main driver of this isn't the necessary fees, nor is Ethereum's virtual machine and Ethereum's greater technical capabilities, it's just that many Bitcoiners and Bitcoin developers don't want Dapps on Bitcoin, they are not interested in Bitcoin. these functions. For better or worse, some Bitcoiners deliberately drove many of these Dapp developers away. Some Bitcoin proponents argue that most dapp activity is related to unsustainable scams, or that such activity is undesirable on Bitcoin for security or other reasons.

Since 2014, many people's views have changed. Bitcoin needs transaction fees to survive. In a post-2016 environment where we have many full blocks and higher fees, there is a more general perception that any payment transaction is "legitimate". Certain Dapps on Ethereum, such as exchanges like Uniswap, or lending protocols like AAVE and Compound, have proven to be both successful and interesting to some degree. Still, it's an open question whether Bitcoiners care enough about these protocols on Bitcoin, let alone whether anyone actually builds and uses them.