Critical Fix
A recent update to the Bitcoin Core implementation of the Bitcoin node software fixes an unusually critical bug that, if exploited, could have led to a severe denial of service attacks on the Bitcoin network. The vulnerability had been present in the Bitcoin Core code base since March 2017 and has only recently been discovered and fixed.
The incident highlights the importance of multiple implementations for client software in blockchain networks in order to diversify the risk of software bugs.
A Not So Unusual Bug
Bitcoin developers are arguably very capable distributed systems engineers, but bugs do occur. In this case, the bug could have been exploited to sabotage and disable nodes participating in Bitcoin’s peer-to-peer network. This could have been used to launch a denial of service attack affecting very large segments of the network.
Whilst miners taking part in such an attack would have had to give up their mining reward, there are other incentives to carry out such an endeavor. For instance, a large blackout of the Bitcoin network would have severe price impact and the resulting volatility could be exploited to make a lot of money.
The bug also affects the still experimental Lightning Network, Bitcoin’s second layer scaling solution. Therefore, any early Lightning Network adopters are urged to update their software.
Whilst the severity of the bug might have been slightly higher than usual, bugs are extremely common. Most major blockchain networks have suffered from high-profile cases at one time or other. Underlying cryptography solutions do not fare much better. Many readers will remember the Heartbleed bug, a serious vulnerability in OpenSSL that affected many systems worldwide.
Implementation Diversity
One of the often overlooked factors in these cases is the importance of multiple implementations of the underlying protocols. Software bugs are unavoidable, and if everyone uses the same software, everyone has the same bugs. In a blockchain, security is a numbers game. To take over the Bitcoin network an adversary needs more than 50% of the computational power of the network. If every node can be attacked in the same way, this is more likely. To attack a delegate proof of stake blockchain running a BFT-based voting protocol on 100 validator nodes, it’s enough to control 34 nodes. If a large percentage of the network runs software with the same vulnerability, an attack, or even an unintentional failure scenario, is much more likely to have a large impact.
It is therefore important for a blockchain to have a rich ecosystem of competing implementations. It is good for Ethereum that Geth and Parity share the market. However, it would be even better if other implementations also had a considerable market share, preferably ones that use different programming languages and libraries.
Blockchain architects should, therefore, strive for open and well-documented protocols, encourage diversity, and facilitate different implementations.