Bitcoin has a carefully crafted system of checks and balances, where power is split amongst the protocol’s various stakeholders (developers, miners and users) in such a way that no single party ‘controls’ the ledger.
Decentralising block generation is crucial to prevent a single entity (or more likely, a consortium) from taking control of the network – a party controlling the majority of the hashpower can double-spend, reverse or censor transactions at will by performing the dreaded 51% attack.
This attack is made possible by the fact that nodes automatically follow the longest chain (i.e. that with the most accumulated proof-of-work). Consider a scenario where the attacker begins to secretly build a new chain on top of a given block (without broadcasting it to the network), whilst the remainder of the miners continue to build on what is decidedly the main chain.
Given the masses of hashpower that the attacker has, they’re able to keep up with the rate of new blocks being appended to the main chain, selectively including (or, indeed, excluding) transactions. In order to make such an attack profitable, it’s probably at a point after they ‘forked’ that they’ll choose to begin making large purchases on the main chain, without including these transactions on their secret chain.
A merchant will generally wait for a certain amount of confirmations before accepting that the deposit is valid, which, for all intents and purposes, it will be. Worth noting is that exchanges tend to require a high number of confirmations on less secure chains (if the coins/tokens are buried, they’re less likely to be reversed or double-spent).
When the attacker is done purchasing what we can only assume to be underground bunkers and supervillain swivel chairs on the main chain, they proceed to broadcast their own chain, which will need to be longer than the one other nodes are currently following. Upon receiving this, nodes cast the valid-until-then chain to the side and the ledger is reorged. On this new chain, the attacker is still in possession of all of the funds they had spent in the other state.
Now, obviously this isn’t an easy or cheap attack to pull off on Bitcoin. If the attacker was to rent mining power from NiceHash, it’s estimated that a one-hour 51% attack would cost ~$230k. This, of course, assumes that the service has the rigs necessary to do so (which they don’t).
Conversely, other chains are much cheaper to take over – we’ve seen this play out with other coins in recent months, most notably Bitcoin Gold, Verge and Monacoin. The pattern tends to be attackers sending coins to an exchange, cashing out into a more secure cryptocurrency, then propagating their (longer) chain with those coins still in their custody.
Many are concerned that if such an attack were to take place on Bitcoin, it would be conducted through the collusion of mining pools. Mining centralisation (both in hardware production and hashing power) is not a problem to overlook. Industrial and small-scale miners alike often converge towards pools, which results in them receiving a steady payout at the cost of sacrificing autonomy – Core dev Matt Corrallo recently published a proposal for remedying this.
In the same breath, however, it would be suicide for any one party to pull off a massive reorg — let’s not forget that miners have a vested interest in seeing Bitcoin succeed. They purchase purpose-built hardware (and peripheral equipment/space, etc.) and expend tremendous amounts of electricity to earn transaction fees and block rewards.
When other participants realise what has happened, all faith in the protocol crumbles (something that the price reflects when it plummets), and miners end up with useless equipment. As such, even if an entity had the means to pull off a 51% attack, there’s more of an incentive for them to simply continue acting honestly.
Of the attacks that could be carried out on Bitcoin, 51% attacks are perhaps the most devastating, in that they take aim at one of the cryptocurrency’s core value propositions – transaction finality. If successfully carried out, a 51% attack would undermine Bitcoin as a whole and possibly cause irreversible damage. A handful of prominent developers believe the PoW algorithm needs to be changed in order to mitigate the threat.
It’s orders of magnitude easier (and more profitable) for an adversary to target weaker chains, or to mine honestly. Unless you’re hell-bent on destroying the protocol (not out of the realms of possibility – the next article will discuss powerful actors that wish to take down Bitcoin) or have a passion for burning through cash, there’s little incentive to attempt an attack of this magnitude.
This is the second article in a series on Bitcoin attack vectors. Find the first one on Sybil/eclipse attacks here.
Cover art by author.