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

Has The Window For Bootstrapping A Proof-of-Work Coin Closed?

/

In the wake of three high profile mining-related attacks on notable alt-coins, one can't help but wonder: is the window for bootstrapping a new proof-of-work cryptocurrency closed? If not, it must be getting close. (For reference, see attacks on: Verge, Bitcoin Gold, Monacoin).

The default failure mode for any new cryptocurrency in 2018 is the sound of silence. For a coin to be attacked, first someone has to care enough to try. It's likely no one will. For the sake of this discussion, we'll assume we're talking about a coin that's getting some traction: it's listed on some exchanges and has some notable trade volume.

Launching a new PoW cryptocurrency there are, broadly speaking, two choices when it comes to choosing a hashing algorithm:

  1. Choosing an existing hashing algorithm used by other coins
  2. Creating a novel hashing algorithm by tweaking or combining existing ones

There are lots of variations on these two themes. Verge, for example, got cute and allowed miners to use any one of five different algorithms to produce blocks- a "feature" exploited by its attacker. For the most part, though, a project will fall into one of these two buckets. Let's examine the issues with each.

Using An Existing Algorithm

The problem with choosing an existing hashing algorithm, one used by an established cryptocurrency, is obvious: your fledgling chain is immediately susceptible to a 51% attack from existing miners. Those miners likely have warehouses full of ASICs churning out hashes 24/7. Even a handful of those machines, if diverted toward your chain, could destroy your network. And, as Charlie Lee pointed out recently, there is no real incentive that prevents them from doing this.

 
 

Many miners will have no bones about extracting a quick profit while demolishing your chain, then pointing their hash power back to an established coin. So, using an existing algorithm seems to be off the table. But what about....

Using A Novel Algorithm

Creating a new hashing algorithm seems like an attractive alternative to being crushed by existing miners, but this path, too, is fraught with peril. For one, introducing a new hashing algorithm is nontrivial from a technical perspective and introduces a security risk for your network.

More importantly, any coin that gains real traction in the market will immediately trigger a race to develop and manufacture ASICs- a feat only a small handful of companies currently excel at. As the recent development of ASICs for Equishash and CryptoNight demonstrate, no algorithm is truly ASIC resistant.

Thus, it's only a matter of time before a new algorithm is being mined by stealth ASICs and your network is controlled by, at best, a few companies. (More likely, by just one company- and I do mean one in particular). You might be tempted to think said companies would sell the ASICs and distribute the hash power and all would be well, but as David Vorick recently pointed out in his must-read summary of The State of Crypto Mining, this is not the case:

At the end of the day, cryptocurrency miner manufacturers are selling money printing machines. A well-funded profit maximizing entity is only going to sell a money printing machine for more money than they expect they could get it to print themselves.

 

The best case, then, for a budding PoW coin is to find its hash rate controlled by stealth ASIC miners run by 1-3 entities, with only their goodwill preventing a 51% attack at any moment. Not exactly the decentralized future we were all hoping for.

So, What Now?

I'm honestly not sure we'll see a single new PoW coin launch and gain large scale traction again. Ever. If we do, then certainly that project's team will have to spend a disproportionate amount of time threading the bootstrapping needle to avoid the pitfalls described above.

As for existing coins, I'd go so far as to say that virtually all PoW alt-coins in the long tail are protected merely by obscurity¹. Existing large scale miners and/or ASIC manufactures could trivially attack them. They simply can't be bothered.

A handful of other coins, like Monero and Zcash, have signed up to play an eternal cat and mouse hardfork game with ASIC manufactures. This strikes me as ill-advised, but we'll see where it goes.

Finally there is a top tier of PoW coins that have clearly achieved escape velocity and are relatively safe from a 51% attack. Bitcoin, Litecoin, and Ethereum are the most obvious examples. These chains benefitted from the opportunity to bootstrap in (relative) obscurity and are now (relatively) protected by (relatively) distributed hash power and (relatively) commoditized ASICs. (Did I mention this is all relatively speaking?)

For those of us that care about decentralization and censorship resistance, this conclusion is alarming. To date, PoW is the only effective consensus algorithm that hasn't compromised on those two values. It seems our hopes for a decentralized future rest on the success of at least one of these small handful of projects- or on efforts to develop truly decentralized alternatives to proof-of-work.

¹ There's actually another class of coins I intentionally disregarded in this post: those that merge mine with much larger coins. Bootstrapping a merge-mined coin is basically as challenging as any other PoW mechanism, but there are a handful of coins that have crossed the chasm. Dogecoin, the primogenitor of meme-coins, is (hilariously) the best example of such a chain. Perhaps Doge deserves its market cap after all!