Bitcoin Decentralization and Where to Find It

Introduction

One of Bitcoin’s undeniable and frequently touted strengths is its decentralization. It’s often claimed that the Bitcoin network offers levels of decentralization, accessibility, and distribution unmatched by any other cryptocurrency. But just how decentralized is Bitcoin in reality? And how do we go about measuring its decentralization? Before delving into these questions, it’s crucial to clarify the concepts of centralization and decentralization, as they are often muddled.

To provide a clear definition, the centralization/decentralization dynamic can be understood as the degree of concentration/diffusion of authority among the participants in a system. Here, “authority” refers to the power to influence the functioning and rules of the system, whether for malicious or benign purposes. With this in mind, measuring the degree of centralization in a system entails quantifying the minimum number of entities – participants – required to alter its functioning or rules. The lower this number, the greater the degree of centralization. In a seminal 2017 paper on the subject, Balaji S. Srinivasan and Leland Lee introduced an insightful metric for this purpose: the Nakamoto coefficient.

Derived from the Lorenz curve used in calculating the Gini coefficient, the Nakamoto coefficient identifies the minimum number of participants necessary to compromise or control the system. For instance, in the well-known scenario of Bitcoin’s hashrate, if we assume that five mining pools collectively possess 50%+1 of the total hashrate, then this number would be five. This means that a simple majority of 50% of the hashrate would be adequate to execute a double spending operation on the blockchain. However, the critical threshold may vary for other variables.

Different facets of centralization

Now, let’s address the core issue identified by the authors of the paper: identifying subsystems critical to the functioning of the system. When it comes to Bitcoin, focusing solely on the concentration of hashrate (i.e., miners) fails to capture the full spectrum of centralization/decentralization within the network and overlooks the potential for a 50%+1 attack.

Balaji S. Srinivasan and Leland Lee, in their article, propose five additional measurable subsystems of the Bitcoin Network: client platform, code developers, nodes, custodial/exchanges, and ownership.

According to Balaji S. Srinivasan, the six dimensions of centralization within the Bitcoin network are as follows:

• Client centralization

• Ownership centralization

• Node centralization

• Developers centralization

• Custodial/exchanges centralization

• Hashrate centralization

In addition, we might consider adding one last dimension:

• Hardware Centralization

While this list is comprehensive, what’s lacking is a qualitative assessment of these dimensions. Which among them are truly pivotal for Bitcoin’s network functionality, and which are not?

For instance, one could argue that the client or ownership variables aren’t as crucial in measuring Bitcoin’s decentralization.

In the first case, Bitcoin Core stands as the de facto standard client today. However, it’s worth noting that this is an open-source software authored by Satoshi Nakamoto himself. As long as it remains open-source, actively maintained, and monitored, its dominance doesn’t necessarily equate to vulnerability. It’s important to recognize the distinction between Bitcoin Core’s hegemony rather than a monopoly, as theoretically, other operational clients exist—such as Bitcoin Knots, BTCD, Libbitcoin, BitcoinJ, Bitcoin Unlimited, Gocoin—that can support the Bitcoin protocol. Yet, in practice, very few network nodes utilize these alternatives, favoring Nakamoto’s original implementation. In this regard, in 2010, Satoshi Nakamoto himself said: “I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea.”

As for the second dimension listed above – the distribution of Bitcoin ownership – this undoubtedly has significant socio-economic implications but it doesn’t directly affect Bitcoin’s infrastructure. Since Bitcoin relies on a proof-of-work algorithm, the power that Bitcoin owners have over nodes and protocol operation is essentially nil. The centralization of sat ownership could only become problematic if currency concentration reaches such extreme levels that undermine the network effect, impacting practical use as a medium of exchange and store of value. Fortunately, as polarized as Bitcoin wealth may be, we are far from this point and according to various analyses, as Bitcoin adoption increases, the concentration of sats gradually decreases.

Conversely, subsystems like nodes and coding are pivotal for achieving true network decentralization, being potentially the most critical points within the Bitcoin system. The risk of node takeover and subsequent hard forks or coordinated malicious actions on the protocol poses significant and lasting threats to network trust. However, the probability of such occurrences is already low and have constantly decreased over time, given the growing number of active or quickly activatable nodes (approximately 16 thousand and 53 thousand respectively, according to the latest known data) and their distribution across different locations, entities, and legal jurisdictions.

In the latter case, however, the concentration of Bitcoin Core code developers—known as Core developers and maintainers—remains very high and arguably increasing from a certain perspective. There are relatively few programmers actively involved in writing and maintaining the client, despite it being a critical function for the entire technological infrastructure of the Bitcoin network. Currently, an average of between 40 and 60 developers contribute to this task each month according to GitHub data. They decide voluntarily and independently when and how to contribute to the development of Bitcoin Core software on GitHub. In practice, over the years, there has been a rather high turnover within this developer community: it includes both historical developers dating back to the early versions of Bitcoin Core and many newcomers who joined more recently. Many historical developers have left over the years, while others have re-joined later, some operate consistently and regularly, while others sporadically. Within this group, which does not have a formalized hierarchy (and how could it, being Bitcoin an open-source project?), there are few key developers, namely those who oversee the community’s work. After Wladimir van der Laan left the scene in 2022, the last Bitcoin’s Lead Maintainer, there hasn’t been a single coordinator for work on the Bitcoin Core code. Currently, the GitHub work is led by a board composed of four senior developers (Gennady Stepanov, Michael Ford, Andrew Chou, and Gloria Zhao), each specializing in overseeing a specific component of the client.

