Bitcoin attack, ‘Corebleed,’ demonstrates the need for node decentralisation

At the Breaking Bitcoin Conference in Paris last weekend, speakers from around the world gave talks about breaking down the technicals of different implementations such as Segwit2x, Bitcoin Unlimited, and IOTA.

The most controversial talk was given by alternative Bitcoin implementation developer, Christopher Jeffrey, who revealed to a live audience of about 200 developers, academics, and professionals in the Bitcoin space how he broke the default Bitcoin implementation, bitcoind, better known as Bitcoin Core.

He drove the point home that the software ecosystem in the Bitcoin protocol is glaringly centralized. While Reddit and Twitter conversations focus on the threat to decentralization that miners pose to Bitcoin, Jeffrey highlighted a less popular, though equally harrowing threat: development centralization.

More than 99% of the Bitcoin network today runs Bitcoin Core, which is the default software implementation served by the package managers in most major operating systems. Jeffrey drove this point home by giving a poignant live demonstration.

Opening his talk, Pitfalls of Consensus Implementation, Jeffrey demonstrated a denial-of-service (DoS) attack by running a script which caused bitcoind nodes to allocate excessive amounts of memory, causing them to grind to a halt. This was a successful out-of-memory (OOM) attack executed in the Bitcoin testnet.

This OOM attack on Bitcoin Core, dubbed Corebleed, focuses on machine details, abusing memory, CPU, and disk I/O bottlenecks. This, combined with targeting the consensus layer, “which cannot be ignored by nodes,” Jeffrey notes, would break Bitcoin by bricking the nodes that were running Core software.

Theoretically, if this denial-of-service (DoS) vector were exploited in mainnet, it would shut down a significant portion of the nodes running Bitcoin. Only those nodes backed by beefy servers could survive this attack. However, Jeffrey claims that this would take months to set up.

There are two versions of this attack: a miner version and a non-miner version. The miner version remains strictly theoretica, simply because it is cost prohibitive to execute.

Slide from Pitfalls of Consensus Implementation, by Christopher Jeffrey

This theoretical miner version of the attack would result in 24 gigabytes of data read into memory, and that is the number we would take at face value. In reality though, Jeffrey emphasized, due to the C++ heap, “the memory usage is amplified 3 or 4 times, so it’s probably more like 100 gb.” To pull off this attack, you would essentially have to be a miner. Moreover, the setup phase would be very obvious and people would notice it right away.

The non-miner version of this attack is relatively simpler, more obscure, and less costly to pull off. Done in practice, it would take months to setup and millions of dollars in USD to take down the Bitcoin network as we know it.

It's not a lot of money or time if we consider large organizations wanting to shut down Bitcoin for the sake it, a point Jeffrey drove home in demonstrating this on the majority implementation with the lion’s share of the market. Wipe out Bitcoin Core and you wipe out more than 90% of Bitcoin.

This OOM attack is done by going after “the heart and soul” of Bitcoin: Unspent Transaction Outputs (UTXOs). Mechanically, Jeffrey explains, indexing new UTXOs requires all of the outputs to be stored under the same database record each transaction.

When a spend occurs via an “input,” a single output in the UTXO index is referenced (in green). However, spending a “vector-based UTXO,” as it’s called, requires that a spend input reads the entire database record and stored into memory until the process has been completed.

Jeffrey walked the audience through a key distinction that even seasoned developers have difficulty grasping the subtleties of: protocol versus implementation details which cause network defects.

As this attack is possible due to an implementation detail, it is easily remedied by diversifying the Bitcoin software environment, where multiple implementations with a spread out market share were running in parallel.

The list of alternative implementations is short but varied. Bcoin.io is an alternative to the Bitcoin reference client written in node.js by Jeffrey himself. Btcd is used by lnd, the Lightning Network, written in Go by Dave Collins, Core developer of Decred. Libbitcoin is another, written in C++ by Amir Taaki, who was also present at Breaking Bitcoin. These, along with several other alternative implementations, can be paths toward decentralizing the development space in Bitcoin, leading to a resilient network that couldn't be taken down by a single virus or attack.

All implementations that are forked from Bitcoin Core are vulnerable to this attack. Implementations like Bitcoin Cash, Zcash, and other alternative currencies fall in this category.

However, Bitcoin Core developer, Pieter Wuille, also proposed a performance boost to Bitcoin Core called pertxout in Apri, Core 0.15. While the upgrade is as yet untested, this upgrade from the old vector-based UTXO model to a pertxout model inadvertently amends the OOM attack.