Abstract : 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 battle”. 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 development community in 2014 and the negative perception of using Bitcoin transaction data for alternative use cases, in terms of pushing developers of these Dapps into alternative systems like Ethereum It played an important role.
We are often asked the question: why are Dapps such as decentralized exchanges usually on Ethereum and not Bitcoin? After all, of course 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 it easier to build Dapps; ii. Ethereum’s faster block time makes Dapps more user friendly, or iii. Bitcoin choice A more conservative block size limit than Ethereum, resulting in higher potential fees for Bitcoin. All of the above 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 simply do not want such activity on the Bitcoin blockchain, and they have successfully prevented it. This seems to have mostly happened around March 2014, and what happened during that time is the subject of this article.
As we mentioned in our September 2020 report, in early 2014, Counterparty launched. Counterparty is a protocol layer on top of Bitcoin that supports functions such as creating new tokens and trading those tokens on a distributed exchange. The system works by taking part of Bitcoin transaction data and using it as a function in the counterparty agreement, such as creating tokens, sending tokens, or making market bids for tokens on a distributed exchange.
More succinctly, in the beginning, Counterparty used the Bitcoin opcode OP_CHECKMULTISIG to include Counterparty-related data into the Bitcoin blockchain. 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. This transaction sends 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 the creation of a new token called TICKET. Using OP_CHECKMULTISIG can be considered a hack, as this is 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 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 in the bitcoin blockchain. Since data is not part of the UTXO set, storing data in this way is said to help scale Bitcoin, as nodes participating in pruning do not need to store OP_Return data.
Bitcoin’s consensus rules allow an OP_Return size of up to 10,000 bytes. For example, in May 2013, someone took advantage of this feature in the following transaction. The OP_Return output in this transaction contains the lyrics to Rick Astley’s 1987 song “Never Gonna Give You Up”, which is related to the Rickrolling meme.
Before 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 would be relayed by default. The release notes at the time read as follows:
This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates provably pruable outputs to avoid data storage schemes (some of which have been deployed) storing arbitrary data (such as images) as never-available TX outputs, bloating Bitcoin’s UTXO database. Storing arbitrary data in a blockchain is still a bad idea; it is cheaper and more efficient to store non-monetary data elsewhere.
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 is still 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 the Bitcoin Core 0.12.0 release in late 2016, it was increased to 83 bytes, the limit we have 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.
On March 20, 2014, Jeff Garzik, one of the main contributors to Bitcoin at the time, started posting on the Counterparty section of 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 on the blockchain. That is sheer intellectual laziness. Timestamp hashes (data) are equally secure, while more efficient. Additionally, a secondary chain can be provably pegged to Bitcoin:
Jeff went on to say:
CheckMultiSig apparently works with ECDSA public keys, not arbitrary data. It’s not surprising that using an operation for something other than its intended purpose has negative, possibly unintended, or unknown consequences. Counterparty transactions are not “according to the Bitcoin protocol”, they will pass because it was never expected to use the feature in this way.
One might find it odd that Jeff has this view, since in 2017 he appeared to be a “big block proponent” and this view of conservative use of block space seems to be at odds with the big block view. However, this apparent inconsistency did not materialize in 2014 at all. At that time, Jeff’s views were shared to a certain extent by almost all active developers at the time, including those who later became big block leaders. As far as we know, there is simply no simple mapping between people’s perceptions of the block size limit and this issue. Jeff was a well-respected developer at the time, and this article caught a lot of attention from Counterparty developers and users.
A Counterparty developer who goes by the alias “BitcoinTangibleTrust” replied to Jeff as follows:
You are absolutely right. You don’t need to store data on the blockchain. Timestamp hashes (data) are equally secure, while more efficient. A secondary chain can be provably pegged to Bitcoin. However, according to PhantomPhreak’s [Counterparty co-founder and lead developer] below, Counterparty IS uses 256 bytes to store data in the blockchain in one of every three multi-signature transactions. Also, all these multi-signature transactions are processed by miners.
The developer went on to criticize the Bitcoin developer’s plan to limit OP_Return to 40 bytes instead of 80:
If OP_RETURN is designed to stop/reduce multi-signature behavior (unspent outputs) and thus reduce blockchain bloat, then I’m concerned that by reducing the size of OP_RETURN from 80 bytes to 40 bytes, you will inadvertently make multi-signature More attractive to all meta-protocols, and you’ve made OP_RETURN less attractive.
The lead Counterparty developer and co-founder named “PhantomPhreak” chimed in:
The idea is that we store the data in a second blockchain and put hashes of that timestamp data into bitcoins, and those hashes will also be less than 40 bytes. The reason we didn’t do this was not “intellectual laziness” but the complexity of the implementation. Counterparty is not a computer science project; it was designed to be as simple as possible in order to speed up development. Even if we have to store the data in the multi-signature output, not the too small OP_RETURN output. In this field, worse is definitely better.
Jeff responded the next day:
This is hitchhiking. Given that the vast majority (>90%) of Bitcoin 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 hitch a ride? Instead of participating in existing communities, mastercoin and Counterparty simply hit the “on” switch and started using Bitcoin P2 P nodes as unwanted data storage. Unused transaction outputs are never intended to be used as arbitrary data storage. The fact that it can be abused doesn’t make it correct, or remotely valid, 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 an unused output is a network-wide abuse, plain and simple. The entire network bears the cost.
Due to Jeff’s high status in the community, most in the Counterparty community seem keen to get involved and solve the problem. For example, BitcoinTangibleTrust responded:
Thanks for sharing your thoughts, Jeff. So, will you help us start interacting 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 working together on these issues?
Another Counterparty developer made another point:
Is there a way for the Bitcoin protocol to prevent XCP from using it the way it does, without breaking anything else?
If there is no way for Bitcoin developers to prevent counterparty-related transactions, perhaps this objection does not matter, and Counterparty can continue to use Bitcoin without permission. Bitcoin developer and then-mining pool operator Luke-Jr then entered the debate:
Miners should filter out abuse.
Luke-Jr then suggested that these types of systems could be built using merge-mined sidechain-type structures, which would avoid blockchain bloat.
The problem is not the new layer, but it is imposed 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 original proposed limit of 80 bytes. Luke responded with three points:
- Too many people think OP_RETURN is a feature and should be used. It was never intended to be that way, just a way to “keep the windows unlocked so we don’t need to replace the glass when someone breaks in”. That is, reducing the damage caused by people misusing Bitcoin.
- 40 bytes is enough for all legitimate needs of binding data to a transaction: you get 32 bytes for hashing, plus 8 bytes for some kind of unique identifier (which isn’t really necessary either! ).
- The original 80-byte proposal was intended for 512-bit hashing, but was determined to be unnecessary.
Hopefully, as mining returns to decentralization, we will see less tolerance for abusive/spam transactions, be it the OP_RETURN variant or the other. Now, if anyone 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 started filtering out Counterparty-related transactions. At this point fear and uncertainty started 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 it will hit 80 bytes. Beyond that, some fear that 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 might think it might be difficult to continue using the Bitcoin protocol.
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, 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. One could argue that SegWit on Bitcoin also alleviates this problem to some extent.
It’s a protocol bug, and OPRETURN battles are 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 costs imposed on the network by a given transaction,” he said. Paying for what is being done, then you should be able to do it without asking any questions. “
On March 27, 2014, Counterparty changed the way it traded 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 filters to stop this useless stuff.
Luke-Jr also likened Counterparty to a form of abuse:
This is abuse because you force others to download/store your data according to their free choice. Every full node must download the full blockchain (pruned 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 putting it in the blockchain, you’re just imposing it on people who don’t want it. You explain how this isn’t abuse…
Anger at Bitcoin developers
As one might expect, Bitcoin developer concerns ended up being met with frustration and anger from some Counterparty developers and users. We’ve included some of their reviews below. First from a user named “porqupine” commenting on Luke-Jr’s mining pool blocking Counterparty transactions:
Compared to developers responsibly working on finding solutions, that’s fine – you’re promoting a cat-and-mouse game. You realize you’re 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 sanction for someone you don’t like? Sanctions for broadcasting transactions on nodes in countries where you disapprove of government foreign policy?
On March 21, 2014, porqupine continued:
Wait, when it decides: every node agrees to store data of type X instead of type Y. Maybe I also don’t agree with storing money laundering, illegal drugs and weapons, human slavery, etc. You’re basically negating protocol neutrality and deciding what protocol should and shouldn’t be used to store, not just you’ instead of speaking in the first person, you’re using the pronoun Us, giving the impression that you’re representing all Miners or protocol users speak as a group.
Others expressed concerns about why Jeff and Luke have the power to override others to block certain use cases.
I can’t believe this attitude. I didn’t know bitcoin had an owner. I thought I and about a million others were the owners?
Counterparty co-founder Phantom Phreak said:
First, Counterparty transactions are financial transactions. Second, every full node agrees to download and store the Bitcoin blockchain. That said, transactions that conform to the Bitcoin protocol, Counterparty transactions apparently do. For God’s sake, Satoshi Nakamoto embedded a political message in the genesis block…you have a much narrower view of possible use cases for bitcoin than others.
He or she goes on to say:
Bitcoin does a lot of things it wasn’t originally intended to do. Yes, we’d really like to use a more elegant solution than 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 all message formats to revolve around the 80-byte limit announced by Gavin on the official Bitcoin blog. We only use multi-signature outputs because we have no choice. We don’t want to extend the Bitcoin protocol. We want to do something entirely in it, and be as simple and direct as possible for the benefits of stability, security, etc.
Again, we only store financial transactions in the blockchain, and we’re paying for the space we’re using. Financial transactions in OP_RETURN outputs are no more painful to full node storage than anything else.
Another user called “bitwhizz” said:
If you don’t want to store it, don’t, fairly simple, don’t use bitcoin, don’t download the blockchain, your scott is free. However, my agreement means that I believe Bitcoin not only has transaction capabilities, and based on the fact that no one has it, and has an OP_RETURN feature, I don’t see why that feature should be eradicated, since you don’t want to store your already free choice The data.
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 out of 1000 nodes is not willing to accept this data and should be banned by default. After the most recent nightmare was mt.gox and numerous hacks, thefts, shutdowns, and losses due to storing your balances on centralized entities, it seems that Counterparty has come up with a solution that allows a de- A centralized, trustless solution to this problem.
In fact, anyone can store arbitrary data in the blockchain at any time. It has been and is being used for this purpose. Everyone 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 recall seeing it). Any bitcoin transaction could be a simple flow of money, a love letter, or a trigger to detonate a bomb. Eliminating this possibility would kill Bitcoin.
Baddw went on to say:
Many of the greatest developments in the history of computing (and indeed the entire history of human technology) were the result of people discovering things their inventors had no intention of using. The good thing is that most inventors don’t have that much protection for their inventions, and they don’t refuse to let others use them for new things. Those who do, find themselves quickly surpassed.
It’s clear from these comments that many Counterparty users and developers were surprised and disappointed by the Bitcoin developers’ stance. While the project continues, and so does Mastercoin, it’s likely, for better or worse, that some developers have left Bitcoin as a result to build their protocols on other blockchain systems such as Ethereum. In our opinion, it is this moment in 2014 that is more important than any other. However, others may have a different opinion.
Merged Mining Sidechains
Throughout the OP_Return debate, Counterparty and opponents of blockchain bloat often refer to some form of merged mining sidechains as a solution for Dapps. In fact, Satoshi Nakamoto is said to like this path and is said to have backed it for the Domain Name System in December 2010:
I think BitDNS has the potential to be a completely separate network and separate blockchain, but sharing CPU power with Bitcoin. The only overlap is allowing miners to search both networks for proof-of-work at the same time.
There are many difficulties in implementing these Dapp systems as sidechains, and we understand these weaknesses better than in 2014, when many people just thought they would 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 merge mining systems with Bitcoin.
Bitcoin as a native asset – It may not be possible to have non-custodial Bitcoin as an operational asset on a sidechain, as it may not be possible to establish a trustless two-way peg. This is a big weakness for many Dapps, for example they may want to use Bitcoin as the main trading pair for a distributed exchange. This weakness doesn’t seem to be well understood in 2014, and many just assumed it could work 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, bid and match would likely require all the security of the main chain. With so much mainchain usage, the scaling benefits of sidechain systems can be very limited for every possible action by each user on the exchange. Submitting a bid locally on-chain might only use about 90 bytes, while storing the hash of the order information and the structures and overheads that need to be identified might be about 50 bytes on-chain, so it won’t save much space.
In March 2014, Counterparty developer (xnova) outlined his objections 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 Bitcoin or a Bitcoin-derived implementation) to get the data we store . Therefore: * It will not enable the SPV type of Counterparty client, because of the colored coin features provided by Counterparty (ie 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 chance of bugs and bugs), and the only dubious benefit is slightly* reducing our storage requirements on the blockchain (i.e. maybe 20-40 bytes less per transaction?). I just don’t understand what this 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 in the ecosystem with this capability 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, which provides the ability to bring billions or even trillions of dollars into the Bitcoin ecosystem as it gains more recognition, trust, and idea sharing.
It seems that some people who support sidechains as a solution are not particularly interested in many Dapp applications and have not tried them. Therefore, they never considered the complexities 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 know exactly what they want: censorship-resistant money, non-political money, electronic cash, etc…
After around 2014, most developers interested in Dapps focused on building on Ethereum or other systems, not 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 is not the necessary fees nor 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 drive away many of these Dapp developers. Some Bitcoin proponents believe that most Dapp activity is related to unsustainable scams or that such activity is not desirable on Bitcoin for security or other reasons.
Many people’s views have changed since 2014. Bitcoin needs transaction fees to survive. In a post-2016 environment where we have many full blocks and higher fees, it is more generally accepted that any paid transaction is “legal”. Certain Dapps on Ethereum, such as exchanges such as Uniswap, or lending protocols such as AAVE and Compound, have proven to be both successful and interesting to some extent. Still, it’s an open question whether Bitcoiners care enough about these protocols on Bitcoin, let alone whether anyone actually builds and uses them.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/looking-back-at-history-why-bitcoin-lost-to-ethereum-in-dapp-battle/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.