BitMEX Research: Why did Bitcoin lose to Ethereum in the Dapp battle?
Original author:BitMEX Research
Compilation of the original text: The Way of DeFi
Summary:Compilation of the original text: The Way of DeFi
overview
Summary:
In this post we explore why Dapps are often built on Ethereum rather than Bitcoin, going all the way back to March 2014. We examine the debate over whether and how a Dapp protocol called Counterparty could use the Bitcoin blockchain. This is sometimes referred to as the "OP_Return fight". We explain the history of OP_Return usage and sidechains in Bitcoin. In the end, whether people like it or not, we think it's the culture of the Bitcoin dev community in 2014 and the negative view of using Bitcoin transaction data for alternative use cases, which is driving developers of these Dapps to alternative systems like Ethereum It played an important role.
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. 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.
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 (P2 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, which uses OP_Return.
In early 2014, there was a lot of experimentation, developer activity, innovation and excitement surrounding Counterparty, ahead of a rival platform called Mastercoin.
What is OP_Return?
Bitcoin's consensus rules allow a maximum OP_Return size of 10,000 bytes. For example, in May 2013, this functionality was exploited in the following transaction. The OP_Return output from this transaction contains lyrics from Rick Astley's 1987 song "Never Gonna Give You Up," which is related to the Rickrolling meme.
source:https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain
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) from bloating Bitcoin's UTXO database by storing arbitrary data (such as images) as TX outputs that are never available. 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 an 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.
OP_Return War
source:https://bitcointalk.org/index.PHP?topic=395761.msg5796379#msg5796379
On March 20, 2014, Jeff Garzik, one of the main contributors to Bitcoin at the time, began posting on the Counterparty section of the Bitcointalk forum. Jeff criticized Counterparty's use of the blockchain space.
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5827189#msg5827189
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 developers' plan 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 make multisig More attractive to all meta-protocols, and you've made OP_RETURN less attractive.
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 outputs instead of OP_RETURN outputs which are too small. In this field, worse is definitely better.
source:https://bitcointalk.org/index.PHP?topic=395761.msg5815887#msg5815887
Jeff responded the next day:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5816031#msg5816031
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:
Is there a way for the Bitcoin protocol to stop the way XCP uses it without breaking anything else?
source:https://bitcointalk.org/index.PHP?topic=395761.msg5816503#msg5816503
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.
The original 80-byte proposal was intended for a 512-bit hash, but was determined to be unnecessary.
source:https://bitcointalk.org/index.PHP?topic=395761.msg5817170#msg5817170
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.
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.
source:https://www.coindesk.com/markets/2014/03/25/developers-battle-over-bitcoin-block-chain/
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.
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5955613#msg5955613
On March 27, 2014, Counterparty changed the transaction method to bypass Luke-Jr's mining filter. However, the next day Luke commented:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5826443#msg5826443
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...
Outrage Against Bitcoin Developers
source:https://bitcointalk.org/index.PHP?topic=395761.msg5955738#msg5955738
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:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5826584#msg5826584
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:
I can't believe this attitude. I didn't know bitcoins had owners. I thought me and about a million other people were the owners 🙂
source:https://bitcointalk.org/index.PHP?topic=395761.msg5826770#msg5826770
Counterparty co-founder PhantomPhreak said:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5827473#msg5827473
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:https://bitcointalk.org/index.PHP?topic=395761.msg5827688#msg5827688
source:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5827897#msg5827897
Another user named "bitwhizz" said:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5827776#msg5827776
"Anotheranonlol" said:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5827749#msg5827749
"Baddw" said:
source:
source:https://bitcointalk.org/index.PHP?topic=395761.msg5827925#msg5827925
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:
Merged Mined Sidechains
source:https://bitcointalk.org/index.PHP?topic=1790.msg28696#msg28696
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.
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.
source:https://bitcointalk.org/index.PHP?topic=395761.msg5799174#msg5799174
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 (ie increase the chances of bugs and bugs), with the only dubious benefit being a slight* reduction in our storage requirements for the blockchain (ie 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 even 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.
in conclusion
source:
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.
