Five Technical Takeaways From The Bitcoin Bug

/

It’s been more than a week since the initial disclosure of CVE-2018-17144. In that time, more details have been filled in, including the fact that the bug could not only crash clients, it could also create inflation— and that the bug was discovered and responsibly reported by a developer working on the “Unlimited” Bitcoin Cash client.

There has also been much discussion in the crypto world about the nature of this bug and what lessons we should takeaway from it. This article will detail my biggest takeaways, looking at it primarily from a technical perspective.

#1 The risk of a critical software flaw disrupting Bitcoin, or another major crypto network, is still under-appreciated.

At the beginning of August, it was revealed that Bitcoin Core developer Corey Fields had discovered and disclosed a chain split but in Bitcoin Cash. In his write up detailing that incident, Corey had this to say:

Working through this bug, which certainly had the potential for catastrophe, has reaffirmed my belief that the threat of software bugs is severely underestimated in the cryptocurrency world. I’m presenting a detailed report of this incident… as a wake-up call to companies who have not adequately prepared for this type of scenario.

This seems especially prescient in light of this latest vulnerability, and I fear many people are still failing to account for the risk. I’ve seen many folks on Twitter say things like “bugs can always be fixed” or “whats the big deal— it wasn’t even exploited.” We should make no mistake: Bitcoin dodged a bullet.

#2 Bitcoin development is under-provisioned given the enormity of what is now at stake.

A couple of months ago, Naval Ravikant set off an uproar amongst Bitcoiners for saying that incentives for Bitcoin developers are out of whack. Rather than discussing a very good point, most seized on the use of the economic term “free-rider” to imply, incorrectly, that Naval was criticizing all Bitcoin “hodlers”.

When some in the community did get around to addressing Naval’s actual point, most insisted that Bitcoin did not have a developer problem, that the contributions of passionate experts are sufficient, and that no conversation around how to fund additional eyes on the code was needed. I tweeted about this earlier in the week.

 
 

The commit that introduced this vulnerability was made by a single developer and merged after a cursory review by only one other. This, despite the fact the change was to a critical section of the code dealing with transaction validation. It subsequently remained in the code for a eighteen months before being discovered by someone working for a different project.

For a project with a $100 Billion market cap, which aims to make itself a store of value for people’s wealth, and on which many of us are resting our hopes for a more decentralized monetary future, this is simply unacceptable. I’m not saying I have the answers for how to solve this problem, but we damn well better acknowledge there is a problem, here!

#3 It’s totally unclear whether having only one widely used implementation of Bitcoin is a good idea.

Bitcoin Core is far and away the most widely used client software on the Bitcoin network, with over 95% of all nodes running it. Other networks have much more diverse topologies, such as Ethereum, which has multiple widely used clients built in different languages and by different teams.

There is a downside to heterogeneous networks, most critically that a consensus difference between two or more clients could lead to a chain split. This vulnerability lends credence to those who argue the benefits to multiple clients is worth this risk.

 
 

Had the bug been exploited, virtually all clients on the Bitcoin network would have been affected. Only those still running very outdated versions of the software would have been safe. A heterogeneous network would be more robust to these sorts of vulnerabilities, and arguably might result in their discovery sooner as well.

#4 Mining is (still) centralized, and mining pool operators have an outsized impact on consensus.

There’s no real new information here, just a dramatic demonstration of the reality. When this bug was discovered, the Bitcoin Core developers reached out to the operators of a handful of mining pools. Once some were patched, it was “safe” to reveal the full nature of the bug, despite the fact that 85% full nodes (like my own!) had not yet been patched.

 

Bitcoin hashrate distribution via blockahin.com

 

Running a full node is still a good idea for one’s own security— you don’t have to trust anyone to carry out transactions. And it does impute some measure of greater decentralization to have more full nodes in operation. At the end of the day, though, those in control of the hash rate have an outsized control on consensus, and at the moment, that means just a handful of pool operators.

Something that should create some cognitive dissonance for those of us who care about decentralization: the fact the hash rate is relatively centralized actually made patching this issue easier.

#5 If/when a sophisticated nationstate decides to attack cryptocurrencies, things will get ugly, fast.

What are the odds that someone inside a government agency, be it the NSA, or an equivalent agency in China or Russia, knew about this vulnerability before it was discovered and patched? I’d say they’re relatively high. If I headed up one of those agencies, I would certainly have a team reviewing the code of Bitcoin and other major cryptocurrencies, looking for exactly these types of weaknesses.

Why? Because that would be my job! Bitcoin, and other networks, have become too important on the international stage not to warrant attention from such agencies. And make no mistake, while these agencies are bureaucratic, they still employ and provide resources to brilliant people who, working in small teams, can accomplish incredible feats.

If, or more likely, when a major nationstate decides to become hostile to crypto, things could get…messy