One might wonder if such a small and decentralized group of developers/maintainers contributing to the code today might be the Achilles’ heel among Bitcoin’s various subsystems, making the entire structure vulnerable to attack. A huge, complex, and highly valuable (not only economically) infrastructure like today’s Bitcoin network relies on the often part-time and mostly unpaid work of a few passionate supporters and maintainers. On the one hand, it’s true that individual nodes have the final say on the adoption of each new update/version of the Bitcoin Core client through the consensus mechanism. On the other hand, one might question how many nodes actually analyze the new code for vulnerabilities, harmful changes, or bugs before installing it.

What would happen if, hypothetically, gradual infiltrations of saboteurs occurred within the limited circle of Key Core developers and Maintainers, with the aim of first gaining trust and influence in the community and then hacking the new versions of the code? They could, for example, hide virtual time bombs within them (in the form of bugs or zero-day vulnerabilities). It’s a Machiavellian and complex hypothesis to execute, but not impossible, especially if we consider a gradual, covert operation conducted by entities with significant financial, human, and technological resources at their disposal and with a strong motivation to disrupt the network, such as the intelligence service of a powerful state. What would be the consequences of such an operation on Bitcoin if it were successful? Probably quite serious, if not existential. It could unleash chaos among nodes that unwittingly implemented the corrupted update, leading to forced hard forks with effects on the stability, integrity, and trust in the Bitcoin network. What a technological brute force attack couldn’t accomplish, social engineering aimed at dismantling consensus could. It’s difficult to estimate the probability of success of such an attack on the Bitcoin Core code, but the small number of individuals overseeing its development and maintenance, and the relative lack of interest from the wider user community in their valuable work (and, last but not least, their remuneration), make this subsystem particularly vulnerable to a well-conceived attack.

When considering the realm of custodial and exchange services, the trend toward greater or lesser centralization isn’t entirely clear-cut. While their numbers have soared since the early days of Bitcoin (think MtGOX), the lion’s share of trading volumes against fiat currencies today remains concentrated among a select few major players (Binance, Bybit, Coinbase, OKX, Kraken, etc.). The risks stemming from excessive centralization in this specific subsystem aren’t so much tied to the security of the Bitcoin network itself, but rather to its convertibility with fiat currencies and the security of those delegating custody (i.e., all those Bitcoin users entrusting their sats and hence their “physical” possession).

In the first scenario, heightened centralization (a reduction in the number of exchanges) would render the system more vulnerable to coordinated legal or cyberattacks aimed at disrupting and potentially severing the link between fiat currencies and Bitcoin. This follows the logic that fewer doors make for easier locking. In the second scenario, under an oligopolistic regime, those opting for custodial solutions instead of self-custody would face increased counterparty risk. This would result from the diminished bargaining power of users towards custodial counterparts, who could then impose more burdensome economic conditions and more oppressive clauses (for example, regarding access to custodied bitcoins) than they could in a competitive environment.

Moreover, with only a few large operators capable of controlling significant bitcoin quantities on behalf of their clients, the risk of abuses (such as non-consensual fractional reserve practices), hacking (the richer the target, the more appealing), and political-regulatory interference (including collusion with public authorities, excessive regulation, and bureaucratization) would be considerably higher compared to a more fragmented and competitive custodial system.

At the far end of this counterparty risk spectrum lies the possibility of a 6102 attack: the large-scale seizure of bitcoins held on exchanges and custodial wallets within a certain jurisdiction by legislative action. While this wouldn’t directly impact the functioning of the Bitcoin network, it would likely undermine trust in Bitcoin as a secure means of payment and store of value among the general public, thereby jeopardizing its success as a free permissionless currency.

As for the hashrate/mining subsystem, we won’t dwell on it extensively, since both the issues of its decentralization and the potential for 51% attacks have been thoroughly analyzed by far more authoritative sources than us. We’ll simply recall the most common attack scenarios: double-spending attacks, selective transaction censorship and the empty block attack. The consequences of such attacks should not be underestimated, but they aren’t necessarily existential for the network. There exists a substantial body of literature explaining the limitations of these types of attacks and the countermeasures that could be adopted by the consensus of nodes to thwart or at least effectively counteract them. …sviluppare..

