BITCOIN IMPROVEMENT PROPOSAL

By 2011, Bitcoin’s development landscape had changed significantly. Satoshi was gone, and while he’d left instructions for how its codebase should be maintained, led by Gavin Andresen, there was no formal framework for community contributions. Gavin had a number of accomplished developers supporting him including Pieter Wuille, Wladimir van der Laan, Greg Maxwell, and Jeff Garzik. Nevertheless, there lacked a system for proposing improvements to the Bitcoin protocol.

Development discussions were ad hoc, occurring across forums and mailing lists, and control of the codebase was concentrated in a handful of individuals. This lack of structure showed its limitations as Bitcoin grew. By mid-2011, numerous ideas for improving Bitcoin were being floated in the community, but there was confusion about how to advance them.

Some ideas languished or sparked controversy, while others were simply implemented outside of Bitcoin’s core development as separate projects. For example, proposals like integrating Bitcoin with domain names didn’t make it into Bitcoin, instead inspiring the creation of Namecoin as a separate blockchain. 

Now that Bitcoin was both precious and popular, it was clear that changes to its codebase should be kept to a minimum to avoid breaking anything or diluting the properties that had made the network so secure. But at the same time, there needed to be a way for the most promising proposals to undergo peer review and make it into the Bitcoin protocol provided there was strong community consensus.

But how best to implement such a framework in a manner that was both democratic and decentralised? The idea of letting anyone contribute to Bitcoin’s development was undoubtedly egalitarian, but there was a risk of the protocol being commandeered by individuals who didn’t have its best interests at heart or who were intent on pursuing personal projects at the expense of regular users.

The solution came courtesy of a rising star of Bitcoin development. A maverick programmer whose brilliance was matched only by his flamboyance.

A Wild Amir Appears

Amir Taaki was a cypherpunk through and through, even if he wouldn’t have used that term to describe himself. The British-Iranian programmer and professional poker player had a reputation for being idealistic, independent, and occasionally contrarian. Amir was a divisive character, who felt with some justification that he was excluded from the informal governance system in place at the time. He didn’t have Gavin Andresen’s ear, and thus had little power to influence Bitcoin development.

To solve this, not just for his own benefit, but for the long tail of Bitcoin developers who had now entered the fold, Amir devised the Bitcoin Improvement Proposal, better known as BIP. It formed the rulebook for Bitcoin code submissions. Cribbed from the Python playbook – the programming code in which Amir was steeped – this governance mechanism should enable an open-source project to remain decentralised while supporting a working system for proposals, discussion, and decision-making. Amir’s idea would allow Bitcoin to maintain its anarchic, leaderless nature while introducing just enough process to avoid anarchy in practice.

The first BIP, numbered 0001, was highly meta in that it described how all future BIPs should be structured. It explained that each BIP should contain a concise technical specification and rationale behind the proposal. BIP 0001 also set the expectation that BIPs would be the “primary mechanism” for proposing new features, collecting community input, and documenting design decisions in Bitcoin.

Despite Amir’s outsider status, the BIP framework resonated with the Bitcoin developer community, who recognised that it filled a gap for codebase submissions and approvals. Even developers who weren’t drawn to Amir Taaki found it hard to dispute the rationale behind the BIP mechanism. When Amir Taaki subsequently authored BIP 0014, standardising the Bitcoin client “User Agent” string format, Gavin Andresen himself provided feedback and suggested ways to improve the proposal.

A few months after its creation, the BIP system was put to the test when two competing proposals were submitted concerning how to implement Pay-to-Script-Hash (P2SH), an upgrade to Bitcoin’s transaction scripting: BIP 16 by Gavin Andresen and an alternative BIP 17 by Luke Dashjr. Ultimately, the community coalesced around BIP 16 and BIP 17 was withdrawngithub.com. The episode demonstrated the BIP framework in action and set a precedent for how contentious protocol changes could be resolved.

According to BTCPay Server founder Nicolas Dorier, who has authored several BIPs, the framework “works especially well when you have a group of people who are interested in what you’re doing and capable of refining your idea even before it is fully developed. The main advantage of the BIP repository is that it makes your protocol more easily discoverable and more trustworthy, since it is reviewed and implemented by several people in the community.”

Another BIP veteran, CryptAxe, is ambivalent about BIPs. On the one hand, he points out, “The BIP process provides a structured way to organize and evaluate ideas that could improve Bitcoin. It acts as a central reference point where the community can review technical details and work toward consensus on proposed changes,” before adding: “However, this centralization also introduces weaknesses. The process ultimately depends on a small group of individuals with commit access to Bitcoin Core’s GitHub. Only they can assign BIP numbers and list proposals in the official repository. In practice, this makes the process slow, politicized, and dependent on gatekeepers rather than fully open to community consensus.”

Even its architect, Amir Taaki, later had second thoughts about the BIP framework, which he believed became too conservative over time. Regardless, by late 2011, the BIP model had taken root and Bitcoin development never looked back. Not only has it changed the shape of Bitcoin development to this day, but the concept has since been adopted industry-wide, with Improvement Proposals the preferred mechanism for virtually all blockchains.