Bitcoin’s biggest challenges

I have been participating in the Bitcoin ecosystem for the past 2.5 years, and it has become clear to me that there are several persistent and serious issues with Bitcoin from an organizational perspective. While many people are not familiar with who I am, they may be familiar with the btcsuite project, which I finance entirely by myself and contribute to via the developers I work with. In early 2013, after one of my developers had a less-than-pleasant interaction with the Core developers regarding porting bitcoind to OpenBSD, I decided that making an alternative from-scratch implementation of Bitcoin would be an interesting project and benefit the Bitcoin community by offering an alternative to the Bitcoin Core (BC) monoculture. Having rebuilt the Bitcoin infrastructure from the ground up on my own dime, I have a rather unique perspective on Bitcoin despite being late to the game. I have identified what I consider to be several persistent and severe problem areas with Bitcoin: project governance, funding development and proof-of-work miners having too much power.

Project governance

As many of you are well aware, Bitcoin has been suffering from a long-running clash of views about whether to increase the maximum block size or not. Informal surveys and content on twitter indicate the majority of businesses and miners support increasing the block size, but a majority of BC developers oppose this increase. There are at least 2 less-than-ideal resolutions to this argument:

• Allow BC developers to force the maximum block size to stay at 1 MB, effectively vetoing the community.
• Create a fork of BC that allows larger blocks, and have enough miners and businesses switch to force the block size increase, effectively vetoing the BC developers.

Neither of these options are very appealing, and more importantly than any resolution that is eventually reached, it reflects a very real crisis in governance. In order to better understand the current crisis, it is worthwhile to quickly recap the history of Bitcoin governance since it was introduced in 2009.

In early 2009, Bitcoin started as the project of a single identity, Satoshi Nakamoto (SN), and was run as many open source projects are, with SN as the benevolent autocrat. SN’s autocracy lasted until late 2010, when SN designated Gavin Andresen as his successor. Gavin kept the autocracy going until April 2014, when he stepped down as Lead Developer and became the Chief Scientist. At this point Wladimir van der Laan took over as Lead Developer, but it was clear that the previous autocracy was substantially weakened and the transition to an oligarchy began. The new oligarchy was comprised of the BC developers and put an effective block on any autocratic actions, requiring new decisions to go through a drawn out discussion process on GitHub, with commit access effectively controlled by a smaller subgroup within the BC developers. This informal oligarchy is the current system of governance we have for Bitcoin.

As most of the Bitcoin community has already noticed, this informal oligarchy has a number of problems:

•  The notion of consensus amongst BC developers is “100%” agreement, so making any substantive changes requires unanimous consent.
• Funding for BC developers was entirely donation-driven until 2014. Since donations were insufficient to pay for more than a few developers, many BC developers could not make income working on Bitcoin and had to rely on having the foresight to hold onto a large amount of bitcoin personally.
• In October 2014, a majority of the BC developers decided to participate in the founding of Blockstream, which was VC-backed. This intertwined the financial interests of the BC developers and their VC financiers, creating a perceived conflict of interest in the context of Blockstream’s business model and the maximum block size debate. Since the majority of BC developers work for Blockstream, it means that this group has an effective veto over any substantive changes to Bitcoin and a large amount of influence on what changes get approved.
• In April 2015, several BC developers joined the MIT Media Lab’s Digital Currency Initiative due to problems with funding from The Bitcoin Foundation. Since MIT is an academic institution and not primarily motivated by profit, there is less of a perceived conflict of interest for these BC developers compared to Blockstream. However, it is unclear what, if any, influence MIT can or would exert over these developers. By the same merit as the reasoning with Blockstream, these BC developers also possess an effective veto over substantive changes to Bitcoin.
• In May 2015, Gavin began a push to have the maximum block size increased to 20 MB, which created a lot of debate amongst the BC developers. After a few months of dispute, he decided to work on the Bitcoin XT fork of Bitcoin Core, where the block size increase has been added. Bitcoin XT is attempting to push up adoption amongst full nodes to effectively override the BC developers who oppose the block size increase.
• Businesses, developers of non-core Bitcoin infrastructure, miners, holders of bitcoin and developers of alternative Bitcoin implementations have no vote in any of these decisions about the future of Bitcoin. Despite putting in large amounts of time, energy and money, nobody except the BC developers has any real say about the BC decision making process. It is possible for these groups to band together and effectively revolt against the BC developers, but this would create a serious rift between the development team and the community.

Based on all of this, it is abundantly clear that something needs to change with the governance of Bitcoin. The current governance model of Bitcoin does not admit multiple stakeholders and is geared towards stagnation because of the way consensus amongst BC developers works. Beyond this structure being built to stagnate, even a conversion from a unanimous BC developer consensus model to a weaker one, e.g. with 66% majority required for changes to go in, would be subject to a veto from Blockstream by merit of their employment of so many BC developers. Additionally, all of us who participate in the Bitcoin ecosystem who are not BC developers have effectively zero say in the matter.

Funding development

