( 30th September 2019 )
Hash Power Centralization
The actual manufacturing of equipment can lead to some bad outcomes, but the more dangerous scenario is one where there is a concentration of hash power. Specifically, one company may control more than half of the hash power on the network.
Fig-1: Hash Power Centralization
These can further be subdivided into two different categories:
One company controls pools totaling >50% of network hash power
One company controls machines totaling >50% of network hash power
The possible attacks are similar, but the way the attacks can be thwarted are a bit different. If a single entity controls a bunch of pools, individuals that participate in the pool can simply switch to a different pool to thwart the attack. If a single entity controls a bunch of machines, that is no longer an option. Keep this in mind as we go through the possible ways in which a majority hash power entity can attack the network.
1.1. Majority-only chain
One obvious thing the majority hash power can do is simply reject blocks from everyone else, in essence taking every block reward for themselves. They could also deny transactions they don’t like and possibly try to double spend as well. This is not as easy an attack to pull off as it would seem, just from the math, if the majority is not much more than 50%.
To illustrate why, imagine that a hypothetical manufacturer called Mitbain controls 60% of the hash power and decides to execute the block rejection attack. The probability that the rest of the network finds a given block is 40%. It’s clear that because the minority still has some hash rate, at some point, Mitbain will be behind by 1 block to the rest of the network.
In order to overtake the lead, Mitbain will need to find 2 more blocks than the rest of the network. This is not as simple as it sounds. Given sufficient time with a majority of the network hash rate, overtaking is inevitable, but this does not necessarily happen very quickly.
The math is a little involved, but the number of expected blocks until Mitbain overtakes the rest of the network is actually quite high. With 60% of the network hash power, the expected number of blocks until Mitbain overtakes the network is actually 6 blocks! Note this is with 60% of the hash power, so that’s not 60 minutes for those 6 blocks, but 100 minutes.
Not only that, but in the best case scenario for the attacker, the entire network will be invalidating the previous 5 blocks for the attacker’s 6 new blocks. Every transaction that happened in the previous 5 blocks would be invalidated as if they never happened and the transactions in the 6 new blocks seen as canonical. This is what’s called a block reorganization or a reorg for short and is how a double-spend attack can be performed in Bitcoin. Of course, the attacker could be “nice” and include more or less the same transactions as the original blocks that it’s overtaking, but there’s no guarantee.
No rational merchant or exchange would ever take less than 30 confirmations in a scenario like this (at least without some knowledge about what’s going on).
Fig-2: How many blocks can be expected to reorg every time the rest of the network finds a block.
The above chart shows how many blocks you can expect to reorg every time the rest of the network finds a block. You can see that even having something like 70% of the network hash rate makes executing this attack pretty long and drawn out. If after spending enough hash power to find 6 blocks, Mitbain is still behind by 2–3 blocks, would Mitbain really want to continue?
Furthermore, a large reorg signals to the rest of the network that something nefarious is going on and nodes will likely view these new blocks with suspicion. It’s entirely possible that full node operators on the network will simply invalidate these blocks (this is possible through the invalidateblock command) and happily view the other chain made by the rest of the network as canonical, in which case, Mitbain would have wasted an enormous amount of hash power, announced its bad intentions and have a fork that many nodes don’t recognize for all its trouble. This would be a hard fork without any replay protection and the community would decide which one is worth more.
In addition, during the attack, there are large reorgs every time a non-Mitbain miner finds a block, which make taking payments extremely risky. Essentially, without something like 80% of the network, this attack renders Bitcoin all but unusable during the attack.
If, instead, Mitbain simply mined normally on the network, the mining rewards would essentially be the same without arousing any suspicion or incurring any reputational damage. The double-spend, fee sniping and transaction denial value would have to outweigh the risk of failure including loss of mining rewards, loss of reputation and damage to Bitcoin itself.
To put it simply, this attack really doesn’t make much sense from an economic perspective because there is simply not enough upside for the attacker. What’s more, even if successful, Bitcoin would still survive! There is no guarantee that the temporary degradation of the network is enough to make all the Bitcoin owners sell.
Comments