Bitcoin Governance

A short history of Bitcoin governance

At the beginning of Bitcoin, there was no standard way of collaborating or maintaining, and developing the protocol. Satoshi Nakamoto, the inventor of Bitcoin, wrote most of the original code himself. He was also in charge of updates.

While he was the person writing the code, he was not alone. He solicited feedback from the cryptography mailing list and later from the Bitcointalk forum https://bitcointalk.org/. But the final decision on whether to implement a feature or fix a bug was his. It is easy to see that this was a highly centralized process.

To survive and become less dependent on a single point of failure, the governance process needed an overhaul.

After Nakamoto resigned in 2011, he handed the responsibility over to Gavin Andresen. Andresen enlisted four other developers Pieter Wuille, Gregory Maxwell, Wladimir van der Laan, and Jeff Garzik. Those five developers became the “Bitcoin core developers”. They were mostly in charge of maintaining and developing the Bitcoin core client.

Besides the core developers, more and more people contributed to the codebase. This made it necessary to formalize the contribution process. The decisions are made in a process called rough consensus.

Rough consensus

Rough consensus is a way of decision-making where the “sense of the group” regarding a particular matter is taken into account. Not all group members need to agree. Instead, the dominant view/opinion shall prevail. However, it is not clear what dominant really means.

In 2011 Amir Taaki proposed the Bitcoin improvement proposal (BIP) scheme in BIP 1 https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki. It is very similar to the Python Enhancement Proposal.

With the BIP scheme, anyone is allowed to propose changes to the Bitcoin protocol. It also helps contributors to discuss and improve and sometimes to drop ideas before implementing code.

Thoroughly discussing and scrutinizing proposals is very important to maintain the code’s security and functionality and the network.

Bitcoin Improvement Proposals (BIP)

A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment.

Cited from https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP

The primary use cases for BIPs are proposing new features, collecting community input, and documenting design decisions. BIPs are maintained as text files in a versioned repository (like Git), changes can be tracked.

There are three kinds of BIPs:

Standard Track BIP: Describe changes that affect many Bitcoin implementations. Typically, this includes changes to the protocol, validity rules, or interoperability of applications. The community needs to find consensus. Developers must follow them.

Informational BIP: Describe design issues or offers general information to the Bitcoin community. It doesn’t propose new feature. Instead, its purpose is purely informational, and developers are free to follow them.

Process BIP: They are similar to Standard Track BIPs but apply to topics other than the Bitcoin protocol itself. Developers must follow them. Typical topics are

• changes to tool or development environment,
• changes in the decision-making process,
• and changes in guidelines.

BIP Work Flow

Idea: Everything starts with an idea. Each BIP needs an author (a.k.a. champion) responsible for administering the discussion and trying to create a community consensus around the idea. Before actually writing a BIP, the idea should be vetted through public discussions, thorough research, checking if the idea is new, and making oneself familiar with the contribution process. This helps the author and the wider community to save time.

Collecting community feedback:

Create a draft BIP: After getting the signal from the community that the idea is “BIP-able”, the author creates a draft BIP and presents it to the bitcoin-dev mailing list. BIP editors are entitled to reject BIP drafts if they don’t meet the guidelines.

Submit the BIP draft Proposal: After finishing the draft, the authors submit it as a proposal to the BIP editor.

Getting a BIP number: Once the BIP editor approves the draft, it assigns the BIP a number. At the same time, it gets labeled as Standard Track, Informational or Process. The BIP receives the status “Draft” and the BIP editor adds it to the git repository.

Accept, Defer or Reject BIP: Once a BIP has been accepted, authors have to complete its reference implementation. If the community accepts the completed reference implementation and the BIP, the status is updated to “Final”. If there is no progress, the BIP can get the status “Deferred”. In case the reference implementation is rejected by the community, the status is updated to “Rejected”. If a BIP is never meant to be completed, it can get the status “Active”. This is mostly done with informational BIPs and Process BIPs.

Structure of a BIP

BIPs need to follow a structure. Each BIP should contain the following information:

• Preamble: metadata about the BIP, including BIP number, descriptive but short title, information about the author.

• Abstract: Description of the technical issue being addressed.
• Copyright information: Each BIP must be under the public domain or the Open Public Licence.
• Specification: Syntax and Semantics of any new feature. It should be detailed enough to allow competing, interoperable implementations for different Bitcoin platforms.
• Motivation: Explanation of why the BIP should improve the existing protocol.
• Rationale: Explanation of why the BIP should improve the existing protocol. It should include alternative designs that were considered. Related work also belongs to this point.
• Backward Compatibility: Explanation of why the BIP should improve the existing protocol.
• Reference Implementation
• Final implementation: The final implementation includes test code and appropriate documentation.

BIP Editors

BIP editors perform the following tasks when receiving a draft:

• Read the BIP-draft
• Evaluate its technical soundness and completeness
• Evaluate style, title, markup, etc.

Once the BIP is ready for the repository, the BIP editor does:

• Assign a BIP number
• Merge the pull request when the author is ready
• List the BIP in the mediawiki

Besides, BIP editors fulfill administrative and editorial tasks. They monitor changes and correct spelling, grammar, structure, or markup mistakes.