Attentive readers and those familiar with open source software have likely noticed a theme in the governance issues described above: that many of the recent governance issues are related to a lack of funding for development work. In the world of open source software, it is typical for a project to receive zero or extremely limited donations, even when the project receives wide adoption. Bitcoin is no exception to this pattern since donations alone have only supported 1 or 2 developers at a time through The Bitcoin Foundation. Since it takes the equivalent of several full-time employees to maintain and extend BC, this means there is a large amount of development work that has historically been unpaid.

While it has been the case that BC development work was mostly unpaid, recently, this pattern has changed. The funding of the BC developers by Blockstream and MIT Media Lab has created a much-needed source of income for developers. For the developers, this is obviously an improvement from the unpaid work scenario. However, funding of BC developers by outside entities creates real and perceived conflicts of interest and brings into question the extent that the outside entities can exert influence over Bitcoin.

For example, let’s assume that the Blockstream developers really did strongly favor 1 MB blocks prior to founding the company. The trouble now is that these same developers have a financial interest in keeping the 1 MB block size to drive usage of sidechains, so even if their genuine personal opinion of the 1 MB cap changed, they are very unlikely to share that opinion publicly. This means that external observers cannot differentiate between genuine actions and self-interested actions by those developers.

Beyond the conflicts of interest, it is not clear how much influence these external entities can exert over the BC developers they employ or fund. I would expect that their influence over the personal positions of their developers is rather limited, but this is not necessarily the case. Having participated in a number of different organizations throughout my life, I know some places are a lot more serious about “drinking the KoolAid” than others. Currently, one can only hope that these entities that fund BC development are not surreptitiously influencing BC development.

Proof-of-work miners have too much power

Bitcoin’s proof-of-work miners possess an enormous amount of influence, and that influence is for the most part unchecked. Miners can control the transactions included in a block and which blocks are considered acceptable, which means they can create a denial-of-service by mining empty blocks, censor transactions by explicitly not including them in blocks or hinder new consensus rules from being implemented. In practice, miners have not implemented any censorship to date (to my knowledge), but there are certainly many blocks that are mined with 0 or low transaction counts. To date, miners have not blocked any new consensus rules by refusing to upgrade. While censorship and refusing to upgrade have not been issues to date, they likely will be in the near future.

The mining of empty or artificially small blocks acts as an effective denial-of-service for Bitcoin. Miners still receive the block reward even if the block has 0 transactions included in it and fees are too low to provide an incentive, so there is not a good incentive structure to induce miners to include more transactions in a block. Beyond there being no penalty for mining smaller blocks, there is a direct incentive to mine smaller blocks, due to the longer time required to propagate a larger block. These incentives are not aligned with the behavior that most Bitcoin users would want from the network.

While censorship has yet to become an issue, current estimates of hash power distribution by country show China as having easily over 50% of the hash power. Additionally, I expect that the majority of the ASICs used for mining have chips fabricated in Asia, but likely assembled in China. This means that China will possess a majority of the active hash power for the forseeable future. China is publicly known for its very proactive and aggressive censorship, so it is not a huge leap to imagine that the Chinese government could bring this censorship to bear on Bitcoin miners, e.g. refuse to mine transactions that have certain UTXOs as inputs because they belong to Falun Gong. If such censorship is applied to Bitcoin via the miners, there is very little anyone could do to reign it in.

Since the miners are the ones who create new blocks, they can effectively block or force a software upgrade by working with the other major miners. Miners are under no obligation to mine blocks with new consensus rules, e.g. have a maximum block size over 1 MB, but must typically obey soft fork changes once a majority of blocks are of a new version. If miners band together, they could entirely block a consensus rules update. Alternatively, miners could attempt to force an upgrade on the rest of the network by updating their consensus rules and pushing other full node operators to do the same. If the rest of the full nodes did not go along with this upgrade being forced by miners, it would create a fork, so a forced upgrade by miners would be a risky maneuver. As if the situation with governance was not already messy enough, the miners are another group who possess an effective veto over consensus rule changes.

Conclusions

The challenges outlined in this article are substantial and of key importance for the larger-scale and longer-term adoption of Bitcoin. Straightforward solutions for these problems do not fit well within Bitcoin since they involve making fundamental changes to incentive structures and consensus rules. Beyond the technical difficulties with making these changes, based on how vehemently groups within BC disagree on even simple changes like increasing the maximum block size, it is practically assured that any proposed solutions to these problems will not be implemented for one political reason or another. As such, the only reasonable way to make real progress on these challenges is to create an altcoin that implements the proposed solutions.

We have worked ahead and implemented a solution to each of these problems in a new altcoin we will be announcing publicly in 2 weeks. A second article will follow this one where a proposed solution for each of these challenges is discussed. Company 0’s work on an altcoin in no way means that development will stop on btcsuite, rather, it has already led to several bug fixes in btcsuite from backported changes. Since the altcoin is based on Bitcoin and btcsuite, we expect the work will provide an ongoing symbiotic relationship with btcsuite in terms of changes, with bugfixes and updates flowing both from and to btcsuite as a result.