The IOG team strives to make Cardano decentralized not only at the block production but also at the project management level. Most blockchain projects, if not all, still have centralized project management. Bitcoin is said to be the only project that is completely decentralized since Satoshi left it. The Cardano community should keep a close eye on the debate happening around the Ordinals project which allows minting NFTs on Bitcoin. Prominent figures in the Bitcoin ecosystem call for censorship of transactions and are capable of enforcing their will. This has happened several times in the past. People should understand that every project has a team of developers and they can have a big impact on the project. The goal of decentralized governance is to distribute decision-making power so that it is not held solely by the team. All cryptocurrency fans should care about Bitcoin being decentralized even at the project management level. As you'll see, it's not as simple as it looks at first glance. Let's take a look into Bitcoin's past at one of the hot debates that have now returned. We'll be interested in this mainly in the context of governance. TLDR Taproot upgrade made it unwittingly possible to mint NFTs on Bitcoin. During the OP_RETURN war, the core developers decided that there would be no alternative use cases for Bitcoin. Prominent figures in the Bitcoin community have proposed censorship of transactions that contain NFTs. The IOG team has not yet handed over project management responsibilities to the community. The Cardano community should know Bitcoin's past to learn from it. NFT and other use cases on Bitcoin today and in the past Former Bitcoin core developer Casey Rodarmor has launched the Ordinals project which allows the creation of NFTs on Bitcoin. Ordinals take advantage of the Taproot upgrade that allows storing the NFT data in Taproot script-path spend scripts. Taproot relaxed the limits on witness data sizes in a Bitcoin transaction. It is possible to create a kind of data envelope to store arbitrary data. For example NFTs. However, that wasn’t the intention of the Taproot upgrade. Just to add context. NFTs on Ordinals are stored directly on-chain. Cardano uses external storage to store NFTs. Only the token whose metadata contains information about the NFT, including the link to the image, is stored in the ledger. Why does the Ordinals project pose such a problem now? To understand this, you have to go back in time. The Ordinals project is not the first project that wanted to use Bitcoin for purposes other than normal financial transactions. Similar attempts have been made in the past and there has been a wave of opposition. If you wanted to create something over Bitcoin in the past, you needed to use opcodes. An opcode is a basic command in some computer languages. Bitcoin's scripting language, called Script, has its own set of opcodes. For example, OP_RETURN. OP_RETURN is a transaction output in Bitcoin that is provably unspendable. The function can be used to burn Bitcoin or store arbitrary data in the Bitcoin blockchain. Since the data is not part of the UTXO set, storing data this way is said to help scale Bitcoin, as nodes that engage 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. It was possible to store text, an image, a song, or even a video on the Bitcoin blockchain. Block space is an important component for creating additional functionality. The Bitcoin development community didn't like that the protocol was being used for things other than financial transactions. This started the so-called the OP_RETURN war in 2014. The negative views of core Bitcoin devs on the use of transaction data for alternative use cases, along with other factors played a major role in Dapps developers switching to alternative systems. After some heated debates, OP_RETURN ended up with a size of 80 bytes. A large number of talented developers have started migrating to other blockchains. Although it was very difficult to use Bitcoin for anything other than financial transactions, several projects had been created. Between 2018 and 2019, about 20% of transactions included OP_RETURN. These transactions were for things like Omni, Counterparty, and Veriblock. The first version of the Tether project was on Bitcoin, NFTs existed on it, and Bitcoin served as a security provider. Veriblock and Omni added about 10GB to the Bitcoin blockchain in 32 million transactions that all bitcoin nodes have to download forever. Nowadays, OP_RETURN is hardly used. However, the Taproot design unwittingly has allowed limitless Bitcoin data storage without the need to use OP_RETURN at all. This brings the Bitcoin community back to the debate around the OP_RETURN war. We've simplified the history around the OP_RETURN war, but be sure to find more information about it. What is important in the context of this article is who decided on the changes to the protocol and how, and what the consequences were. Furthermore, whether the debate was comprehensive and included all important aspects. In the debate around the Ordinals project, we see prominent figures endorsing transaction censorship and debating the rest of the community from a position of power. What is important in the context of decentralized governance? Note that the size of OP_RETURN was decided by the Bitcoin core developers and they were able to prevent those who tried to use the protocol from doing so. All the core developers had to do was modify the source code. Bitcoin pool Luke-Jr, operated by the Bitcoin core developer Luke Dashjr, began censoring transactions containing OP_RETURN. Some developers have accused the core developers of usurping power into their own hands and doing what they want instead of looking for a common solution. Project Ordinals shows us that nothing has changed in the approach of Bitcoin core developers. Adam Back, CEO of Blockstream, tweeted: "It's also fair game for miners to censor the crap as a form of discouragement." Adam later deleted the tweet and changed the view. “We can recognize we can't really stop them and it's a free world with anonymous miners. But we can also educate and encourage developers who care about Bitcoin's use case to either not do that or do it in a prunable space-efficient e.g. time-stamp way.” Luke Dashjr, the same person who censored OP_RETURN transactions in the past, added to the original Adam’s tweet: “Is anyone working on a spam filter for this garbage yet?” How to perceive this? Bitcoin devs introduced Taproot and perhaps didn't realize that they were opening up new possibilities that were not intended. Is it fair to solve this problem through transaction censorship as Adam and Luke proposed? From our point of view, it's wrong. If someone constructs a valid transaction that the nodes accept and are able to relay, that transaction should get into the block. Pool operators shouldn't be the ones who have the right to decide to censor transactions based on content. In the case of Bitcoin, if a user pays a large enough fee, the transaction should be included in the block. From our point of view, it is also unacceptable for miners to solve problems introduced by developers. Bitcoin blocks have only been about a third full for a relatively long time and it doesn't look like that's going to change. That said, fees are low. In terms of solving the security budget problem, it would actually be good for Bitcoin if more use cases were created to fill up the blocks. The Ordinals project has already been launched. Do the Bitcoin core devs have the right to somehow change the Bitcoin source code to prevent the project from working? They defend themselves by saying that projects like this are an attack on Bitcoin. On the other hand, some miners may like such projects because they generate profit for the network. Dan Held likes the project. He tweeted: "Ordinals = NFTs on Bitcoin. This is good for Bitcoin." He further argues that this project brings financial use cases and it drives demand for block space. He argues that if someone is paying fees then it is not spam and that Bitcoin is permissionless so no one should have the right to prevent someone from the building. In defense of the core devs, it can be said that they may think they understand Bitcoin the most and know what's best for it. It's certainly not a good idea to store images and other content on the blockchain. If more projects like this were to emerge, it could be that the blocks would be full. Ordinary financial transactions could wait in the mem-pool for a long time and people would send NFTs instead. Perhaps it would soon become clear that the low scalability makes Bitcoin not good for these purposes. Still, one has to ask who should have the right to decide. The public does not necessarily have the best opinion on the matter. Perhaps the market, through fees, would be the best answer. At the moment, it is uncertain how the situation will develop. If the Bitcoin blockchain is flooded with NFTs, the core devs and parts of the community will not like it and will try to fight it. What are the lessons for the Cardano community? The Cardano community has been debating the minPoolCost parameter for some time. The debate is hopefully coming to a conclusion and it is possible that the parameter will be removed. At the time of writing, it looks like it may be possible to remove minPoolCost and add a new minPoolRate parameter along with an increase in the K parameter. We shall see. As part of the Voltaire era, the team plans to hand over the management of the Cardano project to the community. It must be said that this has not happened yet, so the team is in a relatively strong position when it comes to source code editing. At this point, it probably wouldn't be entirely fair to criticize the IOG team for that. The team regularly debates with pool operators and values the opinion of the community. From the perspective of the roadmap, and this is important, there has been no transfer of responsibility yet. If you research the history of Bitcoin, you will find that the team has always had a relatively strong position that has been, at least to some extent, abused. In 2013 there was a blacklisting of addresses by core developer Luke Dashjr. In 2014, the OP_RETURN wars described above took place. In 2015-2017 there were blocksize wars. Bitcoin governance is a controversial topic and everyone will have a different opinion on it. For us, the Cardano community, it is important to learn from the past. Once responsibility for managing a Cardano project has been handed over, the team should always listen to the majority opinion of the community. Voting will be a normal part of decision-making. This will ensure that a majority decision is made. ADA holders will make the decision on the project. The ADA holders can delegate decision-making authority to someone they think technically understands the topic. Any ADA holder can become a Delegation Representative (DRep) and gain power through delegation from other holders. Those who are more interested in the topic should have a look at CIP-1694. Conclusion Bitcoin was the first decentralized blockchain. It is to be expected that not everything works as it should. The important thing is to accept the problem and try to fix it. Decentralized governance is a complex topic. Like it or not, the Bitcoin core devs have a relatively strong position, and prominent figures in the Bitcoin community are not afraid to advocate censorship of transactions. Some community members, such as Ari Paul, even claim that Bitcoin whales and devs have understood that the easiest way for Bitcoin adoption is through a state-friendly cryptocurrency. Censorship of transactions can be seen as a sacrifice for high market capitalizations. This is another difficult question that the Cardano community may face one day. Should high market capitalization be sacrificed for transaction censorship? This article was not intended to seek answers to complex questions, nor was it intended to point out the issues surrounding Bitcoin governance. No project is perfect. George Santayana said that those who do not learn from the past are bound to make the same mistake.
