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 involves 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.” Damage qualitative assessment from 1 to 5: 2
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. Damage qualitative assessment from 1 to 5: 3
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. Damage qualitative assessment from 1 to 5: 5
In the latter case, the concentration of Bitcoin Core code developers – the so-called 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. As of today, on average, between 40 and 60 developers contribute to this task each month with commits 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 community of developers: it includes both historical developers dating back to the early versions of Bitcoin Core and many newcomers who have joined more recently. Many historical figures have left over the years, while others have re-aggregated later, some operate consistently and regularly, others in a limited and sporadic manner. Within this group, which does not have a formalized hierarchy (and how could it, being Bitcoin an open-source project?), there are even fewer key developers, those who pull the strings of the community’s work. According to GitHub data, from its beginnings, 30% of the known commits to the Bitcoin Core master repository were made by only 2 developers, and in particular, almost 25% (meaning 7347 out of a total of 29,822 detected commits) by Wladimir van der Laan alone, the former Bitcoin’s Lead Maintainer. After his departure in 2022, there has not been a single coordinator of work on the Bitcoin Core code, but his enormous contribution remains undisputed. As of today, guiding the work on Bitcoin Core development is a restrictive leadership made up of a few senior developers including Gennady Stepanov, Michael Ford, Ava Chow, 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. Damage qualitative assessment from 1 to 5: 4
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, Bitfinex, etc.). Specifically, as of today, three major entities hold more than 55% of the Bitcoin held in custody by third parties, while just Binance rules the volume of fiat-BTC transactions with 30% of total public exchanges. 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. Damage qualitative assessment from 1 to 5: 3
We won’t dwell much on the hashrate/mining subsystem as both the issue of its decentralization and the possibility of 51% attacks have been analyzed and dissected countless times by far more authoritative sources. We only recall here the most common attack scenarios: double spending attack, selective transaction censorship, and empty block attack. The consequences of such attacks could be awful and should not be underestimated, but there is a vast literature explaining the limitations of this type of attack and the countermeasures that could be adopted by the node consensus to thwart it or at least effectively counteract it. However, all in all, it remains one of the most delicate and vulnerable subsystems, if only due to its degree of centralization. In fact, two mining pools – Foundry USA and Antpool – currently control more than 50% of the hash rate. Damage qualitative assessment from 1 to 5: 4
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. Damage qualitative assessment from 1 to 5: 3
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, i.e.: the relevance of effects on the network), illustrating the dynamics toward increasing or decreasing centralization.
A probability score (P) is assigned on a scale from 1 to 5 based on an inverse and non-linear function of the number of entities required to reach a given critical centralization threshold. In other words, the greater the number of existing entities required to reach a certain threshold, the lower the probability score. The aforementioned threshold is a percentage (sometimes subjectively defined) of the total estimated number of entities participating in a given subsystem, beyond which the system becomes seriously vulnerable to compromise. In some cases, this threshold is objective, as in the case of the mining dimension, while in others it is more arbitrary, such as in the case of developers or the client; however, in general, it could be understood as the tipping point of centralization.
A damage variable (D) is also assigned a score from 1 to 5. This is attributed in relation to the negative consequences expected from an attack on the specific subsystem on the security, stability, and functionality of the Bitcoin network as a whole.
This latter score is obviously subjective and undoubtedly could be subject to criticism and subsequent revisions by more in-depth analyses.
Finally, the specific risk score, which summarizes the risk of centralization of each subsystem, is obtained from the product of these two scores.
Geographical and Economic Decentralization
Other variations of the decentralization/centralization dichotomy can be identified, which cut across the seven 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.
Conclusions
Upon examining various dimensions of decentralization within the Bitcoin network, two critical subsystems come to the forefront due to their significant relevance and current limited decentralization: the mining/hashrate subsystem and the coding/developers subsystem. While discussions around the former have been ongoing since the inception of the Bitcoin project, with debates on numerous 51% attacks and their solutions, the latter has largely been overlooked or underestimated by analysts. Despite the historically honest and transparent behavior of core developers, whose intentions have consistently aimed at the genuine success of the technology, this does not guarantee the same conduct in the future.
The numerical scarcity of Bitcoin Core developers, coupled with the disproportionate code contributions from a select few individuals compared to the total participants, poses risks of infiltration, hacking, and social manipulation that cannot be downplayed. The insufficient number of developers to ensure an attack-proof level of decentralization might stem from their limited recognition and financial rewards within the Bitcoin user base and the wider global programming community.
Whereas miners have a financial incentive predetermined by the protocol itself to participate constructively and faithfully in the network, the same cannot be said for client programmers who lack predetermined, impartial, or proportional remuneration for the quantity and quality of their work. Those among them who have not enriched themselves with Bitcoin in the network’s early days and/or do not act out of selfless altruism, have to rely on grants, scholarships, and donations from third-party philanthropic entities to sustain themselves. The main subsidies to Bitcoin Core developers currently come from various organizations and companies in the Bitcoin Economy such as OpenSats, Spiral, Square Crypto, Chaincode, MIT DCI, Blockstream, Gemini, Coinbase, BitMEX, Hardcore Fund, etc. Their contribution is crucial, but their generosity is not necessarily neutral or disinterested. It’s not a bad thing in itself, but what would happen if other less benevolent donors, who likely have intentions and interests not aligned with the success of Bitcoin, were to take their place?
This raises concerns about potential interference from less benign donors, which could compromise the security and stability of the entire Bitcoin network. The limited numbers, ad hoc collaborations, and uncertain economic incentives make the role of core developers unattractive to most programmers, rendering them vulnerable to corruptive or manipulative actions.
To address these challenges and incentivize the independence, participation, and retention of core developers, we outline a few ideas here.
At one extreme, we could have dedicated micro-crowdfunding platforms that exclusively provide limited, non-refundable donations from donors to avoid imbalances and undue influences from a few individuals. At the other end, a multilateral agreement – optional but technically binding for signatories – among the big players in the Bitcoin ecosystem (miners, ETFs, exchanges, etc.) in which they commit, verifiably by all, to contribute a predefined share of their earnings to Bitcoin Core developers, thus subjecting themselves to a kind of voluntary self-taxation.
In both cases, technical implementation of incentive systems could utilize DAOs, smart contracts, and layer-2 solutions to regulate criteria for disbursement and anonymize payment flows to developers.
Naturally, the two ideas mentioned are not mutually exclusive or conclusive. Even less should they be imposed from above. We consider them simple grassroots ideas to initiate a serious debate on the need to value the key role of Bitcoin programmers without undermining their autonomy. A debate that, in our modest opinion, should be urgently reopened among all those who believe in the value of this revolutionary technology.
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.
