Bitcoin Core and other implementations

Wonder

1. Who decides what a block is when two pieces of code disagree?
2. Why does a minor database error have the power to split the chain in half?
3. What happens to the network if the most popular implementation simply stops being maintained?

Explore

1. Bitcoin began as a single C++ client written by Satoshi Nakamoto. In 2011, the interface was rewritten using Qt libraries, and the software became known as Bitcoin-Qt. By 2014, version 0.9 had dropped the suffix entirely to become Bitcoin Core. The name change reflected a shift in identity: this was no longer just Satoshi’s tool but the canonical reference implementation for the network’s rules.
2. Leadership of the codebase passed from Gavin Andresen, who led it from 2010 until he stepped back in 2014, to Wladimir van der Laan. Today, a small group of maintainers merges changes after rigorous peer review. The versioning scheme jumped from 0.21 to 22.0 in 2021, signaling maturity. Major releases occur roughly twice a year, each one subjected to extensive testing before distribution.
3. Consensus is not just about logic; it is about byte-for-byte identical behavior across tens of thousands of nodes. In March 2013, version 0.8 introduced LevelDB as its storage engine. A block accepted by the new software was rejected by older versions running on Berkeley DB due to a lock limit bug. The chain split until miners downgraded, showing that a hidden difference in behavior, not even in the consensus code itself, can split the network.
4. Alternative implementations exist to prevent any single codebase from becoming a point of failure or capture. btcd is written in Go, bcoin in JavaScript, and libbitcoin in C++. Bitcoin Knots, maintained by Luke Dashjr, is a patch set on top of Core with different defaults, notably stricter filtering of data-carrying transactions. Floresta utilizes the Utreexo data structure for efficient verification. These projects serve as checks on Core’s development process.
5. The risk of reimplementing consensus is high because a bug that accepts invalid blocks can lead to financial loss or chain splits. To mitigate this, libbitcoinkernel aims to isolate the core consensus logic into a reusable library. This allows other software to verify transactions without duplicating the entire node codebase, ensuring that the rules remain consistent even as the surrounding infrastructure changes.
6. Run ‘bitcoin-cli getnetworkinfo’ on a node to see its own version, and ‘getpeerinfo’ to see the software each peer reports (its ‘subver’ string). The network maintains interoperability despite using different software stacks, but the dominance of Bitcoin Core means it effectively sets the pace for protocol upgrades. Nodes that do not upgrade keep following the chain through soft forks, but a node whose consensus behavior diverges can be split off.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Bitcoin Core release notes for version 0.9.0 (2014)
• BIP50: March 2013 Chain Fork Post-Mortem
• Bitcoin Core release notes and documentation (bitcoincore.org)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10