Bitcoin Governance: What is BIP (Bitcoin Improvement Proposal) and how do they work?

We refuse: the king, the president and the vote.

We believe: a rough consensus and running code.

– David Clark

The above quote from David Clark is taken from the manuals of the Bitcoin Freedom Fighters. Distrust of those centralized management agencies and decision-making bodies is built into the Bitcoin protocol. As mentioned in the Cryptography Mailing List, “Governments are good at cutting off the smart interface of a central control network like Napster, but pure P2P networks like Gnutella and Tor seem to hold Your own exclusive territory."

• Bitcoin becomes the official currency of Sweden? But only lasted for thirty minutes
• Grab the unicorn of the next wave of cryptocurrency worlds
• Chainge Technology Open Day | 4 hours to see the technical direction of 2019

But Clark isn't talking about Bitcoin at all: it's 16 years before the Bitcoin white paper came out, he spoke at a meeting of the Internet Engineering Task Force (IETF), which is committed to development and Maintain standards built on the open source Internet.

Bitcoin is decentralized and open source, which means there is no centralized authority to decide on protocol upgrades, and anyone can freely use, fix, and change code. This does not mean that Bitcoin is anarchist governance. In contrast, Bitcoin follows the traditional collaborative governance model of open source software. The process of Bitcoin used to update its software draws heavily on the form of Request for Comments created by ARPANET in 1969.

Bitcoin is both a technology and a currency. Although bitcoin transactions are not modifiable and remain on the blockchain forever, their underlying protocols are being continuously improved and upgraded. Just because there is no central institution to control this development does not mean that the basic agreement will remain unchanged year after year.

Upgrades to the Bitcoin protocol are proposed and implemented through Bitcoin Improvement Proposals (BIPs). BIP provides a standardized process for contributors to propose new ideas, test these ideas, and peer review them. This system of checks and balances is designed to allow continuous innovation in the agreement while ensuring improvements through consensus and collaboration.

In this article, we will break down the BIP process used to upgrade the Bitcoin protocol and show how the governance of the protocol works.

Demand for BIP

The Bitcoin code was originally written entirely by Nakamoto to verify whether distributed point-to-point currency like BTC is actually feasible. To the surprise of many people, BTC has played its due role.

But this means that in the early stages of Bitcoin, there was no standard for collaboration and development agreements. Nakamoto has completed most of the original code writing, as well as subsequent updates and technical improvements. He solicited feedback from the cryptography mailing list, which was a cryptographer's Internet e-mail list, and he eventually created the BitcoinTalk Forum, a web forum dedicated to Bitcoin.

However, in the end, the control of the agreement is in the hands of Nakamoto. When someone reported a flaw in the Bitcoin code base to Nakamoto, so that anyone can spend other people's bitcoin, Nakamoto promoted the update of the Bitcoin protocol and told everyone on the network to upgrade their The client did not explain why.

To survive, Bitcoin needs to develop processes to reduce reliance on a single individual and instead rely on a larger developer community. Nakamoto’s exit from the Bitcoin project achieved this.

In his early years, Satoshi Nakamoto had received help from Gavin Andresen, a developer who actively participated in community activities. When Nakamoto announced that he would leave the project in 2011, he handed the reins to Andresen. Andresen didn't want to take full responsibility for the code on his own, so he asked for help from four other developers: Pieter Wuille, Wladimir van der Laan, Gregory Maxwell and Jeff Garzik. These developers are known as "bitcoin core developers" because they are responsible for managing the development of the main Bitcoin core client implementations.

Historically, Bitcoin core developers have been responsible for most of the development of the Bitcoin protocol. They maintain Bitcoin's code base and are the only ones who can push real-time code to the Bitcoin core client. Although hundreds of people have contributed code to Bitcoin over the years, only a dozen people have had access to the code base.

Although this has led to the belief that bitcoin core developers have an authoritarian influence on the development of the agreement, this is not the case. Core developers are involved in a process of rough consensus to determine what is ultimately included in the decision.

The maintainer — the developer who has access to the Bitcoin core Github code repository — will consider whether there are patches:

• Compliance with the general principles of the project
• Meet minimum standards
• Conforms to the general consensus of contributors.

Jameson Lopp, a contributor to the Bitcoin core, pointed out:

Although the maintainer organization is technically likely to launch a hijacking of the GitHub code repository, tamper with dissenting developers, or even maintain a "coup d'état" of the "Bitcoin Core" brand name, the result will be that the Bitcoin core will no longer be the focus of development. . Developers who disagree with maintainer behavior simply fork the code and move their work to a different code repository, while Bitcoin core maintainers do not have administrator privileges.

Despite this, with the development of the Bitcoin network over the years, the debate among believers has been centered on expansion, technological improvements and more progress, deepening the perception that the Bitcoin core has absolute control over the implementation of the protocol. The impact of Bitcoin core developers on development has even led the Bitcoin cash community to call the original Bitcoin blockchain "Bitcoin Core."

The Bitcoin Improvement Proposal process was created to discuss the development of Bitcoin and make it easier for more community members to understand. It is designed to formalize many of the processes that core developers have used.

Analysis of BIP

The Bitcoin Improvement Proposal (BIP) is a proposed standard for improving the Bitcoin protocol, proposed by Amir Taaki in BIP 0001 in 2011 and extended by Luke Dash Jr. in BIP 0002.

The BIP process relies heavily on the Python Improvement Proposal (Python Enhancement Proposal, PEP 0001) and even copies some of the text directly. It also mentions a document called "On Consensus and Humming in the IETF", a set of open source collaboration principles from the Internet Engineering Task Force.

The goal of the BIP process is to allow anyone to suggest improvements to the Bitcoin protocol, but to thoroughly review the security and feasibility of these ideas before implementing any code that could threaten the stability of the network.

