We reject: kings, presidents, and voting.
We believe in: rough consensus and running code.
The quote from David Clark above seems taken out of a Bitcoin freedom fighter’s manual. Distrust of centralized authorities and decision-making is baked into the Bitcoin protocol. As Satoshi Nakamoto wrote to The Cryptography Mailing List, “Governments are good at cutting off the heads of a centrally controlled networks [sic] like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.”
But Clark wasn’t talking about Bitcoin at all: he was speaking a full 16 years ahead of the Bitcoin whitepaper, at a conference put on by the Internet Engineering Task Force (IETF), an organization dedicated to developing and maintaining the open-source standards that the internet is built on top of.
Bitcoin is decentralized and open-source, which means that there’s no centralized authority that determines protocol upgrades and that anyone can freely use, modify, and change the code. That doesn’t mean that Bitcoin is governed anarchically. Instead, Bitcoin follows a governance model of collaboration following a tradition of open-source software, and the process Bitcoin uses to update its software borrows heavily from the Request for Comments format which was created in 1969 as a part of ARPANET.
Bitcoin is both a technology and a currency. While Bitcoin transactions are immutable and preserved forever on the blockchain, the underlying protocol is being continually improved and upgraded. Just because there isn’t a centralized party controlling this development, doesn’t mean that the underlying protocol stays the same year after year.
Upgrades to Bitcoin’s protocol are proposed and executed through Bitcoin Improvement Proposals (BIPs). BIPs provide a standardized process for contributors to propose new ideas to the protocol, test them, and subject them to peer review. This system of checks and balances is intended to allow continual innovation on the protocol, while making sure that improvements are implemented through consensus and collaboration.
In this article, we’ll break down the BIP process for upgrading the Bitcoin protocol and show how governance of the protocol works in action.
The Need for BIPs
The Bitcoin code was originally written entirely by Satoshi Nakamoto as an experiment to validate that a decentralized peer-to-peer currency like BTC was actually possible. To the surprise of many, it worked.
But that meant that in the early days of Bitcoin, there was no standard for collaborating and developing the protocol. Satoshi Nakamoto authored most of the original code himself, along with subsequent updates and technical improvements. He solicited feedback from the Cryptography Mailing List, an internet email list for cryptographers, and eventually created the BitcoinTalk Forum, a web forum devoted to Bitcoin.
Ultimately, however, control of the protocol rested in Satoshi’s hands. When someone reported to Satoshi that a bug in Bitcoin’s code base made it possible for anyone to spend other people’s bitcoins, Satoshi pushed an update to the Bitcoin protocol and told everyone on the network to upgrade their client, without explaining why.
To survive, Bitcoin needed to develop processes that would make it less dependent on one individual, relying instead on a larger community of developers. This was enabled by the departure of Nakamoto from the Bitcoin project.
In the early years, Satoshi Nakamoto had enlisted the help of Gavin Andresen, a developer who was active in the community. When Nakamoto announced he was leaving the project in 2011, he handed over the reins to Andresen. Andresen didn’t want to accept responsibility for the code completely on his own, so he enlisted the help of four other developers: Pieter Wuille, Wladimir van der Laan, Gregory Maxwell, and Jeff Garzik. These developers became known as the “Bitcoin Core developers,” as they administered the development of the main Bitcoin Core client implementation.
Historically, the Bitcoin Core developers have been responsible for the majority of development on the Bitcoin protocol. They maintain Bitcoin’s codebase and are the only ones with the ability to push live code to the Bitcoin Core client. While hundreds of people have contributed code to Bitcoin over the years, only a dozen or so have ever had commit access to the code base.
While this has led to the perception that Bitcoin Core developers wield an authoritarian influence over the protocol’s development, that isn’t actually the case. Core developers engage in a process of rough consensus to determine what is ultimately included.
Maintainers — developers who have commit access to the Bitcoin Core Github repos — will take into consideration if a patch:
- is in line with the general principles of the project
- meets the minimum standards for inclusion
- aligns with the general consensus of contributors.
As Jameson Lopp, a contributor to Bitcoin Core, points out:
While it is technically possible for a maintainer-organized coup to hijack the GitHub repository, censor dissenting developers, and perhaps even maintain the brand name of “Bitcoin Core,” the result would be that Bitcoin Core would stop being the development focal point. Developers who disagreed with the actions of the maintainers would simply fork the code and shift their work to a different repository over which the Bitcoin Core maintainers had no administrative privileges.
Nevertheless, as the Bitcoin network grew over the years, partisan debates around scaling, technical improvements, and more reinforced the perception that Bitcoin Core exerted absolute control over the protocol. Perception of Bitcoin Core developers’ influence over development even led the Bitcoin Cash community to refer to the original Bitcoin chain as “Bitcoin Core.”
The Bitcoin Improvement Proposal process was established to open up discussion around Bitcoin’s development process and make it more accessible by more members of the community. It was intended to formalize many of the processes already in use by Core developers.
Anatomy of a BIP
The Bitcoin Improvement Proposal, a standard for proposing improvements to the Bitcoin Protocol, was proposed by Amir Taaki in 2011 in BIP 0001 and expanded on in BIP 0002 by Luke Dash Jr.
The BIP process drew heavily from the Python Enhancement Proposal (PEP 0001), even directly copying some of the text. It also refers to a document called “On Consensus and Humming in the IETF,” a collection of principles for open-source collaboration from the Internet Engineering Task Force.
The goal of the BIP process is to allow anyone to propose improvements to the Bitcoin protocol, but also to thoroughly vet ideas for security and feasibility, before implementing any code that could threaten the stability of the network.
The process is meant to allow the community to establish rough consensus around proposed ideas. P. Resnick defines rough consensus as follows:
Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.
Giving the community the ability to propose ideas, peer-review ideas, and achieve consensus around them is critical in the development of a decentralized protocol like Bitcoin — one that doesn’t have leaders. Since the BIP process was established, there have been 191 contributors to the BIP Github repository.
There are three different types of BIPs:
- Standards Track BIPs propose a change to the Bitcoin, including changes to the network protocol, block or transaction validity rules, or any changes that impact the interoperability of applications that use Bitcoin.
- Informational BIPs describe design issues in the protocol or provide information to the community. They do not propose implementing a new feature to the protocol.
- Process BIPs: propose a process around developing Bitcoin, or propose changes to a process. They don’t directly impact Bitcoin’s codebase, but they may include new procedures, changes to decision-making in development, or changes to tools used in developing Bitcoin.
Each BIP must move through several different stages before it can be implemented. Here’s an image from BIP 001 that describes this workflow:
To be implemented, a BIP must move from the draft stage, to proposed, to final.
- Draft: the BIP is submitted as a draft to the Bitcoin dev mailing list and the BIP Github repository.
- Proposed: the BIP includes a working implementation with a plan for deploying the BIP.
- Final: the BIP has met criteria for adoption in the real world. This must be objectively verified.
Along the way, a BIP can be rejected by the community, withdrawn, or replaced:
- Deferred: The author of the BIP can change its status to deferred when no progress has been made on it.
- Withdrawn: The author of the BIP may also choose to withdraw the BIP from consideration altogether.
- Rejected: Anyone is allowed to request a BIP be moved to Rejected if no progress has been made in three years.
- Replaced: If a previously Final BIP becomes irrelevant, it is marked as Replaced. This could happen if, for example, a BIP implemented in a soft fork is overturned by a hard fork three months later.
Below, we’ll walk through how the two major phases of this process work in more detail.
Draft
The goal of the draft stage is to format new ideas for Bitcoin into a standardized BIP, and start soliciting feedback from the community as quickly as possible.
- The author of a BIP is responsible for vetting the idea with the community to assess the feasibility of the idea and build community consensus around it. They should share ideas to the Bitcoin developer mailing list as well as technical forums on Bitcoin Talk. This helps establish whether the idea is original, feasible, and warrants an independent BIP.
- The author creates a draft BIP and presents it to the Bitcoin dev mailing list for discussion. This allows the author to present the idea in the standard format of a BIP and address any additional concerns from the community.
- Following discussion, the author submits the proposal to the BIP git repository as a pull request. The editor of the BIP repository assigns the proposal a number, labels it according to type, and adds it to the repo. BIP editors can only reject a BIP if it fails to meet specific criteria — for example, if the proposed update is unclear, or if it is technically unsound.
- To move the Draft to proposed, the BIP when the author has addressed any objections from the community, deems that the draft is complete, and includes a working implementation of the proposal in the draft.
The draft phase is meant to allow the author to solicit feedback from the community and revise the BIP to address any objections made in this stage. Once the draft phase is completed and the BIP has been submitted, it then is moved to the proposed stage.
Proposed
When a BIP’s status is changed to proposed, it’s now ready to move from discussion to deployment in the actual Bitcoin protocol. To do this, each BIP needs to include specific criteria that outline how real-world adoption can be objectively established.
Typically, that means that a BIP needs to be implemented into the code through either a soft fork or a hard fork.
A soft fork introduces a backward-compatible change to the protocol, meaning that nodes running the latest version of the software remain compatible with nodes running older versions.
Unlike soft forks, hard forks introduce protocol changes that aren’t backward-compatible. That means that if a significant number of nodes don’t upgrade their client to include the new software, the chain splits in two, as was the case with the Bitcoin Cash hard fork. As a result, hard forks are a much riskier way to implement BIPs.
BIP 002 provides some guidelines for establishing how a BIP can be finalized by a soft fork or hard fork:
- Soft-fork BIPs require activation by “a clear miner majority.” The recommended guideline for establishing this majority is that 95% of nodes approve it by upgrading their software to include the BIP. A soft-fork-activated BIP must include the time that a BIP will be active on the network.
- Hard-fork BIPs, on the other hand, require adoption from the entire community. Nodes on the network need to upgrade to the client software that includes the BIP. BIP 002 states that hard fork BIPs “require adoption from the entire Bitcoin economy,” including holders of Bitcoin, and those providing services with Bitcoin. It acknowledges that this may not be feasible.
Given the difficulty of meeting the requirements of a hard-fork BIP, no BIPs have actually been implemented via a hard fork.
Only when a BIP has been successfully implemented through a hard fork or a soft fork and implemented in the Bitcoin protocol is it considered “Final.”
Reaching Consensus on a Decentralized Network
Bitcoin runs on a decentralized network powered by nodes, users, developers, and miners. It operates without the intervention of centralized parties that control the direction of the protocol. But while transactions made on Bitcoin are permanent and immutable, the underlying technology that powers the protocol is continually improving. While the protocol reaches consensus around transactions through proof-of-work mining to finalize transactions, it also must reach a different type of social consensus around how to improve and update the protocol over time. The BIP process is key to how developers can collaborate and contribute to Bitcoin in a decentralized and open way.
The above references an opinion and is for informational purposes only. It is not intended as and does not constitute investment advice, and is not an offer to buy or sell or a solicitation of an offer to buy or sell any cryptocurrency, security, product, service or investment. Seek a duly licensed professional for investment advice. The information provided here or in any communication containing a link to this site is not intended for distribution to, or use by, any person or entity in any jurisdiction or country where such distribution or use would be contrary to law or regulation or which would subject SFOX, Inc. or its affiliates to any registration requirement within such jurisdiction or country. Neither the information, nor any opinion contained in this site constitutes a solicitation or offer by SFOX, Inc. or its affiliates to buy or sell any cryptocurrencies, securities, futures, options or other financial instruments or provide any investment advice or service.
