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.

While the vulnerability has been fixed, Jeffrey 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.

Corebleed 1

Slide from Pitfalls of Consensus Implementation, by Christopher Jeffrey

While implementations that are forked from Bitcoin Core were vulnerable to this attack, such as Bitcoin Cash and Zcash, and other implementations of Bitcoin which were created independently, such as btcd, and Jeffrey’s own implementation, bcoin, Bitcoin Core developer, Pieter Wuille, has already supplied a working fix. Bitcoin Core Developer, Gregory Maxwell, described the update to Bitcoin Core as a covert fix, claiming that the stated reason for the release was “cover for the change.“

Theoretically, if this denial-of-service (DoS) vector were to have been exploited in Bitcoins mainnet, it could have shut down a significant portion of the nodes running Bitcoin. Only those nodes backed by beefy servers could survive this attack. 

There are two versions of this attack: a miner version and a non-miner version. The 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. Jeffrey claimed that 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. The non-miner version of this attack is relatively simpler, and more obscure. Both versions of the attack that he discussed require hundreds of thousands of dollars in cost and months of highly visible preparation.

It's not a lot of money or time if we consider large organizations wanting to shut down Bitcoin for the sake of it, Jeffrey pointed out while 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.

Corebleed 2

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.

Corebleed 4When 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.

Corebleed 4

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. 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.