The process is designed to allow the community to build a rough consensus around the ideas presented. P. Resnick defines the rough consensus as follows:

A rough consensus has been defined in many ways: a simple version is that a rough consensus means that strongly raised objections must go through debate until most people think they are wrong.

Giving the community the ability to present ideas, peer review ideas, and build consensus around them is critical to the development of distributed protocols like Bitcoin without a leader. Since the establishment of the BIP process, there have been 191 BIP Github code warehouse contributors.

There are three different types of BIPs:

• Standard Tracking BIP proposes changes to Bitcoin, including changes to network protocols, block or transaction validity rules, or any changes affecting application interoperability using Bitcoin.
• Information BIP describes design issues in the agreement or provides information to the community. They do not recommend implementing new features for the protocol.
• Process BIP: Propose a process around developing Bitcoin, or suggest changes to the process. They do not directly affect Bitcoin's code base, but they may include new programs, changes in development decisions, or changes to tools used in Bitcoin development.

Each BIP must go through several different phases to implement. This is an image of the workflow described in BIP 001:

To be implemented, the BIP must go from the draft stage to the proposal stage to the final stage.

• Draft: The BIP is submitted as a draft to the Bitcoin development mailing list and the BIP Github code repository.
• Proposed: BIP includes a work execution plan with a deployment BIP plan.
• Final: BIP meets real-world adoption standards. And this must be verified objectively.

In the process, BIP can be rejected, withdrawn or replaced by the community:

• Deferred: The BIP author can change his status to an extension without any progress.
• Withdrawal: The author of the BIP may also choose to withdraw the BIP completely.
• Rejected: If no progress has been made within three years, anyone can request that the BIP be moved to a rejected status.
• Replace: If the previous final BIP becomes irrelevant, mark it as replaced. For example, this may happen when a BIP is implemented in a soft fork and is overturned by a hard fork after three months.

Below, we will detail the two main phases of this process.

draft

The goal of the draft phase is to format new ideas about Bitcoin into standardized BIPs and begin to solicit feedback from the community as soon as possible.

1. The author of the BIP is responsible for reviewing the community's ideas to assess the feasibility of the idea and build a community consensus around it. They should share their thoughts with the Bitcoin Developer Mailing List and the Bitcoin Talk Technology Forum. This helps to determine if the idea is original, feasible, and guarantees a separate BIP.
2. The author created a draft BIP and submitted it to the Bitcoin development mailing list for discussion. This allows authors to present the idea in a standard format of BIP and handle any other issues from the community.
3. After the discussion, the author submits the proposal as a pull request to the BIP github code repository. The editor of the BIP code repository assigns a number to the proposal, tags it by type, and adds it to the code repository. BIP editors can only reject BIP if they do not meet certain criteria—for example, if the proposed update is unclear or technically unreasonable.
4. In order to facilitate the entry of the draft into the proposal, when the author has dealt with any objections in the community, the BIP will consider that the draft has been completed and contains the proposed work execution plan.

The draft phase is designed to allow the submitter to solicit feedback from the community and modify the BIP to address any objections raised at this stage. Once the draft phase is completed and submitted to the BIP, it will be moved to the proposed phase.

proposal

When the status of the BIP changes to a proposal, it is now ready to move from the discussion state to the deployment in the actual Bitcoin protocol. To this end, each BIP needs to include specific standards, outlining how to objectively establish a real-world adoption.

Usually, this means that the BIP needs to be executed into the code via soft forks or hard forks.

Soft forks introduce backward-compatible protocol changes, which means that nodes running the latest version of the software are still compatible with nodes running older versions.

Unlike soft forks, hard forks introduce protocol changes that are not backward compatible. This means that if a large number of nodes do not upgrade the client containing the new software, the chain will be split into two, just like Bitcoin Cash. Therefore, hard forks are a higher risk than BIP implementations.

BIP 002 provides some guidelines for determining how to finalize a BIP through soft forks or hard forks:

• A soft fork BIP needs to be activated by the "obviously the majority of miners." The recommended guide for establishing this "majority" is that 95% of nodes approve it by upgrading new software that includes BIP. The BIP activated by the soft fork must contain an active time that the BIP will be on the network.
• On the other hand, hard-forked BIP needs to be adopted by the entire community. The nodes on the network need to be upgraded to the client software that contains the BIP. BIP 002 states that hard fork BIP "needs to be adopted by the entire bitcoin economy," including Bitcoin holders, and those who provide services in Bitcoin. It acknowledges that this may be difficult to achieve.

In view of the difficulty in meeting the requirements of hard-forked BIP, virtually no BIP is implemented by hard forks.

The chart shows the activation of BIP 91, which received over 93% of node signal support. (Source: Bitcoin Magazine.)

Only when the BIP successfully initiates execution through hard forks or soft forks, and is implemented in the Bitcoin protocol, is considered to have reached the "final" stage.

Consensus on a distributed network

Bitcoin runs on a distributed network supported by nodes, users, developers and miners. It operates without the intervention of a centralized organization that can control the direction of the protocol. While the transactions on Bitcoin are permanent and non-tamperable, the underlying technologies that support the agreement are continuing to improve. Although the agreement confirms the transaction through Workplace Proof (PoW) mining and has reached a consensus on the transaction, it must also reach different types of social consensus on how to improve and update the agreement over time. The BIP process is the key to how developers can collaborate in a distributed and open source manner and contribute to Bitcoin.

This article is compiled from Medium in the financial network chain and does not represent the financial position of the financial network.

Author: SFO; compile: Xi breeze;

Source: Financial Network · Chain Finance

We will continue to update Blocking; if you have any questions or suggestions, please contact us!