Finally, turning to the hardware dimension (originally absent in the work of Balaji S. Srinivasan and Leland), we need to analyze the diversification of mining equipment in terms of manufacturers, models, and their respective market shares of Bitcoin’s hashrate. It’s undeniable that nowadays the number of hardware manufacturers for mining (ASICs) has significantly increased compared to the past. Major companies in the sector include Bitmain, Whatsminer, Canaan, Zhejiang Ebang Communication, Halong Mining, Helium, Bitfury, Bee Computing, and HIVE Blockchain. However, the total hashrate of miners is currently dominated by a few ASIC models and even fewer manufacturers. According to recent estimates by Coinmetrics, over 70% of the global hashrate is produced by ASICs from a single leading company, Bitmain. Additionally, including just three other manufacturers (Whatsminer, Canaan, and Ebang) accounts for virtually all of the computational power used by the Bitcoin network. Moreover, the overwhelming majority of the hashrate is generated by only seven ASIC models from these aforementioned companies: Antminer S19xp, Antminer S19jpro, Antminer S19, Canaan 1246, Antminer S17, MicroBT m20s, and MicroBT m32.

The risks of such centralization of hardware in terms of models and manufacturers are numerous. With very few large manufacturers, primarily now located in China, they could easily be compelled by governments and lawmakers of the jurisdictions they’re subject to, to halt production in their facilities, hand over batches of manufactured hardware, or secretly infiltrate backdoor hardware and trojans into their ASIC models. The consequences would immediately impact the mining subsystem, causing instability and potentially a collapse in the network’s hashrate, resulting in significant economic losses for miners using corrupted ASICs or those unable to acquire new ones. A significantly lower and prolonged hashrate would reduce the security of the entire network, as it would increase the chances of a 51% attack, perhaps precisely by the actor who initiated the hardware attack. Here, we see how an attack on one poorly decentralized subsystem can virtually weaken another and thus attack it in a dangerous chain reaction with dangerous consequences for the integrity of the Bitcoin network.

Given this non-exhaustive overview of the various subsystems of Bitcoin and their vulnerabilities, we can endeavor to synthesize the six dimensions into a single table. This table would measure the risk of centralization as a matrix between probability (P) and damage incidence (D, meaning the relevance of effects on the network), illustrating the dynamics toward increasing or decreasing centralization.

R=P*D

Geographical and Economic Decentralization

There are also other aspects of the decentralization/centralization dichotomy that cut across the six types just illustrated: geographical (jurisdictions) and economic (economic entities). Geographical decentralization addresses the question: where are the nodes, wallets, exchanges/custodians, and miners physically and legally located? Economic decentralization, on the other hand, concerns the economic ownership of these entities: for example, who owns the mining pools? Or who controls the exchanges? The geographical and economic aspects may seem overlapping at first glance, but in reality, they are not at all. For instance, there could be a Bitcoin ecosystem where there are many independent miners, but all located within the same jurisdiction and thus subject to the same political-legal risk. Here, economic/ownership centralization would be low, while geographical centralization would be very high. Conversely, there could be many miner factories scattered across the globe but controlled by the same economic entity and therefore effectively considered as a single point of failure. The same argument could equally apply to nodes, hardware or bitcoin ownership. In a world dominated by states and large corporations, neglecting these factors can be fatal. The mere number of participants in a Bitcoin subsystem tells us little about decentralization if they are mostly concentrated in a single jurisdiction or subject to the same economic control. Therefore, both the qualitative geographical parameter and the economic parameter should be integrated into any attempt to measure the degree of decentralization of the Bitcoin network.

What changes with ETFs?

The recent emergence of Bitcoin ETFs in the US market may have a considerable impact on the decentralization of the network, particularly concerning the Custodial/Exchanges subsystem. While investing in an ETF significantly simplifies access to bitcoin performance compared to other fiduciary solutions, this option doubles (if not triples) the counterparty risks for investors. Those who “invest in bitcoin” through an ETF do not actually possess or own the assets; they are subject to both the counterparty risk of the ETF manager and that of the Custodial/Depository to which the ETF relies on (if the manager does not opt for an unlikely self-custody), as well as the risk of the intermediary/broker through which they acquire the instrument. In practice, the adage “Not your keys, Not your coins” reduces to a simple “Not Your Coins, goodbye” especially in the case of an hypothetical 6102 attack applied on ETFs.

On a macro level, the same arguments made for custodial/exchange entities apply to passive funds on Bitcoin: the more they are utilized by institutional and retail investors as a form of “investment in bitcoin,” the more bitcoin is absorbed into their masses. Consequently, their coercive power over users and contractual (i.e., economic) power over other subsystems of the Bitcoin Network increase. If a specific Bitcoin ETF were to acquire a significant (if not dominant) market share of circulating bitcoin over time and systematically use its proceeds to subsidize developers of the Bitcoin Core client, it could influence their actions, guide client implementations, and thus the development direction of the entire network towards its desires. This would be a case where the centralization of one dimension (that of custodians through ETFs) leads to the centralization of a much more vital dimension: that of developers discussed earlier.

This is a guest post by Michele Uberti. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.