To fully understand the rationale behind the current state of Bitcoin development, knowledge about historical events is essential. This blog post highlights selected historical events, software releases and bug fixes before and after Satoshi left the project. It additionally contains a section about the current state of Bitcoin development. The linked timeline provides extra detail for each event.

I wasn’t following the Bitcoin space when a majority of these events happened. A big part of the timeline is adapted from a talk John Newbery gave on the History and Philosophy of Bitcoin Development. The title of this blog post is supposed to remind you that it can’t and doesn’t include every event. History is in the beholder’s eye. History evolves. If you have a suggestion about something missing or want to propose a change, please create an issue in the open-source project bitcoin-development-history, which is used to generate the attached timeline.

With Satoshi

The timeline tells a story beginning in early 2007. Satoshi Nakamoto starts working on Bitcoin. The peer-to-peer electronic cash system with no trusted third party. A system only controlled by the software which its users run.

Early on contributors join Satoshi working on Bitcoin. These new contributors add, next to many other things, support for Linux and macOS to the project. Over the summer of 2010 Satoshi authors a few critical software changes. For example, checkpoints are introduced as a safeguard against malicious peers broadcasting low difficulty chains. A node enforcing these checkpoints rejects chains that don’t include specific block hashes at specific heights. Checkpoints are hard-coded by Satoshi alone which in theory allows Satoshi to control which chain the network follows.

A few days after adding checkpoints Satoshi releases the first consensus change in version v0.3.3. Satoshi urges users to upgrade. Over the next month, multiple minor versions are released. One of them fixes a critical overflow bug. This bug was exploited to create two high-value UTXOs. Satoshi advises miners to reorg the chain containing the blocks with the malicious transactions.

A week later Satoshi introduces an alert system to inform node operators about similar bugs and problems in the network. The alert system includes a safe mode. The safe mode, once triggered, disables all money handling RPC methods in the entire network. Only Satoshi can create valid network alerts by signing them with a private key. Some users raise the question of what could happen when a second party, for example, a government, gets access to this key.

Satoshi has a lot of power over the Bitcoin network at this point. The main concern here isn’t that Satoshi would turn evil and try to destroy the network, but rather that there shouldn’t be such a single point of failure in a decentralized system.

In December 2010 Satoshi opens his last thread on bitcointalk announcing the removal of the safe mode. Satoshi writes in one of his last emails: »I’ve moved on to other things. It’s in good hands with Gavin and everyone.« Some might argue Satoshi stepping away from Bitcoin is one of his greatest contributions.

Without Satoshi

Around the same time, the development process moves from SVN to GitHub, which leads to longtime contributors like TheBlueMatt, sipa, laanwj and gmaxwell joining the project. In mid-2011 the BIP process for Bitcoin Improvement Proposals is introduced. In the last quarter of 2011 and the first months of 2012, the community discusses various proposals, which would allow the receiver of a transaction to specify the script needed to spend it. Out of them, P2SH is merged.

In fall 2012 the Bitcoin Foundation is announced. The Bitcoin Foundation hopes to achieve for Bitcoin what the Linux Foundation does for Linux. Some people raise the fear of development centralization in the announcement thread.

Bitcoin version v0.8.0 is released in spring 2013. Two weeks after the release an unexpected hardfork splits the network in nodes that have and haven’t yet upgraded. The hardfork is resolved fairly quickly. Different miners react by shifting their hashpower to the chain valid for both upgraded and not upgraded nodes.

In late 2013 the Bitcoin software is rebranded to Bitcoin Core. In the following year companies such as Chaincode and Blockstream are founded. Later the MIT Digital Currency Initiative joins Chaincode and Blockstream by paying developers and researchers to work on Bitcoin. In February 2015 Joseph Poon and Tadge Dryja release the first draft of the Lightning Whitepaper. The next year Luke Dashjr revises the BIP process with BIP 2 and the Bitcoin Core release v0.13.0 includes SegWit as a softfork. In November 2016 the alert system is retired and in August 2017 SegWit gets activated. The year 2019 brings a new company, Square Crypto, sponsoring Bitcoin development. In May Pieter Wuille proposes BIP taproot.

The current state of Bitcoin development

Over the years the Bitcoin development culture became more decentralized, well-defined and rigorous. There are currently six Bitcoin Core maintainers, distributed over three continents. Only they can merge commits by contributors. Before commits get merged, however, they have to go through a review process, which has gotten a lot stricter.

For example, a competing proposal, to the earlier mentioned P2SH, was OP_EVAL. The pull request implementing OP_EVAL was merged at the end of 2011. It had only one reviewer, though it changes consensus-critical code. Russell O’Connor opened an issue criticizing parts of the implementation and that such a big and consensus-critical change should have had a lot more review and testing.

This fueled an ongoing discussion on how to ensure higher code quality through more testing and review. Today each pull request should at least be reviewed by multiple developers. If a change touches security-critical or even consensus-critical code, the review process needs many reviewers, a lot of testing and usually spans over multiple months. John Newbery, an active Bitcoin Core contributor, told me that there is “no chance a consensus change would be merged with a single reviewer today”.

A lot of work went into automated testing. There are unit-tests written in C++ and functional-test written in Python. Every non-trivial change should update existing tests or add new ones to the frameworks. Next to unit- and functional-tests, there is an initiative to do fuzz-testing on Bitcoin Core and a benchmarking framework to monitor code performance. The website bitcoinperf.com, for example, offers both a Grafana and a codespeed interface visualizing periodic benchmarking results.

A well-defined release process has been put together over the years. Major releases of Bitcoin Core are scheduled every six months. The schedule includes a translation process, a feature freeze and usually multiple release candidates. Recent efforts by Cory Fields and Carl Dong aim to increase the Bitcoin Core build system security with deterministic and bootstrappable builds. The new build system might not be fully ready for the v0.19.0 release of Bitcoin Core this fall but could provide greater build security in the future.

Conclusion

Over the past ten years, the Bitcoin development culture has changed a lot. Moving from being very centralized around Satoshi to being more decentralized with more than a thousand GitHub contributors in 2018. It has become clear that high standards for code review, code quality, and security are needed. These standards are followed and constantly improved.

I think to fully understand the rationale behind the current state of Bitcoin development, knowledge about historical events is essential. There is a timeline with more events attached below. Some suggested further reading could be The Tao Of Bitcoin Development written by Alex B., The Bitcoin Core Merge Process written by Eric Lombrozo and the blog post by Jameson Lopp: Who Controls Bitcoin Core?

Acknowledgments

I’m thankful for John Newbery helping me to shape and review this blog post. He did a lot of the historical digging for his History and Philosophy of Bitcoin Development talk, which this blog post is based upon. I’m also very grateful for Chaincode Labs inviting me to their 2019 Summer Residency where I met a lot of awesome people, learned a ton and started working on this blog post and the timeline.