Author: Kalle Rosenbaum & Linnéa Rosenbaum
Bitcoin is built using open-source software. In this chapter, we'll analyze the implications of this fact, how to maintain open-source software, and how open-source software in the Bitcoin ecosystem allows for license-free development. In the section "Choosing Cryptography," we'll briefly discuss how to select and use upstream codebases in a cryptographic system. This chapter also includes a subsection focusing on the code review process in Bitcoin development, followed by how Bitcoin developers obtain funding. The final section discusses Bitcoin's open-source culture, which may seem strange to outsiders, but this seemingly odd phenomenon is precisely a sign of health.
The vast majority of Bitcoin software, especially Bitcoin Core , is open source. This means that the software's source code is publicly available for anyone to review, patch, modify, and redistribute. The definition of "open source" on https://opensource.org/osd includes, but is not limited to, the following key points:
Free distribution
The license shall not restrict any party from selling or giving away the software as part of a complete software distribution that includes programs from various sources. The license shall not require royalties or other fees to be charged on such sales.
source code
The program must include source code and must allow the distribution of both the source code and its compiled form. When certain forms of a product are not distributed with the source code, there must be a publicly available form that allows users to obtain the source code at a reasonable copying cost, ideally through free internet download. The source code must be the preferred form for programmers when modifying the program. Intentionally obscuring the source code is not permitted. Using intermediate forms, such as the output of a preprocessor or translator, is also not allowed.
Derivative works
The license must allow for modification and derivative works, and must allow them to be distributed under the same terms as the original software license.
— Definition of "open source", open source movement website
Bitcoin Core follows this definition and is distributed under the MIT license :
The MIT License (MIT)Copyright (c) 2009-2022 The Bitcoin Core developersCopyright (c) 2009-2022 Bitcoin DevelopersPermission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files (the "Software"), to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software. MIT 许可（MIT）版权（c）2009-2022 Bitcoin Core 开发者版权（c）2009-2022 Bitcoin 开发者在此将许可免费地授予任何获得了本软件和相关说明书文件（即“本软件”）的人，可以不受限制地处理本软件，包括不受限制地使用、复制、修改、合并、出版、分发、转许可、以及/或者销售本软件之拷贝的权利；并且得到本软件服务的人也得到同样的许可；上述许可仅受制于下列条件：上述版权声明和本许可声明必须包含在本软件的所有拷贝和主要部分中。(Translator's note: In the copyright notice, "Bitcoin Core" and "Bitcoin" both refer to the software.)
As noted in Chapter 2.1 of this book ( Chinese translation ), it is crucial that users be able to verify that the Bitcoin software "works as claimed." For this to be possible, users must have unrestricted access to the source code of the software they wish to verify.
In later chapters, we will delve into some of the interesting aspects of open-source software in Bitcoin.
7.1 Software Maintenance
The source code for Bitcoin Core is maintained in a Git repository hosted on GitHub . Anyone can clone this repository without requesting permission from anyone; then, they can inspect, compile, and modify it on their own devices. This means that there may be thousands of copies of this repository scattered around the world. They are all copies of the same repository, so what makes this source Bitcoin Core repository so special? Technically, it's nothing special; but socially, it has become a focal point for Bitcoin development.
(Translator's note: A "Git repository" means a codebase managed using a distributed collaborative software called Git. Distributed collaboration means that people each copy the codebase and modify it independently, and then seek code merging; in this process, Git can help people analyze code changes and reduce conflicts.)
Bitcoin expert and security expert Jameson Lopp explains this very well in his blog post, " Who Controls Bitcoin Core? ":
Bitcoin Core is a focal point for Bitcoin protocol development, not a command or control point. If it ceases to exist for any reason, a new focal point will emerge—the technical community platform hosting the codebase (currently GitHub) will only affect convenience, not the completeness of the definition/project. In fact, the focal point of Bitcoin development has changed platforms and even names!
— Jameson Lopp, "Who Controls Bitcoin Core?" (2018)
He then explained how Bitcoin Core software is maintained and how it resists malicious code changes. The main points of the entire article can be summarized at the end:
No one controls Bitcoin.
No single person controls the focus of Bitcoin development.
— Jameson Lopp, "Who Controls Bitcoin Core?" (2018)
In his Medium article titled "The Bitcoin Core Merge Process," Bitcoin Core developer Eric Lombrozo further explains this development process:
Anyone can copy this base codebase and then make any modifications to it within their own. They can compile a client using their own codebase instead of running the software compiled from the base codebase, if they wish. They can also release pre-compiled binaries for others to run.
If someone wants to merge their changes to their local codebase into Bitcoin Core, they can submit a "pull request (PR)". Once submitted, anyone else can review the changes and comment on them, regardless of whether they have merging privileges with the Bitcoin Core codebase.
— Eric Lombrozo, *The Bitcoin Core Merge Process* (2017)
It should be noted that a PR may take a long time to be reviewed before it can be merged into the codebase by the "maintainer". This is usually because the PR lacks review (see Chapter 7.5 for details); and the lack of review is usually due to a lack of reviewers .
Lombrozo also discusses the process surrounding changes to the consensus rules, but that's somewhat beyond the scope of this chapter. More information on this topic (Bitcoin protocol upgrades) can be found in Chapter 5 of this book ( Chinese translation ).
7.2 License-free development
We already know that anyone can write code for Bitcoin Core without requesting permission, but that doesn't necessarily mean they can merge it into the original Git codebase. This applies to any modifications, from the color scheme of the graphical user interface to the format of peer-to-peer messages, and even to consensus rules—the set of rules that define a valid blockchain.
Perhaps equally important, users are free to develop systems built on the Bitcoin protocol without requiring any authorization. We have already seen countless successful software projects built on Bitcoin, such as:
Lightning Network
This is a payment network that allows for very small, rapid payments. It only requires a small number of transactions to be confirmed within the Bitcoin blockchain. Several interoperable software implementations are now available, including Core Lightning , LND , Eclair , and the Lightning Dev Kit .
CoinJoin
Multiple participants combine their payments into a single transaction, making "address clustering" more difficult ( explained in Chapter 3.4 of this book). Several software implementations already exist.
side chain
Such a system allows a coin to be locked within the Bitcoin blockchain and then unlocked on other blockchains. In other words, Bitcoin can flow to other blockchains, or "sidechains," to utilize their features. Examples include Blockstream's Elements .
OpenTimestamps
It allows you to privately timestamp a document within the Bitcoin blockchain. You can use this timestamp to prove that the document must have existed before that specific moment.
Without permissionless development, many such projects would not be possible. As stated in Chapter 1.3 of this book ( Chinese translation ), if developers had to request permission to develop protocols on Bitcoin, then only projects permitted by the Central Developers Council would be developed.
The projects listed above commonly identify themselves as open-source software, which in turn allows people to contribute code, reuse, and audit these projects without requesting any permission. Open-source development has become the gold standard for Bitcoin software licensing.
7.3 Anonymous Development
Developing Bitcoin does not require permission, which brings an interesting and important option: you can write and release code for Bitcoin Core and any other open-source project without revealing your identity.
Many developers do this: using pseudonyms and trying to separate the pseudonym from their real identity. The reasons for doing so vary. One anonymous developer, "ZmnSCPxj," contributes code to Bitcoin Core and Core Lightning (an implementation of Lightning Network clients) among other projects. He states on his personal webpage :
I am ZmnSCPxj, a randomly generated internet persona. My pronoun is "he".
I know people instinctively want to know my real identity. However, I think my identity is basically irrelevant, and I'd rather people focus on my work to get through this.
If you are hesitant to donate, or have doubts about my cost of living or my income, please understand: properly speaking, you should donate based on the value I create for you through my articles or my work on Bitcoin and the Lightning Network.
— ZmnSCPxj, his GitHub homepage
ZmnSCPxj used the pseudonym because he wanted people to focus on his work rather than his (or their) personal life. Interestingly, a post on CoinDesk revealed that the pseudonym itself was created for another reason.
My initial reason for using this pseudonym was that I was worried I might cause a major disaster; therefore, "ZmnSCPxj" was originally intended as a disposable encryption that could be abandoned in this situation. However, it seems to have gained mostly a positive reputation, so I've kept it.
— "Many Bitcoin Developers Are Choosing Pseudonyms, and It Makes a Good Sense" (2021)
Using anonymity actually allows you to speak more freely without worrying about saying something stupid or making a big mistake that could jeopardize your personal reputation. His pseudonym proved to be quite famous, and he even received a developer grant in 2019 , which in itself is proof of Bitcoin's permissionless nature.
However, it's fair to say that the most famous cryptographer in the Bitcoin world is "Satoshi Nakamoto." We don't know why he used a pseudonym, but in hindsight, it might have been a good idea:
- As more and more people speculate that Satoshi Nakamoto owns a large amount of Bitcoin, maintaining a secret identity is necessary for his financial and personal safety.
- Because his identity is unknown, there is no possibility of prosecuting anyone, which leaves many government authorities with nowhere to exercise their authority.
- Without any authority figures to worship, Bitcoin will become more meritocratic and more resistant to ransomware.
Please note that these principles apply not only to Satoshi Nakamoto, but also to varying degrees to anyone who develops Bitcoin or holds a large amount of Bitcoin.
7.4 Preferred Cryptography
Open-source software developers often use open-source code libraries developed by others. This is a natural and surprising part of any healthy ecosystem. However, Bitcoin software deals with real money, and therefore, developers need to be extra careful when choosing which third-party libraries to rely on.
In a philosophical discussion about cryptography , Gregory Maxwell sought to redefine the term "cryptography"—arguing that its original meaning was too narrow. He explained that fundamentally, information should flow freely , and then, based on this, offered his own definition:
Cryptography is the art and science we use to defeat this inherent nature of information; we want information to submit to our political and moral desires, to resist all opportunities and attempts that go against humane ends, and to be guided toward humane ends.
— Gregory Maxwell, Bitcoin Preferred Cryptography (2015)
He then used the new term " selection cryptography," referring to the art of choosing cryptographic tools, and explained why it is an important part of cryptography. This art revolves around how to select cryptographic libraries, tools, and practices; in his own words, it is "the selection of cryptosystems."
Using concrete examples, he demonstrated how easily selective cryptography can lead to disastrous consequences, and presented a list of questions for participants to reflect upon. Below is a selected version of this list:
- Was this software originally developed for your intended purpose?
- Is cryptography being taken seriously?
- The review process... Is there really a review process?
- What is the software author's experience like?
- Does this software come with a user manual?
- Can this software be ported?
- Has this software been tested?
- Does this software employ best practices?
While this is not a definitive guide to success, it can be very helpful to refer to these questions when implementing optimal cryptography.
Because of the issues Maxwell mentioned, Bitcoin Core has made a significant effort to minimize its reliance on third-party codebases . Of course, you can't eliminate all external dependencies, otherwise you'd have to rewrite everything yourself, from font rendering to the implementation of operating system calls.
7.5 Audit
This section is titled "Review" rather than "Code Review" because Bitcoin's security heavily relies on multiple levels of review, not just source code review. Furthermore, different ideas require different levels of review: compared to color scheme changes and typo corrections, consensus rule changes require more layers and deeper levels of review.
On the road to final adoption, an idea typically goes through multiple stages of discussion and review. Some of these stages are listed below:
- This idea was posted in the Bitcoin-dev mailing list.
- This idea led to the development of a Bitcoin Optimization Proposal (BIP).
- This BIP was implemented as a PR for
Bitcoin Core - Deployment mechanisms were discussed.
- Several attractive deployment mechanisms have been implemented as
Bitcoin CorePRs. - The PR was merged into the master branch of the codebase.
- Users can choose whether or not to run this software.
At each stage, the available information—whether it's source code, a BIP, or just a loosely described idea—is reviewed by people with different perspectives and backgrounds. These stages are usually not strictly sequential; multiple stages may run concurrently, or sometimes they may be repeated back and forth. Different people at different stages can provide feedback from different perspectives.
Jon Atack is one of Bitcoin Core's most prolific code reviewers. He wrote a blog post explaining how to review Bitcoin Core PRs. He emphasizes that a good code reviewer focuses on providing the greatest added value.
As a newcomer, your goal is to try to add value, be friendly and humble, and learn as quickly as possible.
A good approach is to avoid being self-centered and instead ask, "How can I better serve everyone?"
— Jon Atack, "How to Review
Bitcoin CorePR" (2020)
He pointed out that review is the real limiting factor for Bitcoin Core . A large number of good ideas are stuck in a rut: without review, they remain stagnant. Note that review is not only beneficial for Bitcoin, but also a great way to add value to software while learning about it. Atack's rule of thumb is: review 5 to 15 PRs before submitting any of your own. Again, your focus should be on how best to serve the community, not on getting your own code merged. Building on this, he emphasized the importance of performing reviews at the right level: Is it time to check for typos, or does this developer need review of the concept more?
When starting the review process, a useful starting question is, "What does it need most right now?" Answering this question requires experience and a growing understanding of the context, but it is a useful question that determines how you can add the most value in the shortest amount of time.
— Jon Atack, "How to Review
Bitcoin CorePR" (2020)
The second half of this article contains many helpful introductory technical guides on how to actually conduct audits; the article also provides links to important documents for further reading.
Bitcoin Core developer and code reviewer Gloria Zhao once wrote an article containing questions she often asked herself when conducting code reviews. She also mentioned what she considers to be the standards for good review.
In my opinion, a good review process involves asking myself many targeted questions about the PR, and all of those questions are answered.
...
Naturally, I would start with conceptual questions, then move on to methodological questions, and then to implementation questions. Generally, I personally believe that leaving C++ syntax-related comments in a PR draft is pointless; moreover, it feels impolite to leave the author with more than 20 code organization suggestions and then ask them "What's the point of this PR?" after they've read them all.
— Gloria Zhao, “Common PR Review Issues”, GitHub (2022)
Her idea is that a good review should focus on what the PR needs most at that moment, which aligns with Jon Atack's advice. She also provides a list of questions you can ask yourself at different stages of the review process, but please note: this list is by no means all-encompassing, nor is it a shortcut. This list is disguised with real-world examples from GitHub.
7.6 Financial Support
Many people contribute to the open-source development of Bitcoin, whether for Bitcoin Core or other projects. Many do this in their spare time without compensation, but some developers are paid.
Companies, individuals, and organizations interested in Bitcoin's continued success may donate funds to developers, either directly or through organizational channels. Some companies focused on Bitcoin may also hire experienced developers to work full-time on the project.
7.7 Culture Shock
People often have the impression that there is a lot of infighting and endless arguments among Bitcoin developers, and that they seem completely incapable of making decisions.
For example, the "Taproot" deployment mechanism described in Chapter 5.2.3 ( Chinese translation ) has been discussed for a long time, during which two opposing camps emerged. One camp hoped to "fail" the upgrade if, after a certain point, miners did not overwhelmingly vote in favor of the new rules, while the other camp hoped to enforce the new rules at a certain point regardless. Michael Folkson summarized the debate between the two camps and posted it in the Bitcoin-dev mailing list.
The debate seems destined to drag on indefinitely, with no end in sight. This is frustrating, and as a result, it's only fueling the controversy. Gregory Maxwell (as user "nullc") expressed concern on Reddit that such a protracted discussion could make an escalation less secure.
At this point, additional waiting will no longer add more review or certainty. On the contrary, additional delays will slow the momentum, potentially increase risks (as people start to forget the details), postpone work on downstream applications (such as wallet support), and if people are comfortable with the activation window, they will not invest as much additional review effort as possible.
— Gregory Maxwell, “Is Taproot Deployment Too Fast or Too Slow?”, Reddit
Ultimately, thanks to the new proposal "Speedy Trial" put forward by David Harding and Russell O'Connor, the dispute was resolved. This proposal is named as such because it provides a relatively short signaling period for miners to either quickly lock in the upgrade or quickly indicate failure. If miners activate it within this signaling period, Taproot will be deployed approximately six months later. This upgrade is explained in more detail in Chapter 5 ( Chinese translation ).
Those unfamiliar with Bitcoin's development process might find these heated debates to be terrible, even toxic. There are at least two factors that make it seem bad to some:
- Compared to closed-source companies, all debates in open-source development occur in a public environment and are unedited. Software companies like Google don't allow their employees to debate proposals in public; instead, they typically issue a statement expressing the company's position on the topic. This makes the company appear more harmonious than Bitcoin.
- Because Bitcoin is permissionless, anyone can express their opinions. This is the complete opposite of closed-source development companies, where only a small number of people can express their views, usually those with similar opinions. The number of opinions within the Bitcoin development team (compared to companies like PayPal, for example) is staggering.
Most Bitcoin developers would say that this openness creates a good, healthy environment, and is even a necessary environment for producing the best results.
As implied in Chapter 6.2 ( Chinese translation ), the second point above can be very beneficial, but it also has a drawback. Attackers can use delaying tactics, as illustrated in the book * Simple Sabotage Field Manual *, to distort the development process and final decisions.
Another point worth noting is that, as discussed in Chapter 7.4, because Bitcoin represents money, and Bitcoin Core protects countless amounts of capital, security is paramount. This is why experienced Bitcoin Core developers may seem stubborn, but this attitude is reasonable. In fact, a feature lacking sound design principles is unlikely to be adopted. The same applies to features that break "reproducible builds" (see Chapter 2.1 ), adding new dependencies, and code changes that do not follow Bitcoin's best practices .
New (and old) developers may find this frustrating. However, as is customary in open-source software, you can always fork the codebase, merge the code into your own copy, and then compile and run your own binaries.
7.8 Conclusion
Bitcoin Core, and most other Bitcoin software, are open source, meaning anyone can freely distribute, modify, and use them. The Bitcoin Core codebase on GitHub is currently the focus of Bitcoin development, but this could change if people begin to distrust the maintainers of the codebase, or even the website itself.
Open source development allows for trustless development, including the development of Bitcoin and systems built on top of it. Whether you're writing code or reviewing code (proposing), open source gives you the freedom to participate, whether you're anonymous or not.
The development process surrounding Bitcoin is extremely open, which makes Bitcoin seem like a toxic and inefficient place, but it is precisely this culture that allows Bitcoin to resist malicious actors.
