Bcoin: “Menace” to the Bitcoin Network?

In the context of Satoshi Nakamoto’s early warning to Gavin Andresen in 2010 on Bitcointalk against building minority versions of the Bitcoin protocol, secondary implementations were at the time dubbed “menace” to the network.

“I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.” – Satoshi Nakamoto

But circumstances are different now that we are in 2017. And so is the code.

The Birth of Bcoin

Follow the development history of Bitcoin Core and the path quickly reveals a high technical barrier of the consensus code due to its patchwork nature from the contributions of different developers. The difficult and complicated code history makes it functionally prohibitive to reference or build atop of from scratch, even for experienced developers. This is why Bcoin – a library derived from the Bitcoin Core code – has been constructed Purse told BTCManager.

Originally developed as a Simple Payment Verification (SPV) node, Bcoin’s now full node evolved from the need of reliable and secure infrastructure for future features to build on, particularly – but not limited to – the needs of Purse’s merchant platform and its rapidly expanding user base.

Minority implementations like Bcoin, Bitcore, bitcoinjs, and Btcd, to name a few, were inevitably built to diversify reference versions of Bitcoin’s code base. Hailed by software developers as their go-to library for simplifying complicated “bitcoin things,” Bcoin will indeed be battle-tested across applications and use cases.

Key Features

Distinct from the C++ language that the original consensus code was written, Bcoin is written in ubiquitous JavaScript, allowing it to run on “almost any browser, on laptops, on servers, on smartphones, on almost any device you can imagine…” according to Bcoin documentation. It supports Versionbits, CSV, Segwit, BIP70, BIP151, BIP152, BIP150, and MAST.

Alternative Implementations as a Hedge Against Single Points of Failure

Christopher Jeffrey, nicknamed JJ, CTO of Purse, spoke to BTCManager about comparing notes with Olaoluwa Osuntokun, aliased Roasbeef, Chief Scientist of Lightning Network – LN being the standout second-layer instant payment verification solution built upon an off-chain, trustless, distributed architecture. Similarly, the beauty of the blockchain-compatible Bcoin full node is in allowing users – network node operators – to confirm valid transactions without trusting other nodes for verification, thereby mitigating exposure to counterparty and centralization risks.

Christopher Jeffreys, ironically tokened the Bitcoin Menace, turns out to be the opposite of a force of malice. While Satoshi’s original avowal was technically reasonable while Bitcoin’s consensus code was in the hands of a few developers and Bitcoin the network was a vulnerable one-year-old in 2010, Bitcoin has since grown to stand on its own two feet supported by a robust community of experienced developers. The risk now and everywhere is in centralization. The code itself is not immune to such risk.

In the same thread as mentioned above on Bitcointalk, Gavin Andresen pushed back to Satoshi, saying, “…SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They’ll either hack the existing code or write their own version, and will be a menace to the network.”

In 2011, as predicted by Gavin Andresen, the trend of alt-clients was started by libbitcoin founder, Amir Taaki, contra to Satoshi’s wishes for maintaining the single reference client.

Taaki detailed such code centralization risk in The libbitcoin Manifesto:

“A diversified Bitcoin of many wallets and implementations is a strong and pure Bitcoin. To protect the integrity of the network, we need to eliminate single points of failure. An inbred Bitcoin with the same software code everywhere shares the same weaknesses and is susceptible to the same attacks. A single pathogen can wipe out a genetically homogenous population. And centralized software is vulnerable to the dictates of whoever controls [the] development of that software code, and any dictates pressured onto them.”

Andresen was correct in his warning about “menaces” to the incumbent code rising into the equation – many re-implementations have since been created in the wake of Satoshi’s departure from communications – but the storied somebody perhaps has more benevolent and pragmatic intentions in creating their own versions than was predicted.

Jeff Garzik wrote in his BIP100 block size change proposal:

“In the world of computer networking, the lowest layers of networking are irreversible, one-­way messages… IP, the Internet Protocol, requires additional, upper-­layer protocols TCP and HTTP to be useful. Yet IP forms the foundational layer of the Internet. Bitcoin protocol and network today is that foundational layer.”

If the Bitcoin protocol is anything like the Internet Protocol that Garzik illustrated, to receive the enormous wave of real-world solutions and applications that are about to crash through the innovation pipeline, then solid, trustless, production-ready alternative implementations appear to be mission-critical for Bitcoin to manifest mainstream success. Purse.io has been testing Bcoin and running it in production since October 31, 2016. It remains to be seen whose – Satoshi’s or Taaki’s – time-tested version of reality will concede.