Partnered With:

What goes on behind the scenes of Bitcoin's development (PART 1)

Read this article in 13 Minutes

A brief history of Bitcoin: Look at the timeline of its development and understand the philosophy behind the current state of bitcoin development

The Incomplete History of Bitcoin Development

原文作者：0xB10C

Ah Jian is a fan of Ethereum

To fully understand the reasons behind the current state of bitcoin development, it is necessary to understand some historical events. This paper focuses on the historical events, software releases and bug fixes before and after Satoshi Nakamoto left the project. An additional chapter on the current state of bitcoin development has been added. The timeline attached to the article provides additional detail on each incident.

I'm not a witness to most of the events here. So a large portion of this timeline is taken from a talk by John Newbery called "The History and Philosophy of Bitcoin Development." The title of this article is also very clear. This article does not and cannot cover every important event. History is always changing, and if you think I'm missing something, or would like to suggest that I make some changes, please submit an issue in the open source project Bitcoin-Development-History, which is my way of attaching more timelines.

When Satoshi nakamoto was still around

The timeline starts in early 2007. Satoshi Nakamoto started developing bitcoin. This peer-to-peer electronic cash system has no credibility. The entire system is completely controlled by the software the user runs.

Early on, nakamoto was joined in his work by contributors. In addition to the development of the software, these new contributors have added support for Linux and maxOS operating systems. By the summer of 2010, Nakamoto had made some key changes to the software. For example, "checkpoints" were introduced as a security measure against attacks that spread low-difficulty chains. Nodes that use these checkpoints reject chains that have a particular height that doesn't match a particular block. The checkpoints were hardcoded by Nakamoto alone, which, in theory, allowed him to decide which chain the entire network followed.

A few days after the checkpoint was added, Satoshi nakamoto released the first consensus mechanism change in v0.3.3. Mr. Nakamoto urged users to upgrade. Over the next month, several minor updates were released. One of them fixed a deadly overflow vulnerability. This vulnerability was exploited to create two high-value UTXOs. Mr. Nakamoto suggested that miners reorganize blocks containing malicious transactions.

A week later, Nakamoto added an alert system to alert node operators to similar bugs and problems in the network. The alarm system has a safe mode. This secure mode, once triggered, disables all RPC methods for handling money across the network. Only Satoshi Nakamoto can sign with a private key to create a valid network alert. Some users are asking what would happen if someone else, say a government, got hold of the private key.

At this point, Satoshi nakamoto had too much power over the bitcoin network. But the main concern is not that Satoshi nakamoto will go bad and destroy the entire network, but that there should not be a single point of failure in a decentralized network.

In October 2010, Nakamoto posted his last post on the BitcoinTalk forum, announcing the removal of the safe mode. "I'm ready to go somewhere else," Nakamoto wrote in one of his last emails. "With Gavin and everyone, the project will be well maintained." Some argue that Mr Nakamoto's departure from the bitcoin world is one of his greatest contributions.

After Nakamoto left

Around the same time, the entire development process moved from SVN to GitHub. BlueMatt, SIPA, Laanwj and Gmaxwell joined the project. In mid-2011, the BIP (Bitcoin Upgrade Proposal) process was created. During the last quarter of 2011 and the first month of 2012, the community discussed multiple proposals that would allow recipients of transactions to specify spending conditions. Thus, the P2SH transaction introduced bitcoin.

In late 2012, the Bitcoin Foundation was announced. The Bitcoin Foundation is modeled after the Linux Foundation. Under the post, some people expressed concern that development would become centralized.

Bitcoins v0.8.0 & have spent Released in the spring of 2013. Two weeks later, an unexpected hard fork broke out between upgraded and unupgraded nodes in the network. The hard forks were quickly resolved, with miners switching mining power to a chain that worked on both upgraded and unupgraded nodes.

In late 2013, Bitcoin software changed its name to Bitcoin Core. Over the next few years, companies including Chaincode and Blockstream were formed. Later, the MIT Digital Currency Initiative joined Chaincode and Blockstream to pay bitcoin developers and researchers. In February 2015, Joseph Poon and Tadgw Dryja published the first draft of the Lightning Network White Paper.

The following year, Luke Dashjr revised the BIP process through BIP 2; Bitcoin Core released V0.13.0, adding SegWit as a soft fork. In November 2016, the alert system was completely phased out. By August 2017, SegWit was active on the Bitcoin network. In 2019, another company, Square Crypto, began funding bitcoin development. In May 2019, Pieter Wuille presented BIP Taproot.

The current state of bitcoin development

Over the past few years, bitcoin's development culture has become increasingly decentralized, targeted and rigorous. There are currently six maintainers of the Bitcoin Core code base in three countries. Only they can incorporate code changes proposed by contributors. However, before content can be merged, the changed content has to go through a much more rigorous review process.

For example, in the early days of Bitcoin, there was a rival proposal to P2SH called "OP_EVAL." A pull request (" merge request ") that implements OP_EVAL was incorporated into the code base at the end of 2011. Even code that makes such a significant change to consensus has only one reviewer. Russell O "Connor has opened an issue criticizing part of the implementation and arguing that such a large, consensual change should have been reviewed and tested more.

This prompted an ongoing discussion about how to achieve higher quality code through more testing and review. Today, every merge request is reviewed by multiple developers. If a change touches on a critical part of security or even consensus, the review process needs to be reviewed by more auditors, requires extensive testing, and can often take months. As active Bitcoin Core contributor John Newbery told me, "Gone are the days when you can merge consensus-affecting code with the approval of just one reviewer."

A lot of effort has also been put into automated testing, such as unit tests written in C++ and functional tests written in Python. Each significant change requires updating existing tests or adding new tests to the framework. In addition to unit and functional testing, fuzzy testing was done on Bitcoin Core and a benchmark framework was established to measure code performance. For example, the Bitcoinperf.com network provides Grafana and Codespeed interfaces to visualize the results of periodic benchmarking.

After years of effort, Bitcoin Core software has formed a clear distribution process. Major versions of Bitcoin Core are released every 6 months. The release plan includes a translation process, a feature freeze process, and often multiple release candidates. Recently Cory Fields and Carl Dong have also worked on improving the security of the Bitcoin Core build process, using deterministic and bootable build packages. The new build system may not be ready to support The upcoming Release of Bitcoin Core V0.19.0 this fall, but it could provide better build process security in the future.

conclusion

In a decade, bitcoin's development culture has changed dramatically, from being highly centralized around Satoshi nakamoto to decentralized around a few thousand GitHub contributors (as of 2018). Clearly, high standards of code review, code quality, and security are needed. These standards have been followed and consistently improved.

I think understanding these historical events is essential to fully understanding the philosophy behind the current state of bitcoin development. So I made a timeline to string together more events.

For further research, I recommend reading NBSP. Alex B. Written & have spent The Tao Of Bitcoin DevelopmentThe Chinese version), Eric Lombrozo Written & have spent The Bitcoiin Core Merge Process (BITcoiin Core Merge Process); And & have spent Jameson Lopp Work & have spent Who Controls Bitcoin Core? (Who controls Bitcoin Core?) .

Thank you

Thanks to John Newbery for helping me organize and review this article. He said in his own speech. I have done a lot of historical research work in History and Philosophy of Bitcoin Development, and this speech is also the basis of this article. Also, I'm very grateful to Chaincode Labs for inviting me to their 2019 Summer Residency, where I met so many interesting people and learned so much, and it was there that I started working on the timeline and writing this article.