Sia CEO: The future under Bitcoin Unlimited is bound to be centralized

Note: The author of this article is David Vorick, CEO and lead developer of Nebulous Inc, which owns the decentralized cloud storage platform Sia.

Bitcoin Unlimited (BU) is a Bitcoin full node implementation protocol where each node can choose its own preferred block size limit. One of the selling points of BU is that it allows users to choose the block size using their full node and economic power. If a node chooses a block size that is too small, it will be forced offline because the node will not be able to follow the longest chain. If a miner chooses a block size that is too large, the blocks he creates will be ignored because there are too few full nodes that witness and acknowledge this block. In general, it is the market that determines the most appropriate block size, that is, we use the power of the free market to resolve the block expansion dispute.

In practice, this concept has many problems. When some community members decide to increase the block size, miners are the ones who have the final say. This is because only they can effectively prevent potential Sybil attacks ^[1] in the ecosystem. Suppose we have some effective way to infer that this "economic majority" will agree to adjust the block size at some point.

So what does an “economic majority” mean? After a contentious fork, two chains are formed. In a really bad fork, there may be more chains and no clear winner. Ethereum (fork) and Ethereum (original chain) are the result of a contentious fork (hereafter referred to as ETH and ETC). The community is split. The economic and political majority in the community clearly prefers a hard fork, while the economic and political minority prefers ETC. Therefore, any attempt by BU to adjust the block size will have a similar result.

In the ETH system, exchanges, service providers, websites, and developers all agree to the hard fork. Users prefer to trust developers, so most users agree to the hard fork to follow the developers' footsteps. This situation is very similar to the way BU went. A small number of nodes cannot detect the hard fork, so you can automatically take them into your pocket. If you can also persuade exchanges and service providers (such as BitGo) to stand on your side, then you have most of the computing power, that is, you have gained power in the hands of the majority of the economy. But this will trigger a centralization crisis, because the process of reaching consensus is to directly win the support of those centralized service providers with high incomes.

This is exactly what is happening with Bitcoin. The economic majority is the centralized service providers. If you can get two or three mining pools, exchanges, and payment processors to support you, you can control the vast majority of Bitcoin users. That means full nodes are meaningless as long as the economic majority votes. Full nodes are only effective when operating wallets and processing millions of dollars in daily transactions. You are handing the initiative over to centralized service providers.

This is not the worst part. What’s worse is that when these centralized players decide to increase the block capacity, they also set higher barriers for system participants. When the full node you run does not represent any economic power at all, or even when you cannot run a full node at all, you can only trust those “all-powerful” centralized service providers. But this is still not the worst part.

In the future, Bitcoin will need more capacity. So these economic majorities vote on the new block size. At this point, the centralized service providers have all the power. Most of them will be able to transition to the new block size, but since the blocks are already so large, some of the smaller centralized players simply can’t keep up. Because they can’t afford to maintain a small data center to maintain the new block size with only 100,000 users. These small players are no longer part of the economic majority, and if you are still running a full node, you may be able to help them, but you lost all your full nodes in the previous block size upgrade. If Coinbase wants to initiate an upgrade and strongly supports it, the rest of the people will definitely agree to it. They are the players with the power to increase Bitcoin capacity and eliminate "unqualified" competitors even without user consensus.

Where will things eventually develop? Ordinary users will lose control of Bitcoin, and Bitcoin will be in the hands of a few centralized players , and even the number of these centralized players will decrease. Because every time the expansion problem arises, the largest players will successfully "pass the test" as the economic majority, and the smaller players with insufficient strength will face the situation of being eliminated. Before long, only two or three centralized companies can adapt to the pace of Bitcoin's expansion, and everyone else will choose to trust them unconditionally. And these two or three companies are less in number, and it will become easier for the government to regulate and control them. They will turn Bitcoin into a featureless modern banking system.

The problem with BU is that the decision-making power is in the hands of the economic majority, including the decision-making power of the economic majority (as long as the participation cost is increased). Those in power can eliminate some participants by raising the system price and monopolize power. This model creates pressure for centralization, which is absolutely a disaster for cryptocurrencies that aim to be decentralized.

If you support decentralization, you should not support BU. I feel it is necessary to point out that BU's problem is not just the one I mentioned, but the problem described in this article is the most important and cannot be solved at all. If you want to develop a decentralized cryptocurrency, BU is definitely not the right choice.

Notes (↵ returns to text)

1. Sybil attack refers to a situation in which a single node has multiple identities in a peer-to-peer network, which weakens the role of redundant backup by controlling most of the system's nodes. ↵