Over the last few years, the buzz generated by Bitcoin’s scaling debate has drawn unprecedented attention towards the development process that drives the evolution of the cryptocurrency’s protocol. Though open-source software projects have a long history of being subject to pressure from competing interests, of having to deal with divergent visions promoted by different development teams, in Bitcoin’s case the scope and variety of interests with a stake in the system, and therefore the motivation for having a voice in the development process, creates a truly unique situation.
In order to deal with these challenges, large open-source projects have carefully defined the ethos, mission and principles underlying the work of their contributors. A notorious example of this is the Internet Engineering Task Force (IETF)’s “The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force”. As one of the largest standards organization with constituents spanning the entire globe, the IETF has decades of experience organizing the development efforts of its volunteers. More importantly, its “rough consensus” approach has strong parallels with the decision-making process for Bitcoin development.
In the past, a failure to understand the practices influencing the direction of the Bitcoin protocol has led to unnecessary conflicts; now, it again threatens to stall progress despite the involved actors’ best intentions. However, we should remember that open-source development remains an all-inclusive effort. The challenges we are facing are simply an opportunity for everyone involved to funnel the positive energy of the relevant actors towards more productive outcomes.
This article is an attempt to create mutual understanding using the IETF’s guide as a model of reference. It outlines not just how to contribute to Bitcoin, but also how to reach consensus in doing so. The notions outlined here are only the product of an outsider’s own perspective and should not be confused as anything official or formally standardized.
The Bitcoin Development Landscape
The Bitcoin Core project is the most active and prolific leader for Bitcoin development today. It consists of a loose group of hundreds of volunteers from all across the world, who together contribute to the implementation located under the Github.com/Bitcoin repository.
The project has no governing body nor membership model: participants are welcome under an open contributor model and gain influence through a meritocratic process based on the quality of past contributions, as evaluated by peer-review. To facilitate the development activity, maintainers are appointed by a lead maintainer, who is responsible for moving the project forward by overseeing the release cycle. This hierarchy and the associated titles are a practical matter and do not imply any form of privilege or authority. In the event that any of these entities abuse their control over the repository, the remaining members are free to fork the project and continue their work.
While the mission of the project has never been formally defined, certain goals can be inferred from past communications. Bitcoin Core works to:
- Look after the health of the network,
- Strive for the highest standards of performance
- Keep Bitcoin secure on behalf of everyone
- Maintain and release software to the Bitcoin community for users’ consideration
- Favour backwards compatible upgrades that preserve user choice
- Safeguard the network’s core features of decentralization, security and permissionless innovation
While most contributors participate on a volunteer basis, several entities now provide financial backing through grants or direct employment in order to ensure the sustainability of the development efforts. These include, but are not limited to, Blockstream, ChainCode Labs, Ciphrex, MIT DCI, and Purse.io. In most if not all cases, specific contractual clauses and arrangements are made to preserve developer independence and to protect them from conflict of interests potentially detrimental to Bitcoin or its users.
Years of collaborative work, a unique collection of the most experienced and knowledgeable developers in the field and a dependable track record have made Bitcoin Core the most trusted implementation in the space. However, the project’s status as technological steward of the protocol is bestowed only by the voluntary actions of Bitcoin users worldwide. Bitcoin Core does not control Bitcoin and it cannot unilaterally force changes to its consensus rules. Many users and companies run their own patches of the Bitcoin Core software. Other developers have created their own implementations, some based on the Bitcoin Core codebase and others written from scratch using a different language, with notable releases including btcd, Libbitcoin, Bcoin, NBitcoin.
However, the Bitcoin development landscape is larger than just the Bitcoin Core project and these individual developers. Bitcoin, its ecosystem and its related technologies have been researched by hundreds of academics, who have published more than 1150 papers to date. The Scaling Bitcoin Workshops instituted in 2015 have provided a unique opportunity for developers and researchers to collaborate on matters of protocol development and to discuss the technology’s evolution in an academic context. Other institutions such as Stanford, Princeton and ETH Zurich also have active resources dedicated to research in the field.
How to contribute?
There are several ways to contribute to Bitcoin development; anyone is welcome to do so provided they are conscious of the process in place and respectful of the standard practices developed over the years.
One of the most challenging aspect facing new contributors is the breadth of the codebase and the complexities of the technologies surrounding it. Specifically, newcomers often find out that new ideas are in fact rarely novel and are likely to have been proposed or considered in the past.
In order to inspire productive contributions and avoid misdirected efforts, developers are encouraged to consult the various online resources listed below prior to making formal proposals. Free and open-source software (FOSS) development favours open communication and various platforms have been established over time for contributors to receive feedback on their initiatives.
Read & Engage:
The focal point of Bitcoin development is the bitcoin-dev mailing list, an implementation-neutral list currently hosted by the Linux Foundation. Motivated contributors are advised to consult the archives of the list in order to get a proper feel for the development process but also to uncover content potentially relevant to their work.
Discussion on the list is lightly moderated in order to preserve a focus on technical discussion and proposals. Meta discussions are generally redirected to the bitcoin-discuss mailing list.
Other venues such as the #bitcoin-dev, #bitcoin-core-dev and #bitcoin-wizards channels on IRC freenode are also recommended for receiving initial comments on ideas or for getting answers to questions relevant to Bitcoin development. Historical logs for the aforementioned channel also contain a wealth of information that may be valuable to new contributors. They can be found at:
- #bitcoin-dev
- #bitcoin-core-dev
- #bitcoin-wizards (older content here)
Additionally, many individuals maintain their own sites, where ideas that have been discussed in various circles throughout the years are collected and archived. One of the most comprehensive, though admittedly hard to parse, is developer Bryan Bishop’s wiki available here. Other community resources include the Bitcoin Wiki and Bitcointalk’s Development & Technical Discussion section.
Finally, different in-person venues have emerged over the years to support technical collaboration as well as the promotion of new ideas under a different social context. Examples of those include, but are not limited to, the SF Bitcoin Devs meet-up, NYC Bitcoin Devs, Bitcoin Milano meet-up, the Paralelni Polis Bitcoin meet-up, the Scaling Bitcoin conferences and the S3ND roundtable meetings.
Propose & Implement
Developers interested in contributing code and helping with the review process are advised to consult the guideline available here. The most effort is required for changes that affect Bitcoin’s consensus rules and for features that may require standardization given their impact on the ecosystem as a whole.
The Bitcoin Improvement Proposal (BIP) mechanism is Bitcoin’s own version of the IETF’s Request For Comment (RFC), which is used to document the introduction of new standards, methods or technologies relevant to the core systems underpinning the Internet. The concept was applied to Bitcoin by developer Amir Taaki and its initial specification largely adapted from Python’s PEP-0001. It has since been revised by developer Luke-Jr.
We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. — BIP2, BIP process, revised
The essence of the BIP process can be found in the “BIP Workflow” section of BIP2 which highlights its purpose as a collaborative tool.
The nature of Bitcoin’s distributed trust and its open-source principles require strict adherence to the scientific peer-review model. Transparency and open discourse are essential to the success of any proposal and ultimately the health of Bitcoin development. New contributors should approach the process with humility and not be fazed by early rejection, for no single individual can claim the collective wealth of knowledge and experience that the community has acquired over the years.
This rigorous vetting process requires engaging as many actors as possible in in order to build consensus around a proposal. It is especially critical if the proposed change involves changes to the consensus rules of the system. While this may seem tedious to some, failure to respect this convention is likely to stall the progress of development even more, by introducing mistrust and politics. A perfectly sound technical proposal might suffer from significant delay if the motivations of its author are questioned due to an attempt to skirt the established practices. To avoid this, contributors are encouraged to proactively engage the relevant constituents of the ecosystem and to foster dialogue, particularly amongst fellow developers. Details about the role of the various participants and the requirements for reaching consensus can be found in the Rationale section of BIP0002.
If you do decide to try to write a document that becomes an IETF standard, be warned that the overall process may be arduous, even if the individual steps are fairly straightforward. Lots of people get through the process unscathed, though, and there’s plenty of written guidance that helps authors emerge with their ego more or less intact. — The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force, 2012
Once a new idea has satisfied the above requirements, its sponsors are expected to produce a working implementation whose code is coherent with the specification. It should aim to preserve backward compatibility and to be as minimally disruptive as possible. To facilitate interoperability, BIP123 was introduced by developer Eric Lombrozo; it helps to categorize proposals according to the network layers they interact with.
Rough consensus & running code
In many ways, the IETF runs on the beliefs of its participants. One of the “founding beliefs” is embodied in an early quote about the IETF from David Clark: “We reject kings, presidents and voting. We believe in rough consensus and running code”. — The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force, 2012
Much has been written over the years about Bitcoin’s governance model (or the lack thereof). When Satoshi Nakomoto vanished from the development scene in 2010 he left no instructions or guidelines for his successors to consider when faced with consensus critical decisions.
For the better part of Bitcoin history this had not been an issue; technical changes to the protocol were rarely controversial, and users would trust the peer-review process in place. Proposals would be evaluated according to their technical merits and eventually merged into the codebase once they had been determined to satisfy “the minimum standards for inclusion”.
With time, the latent challenges of consensus building materialized, an expected consequence of the increased diversity of actors in the ecosystem and their diverging interests and expectations. In the opinion of many, the social complexity of the system brought its technical evolution to a halt. With no authority in place, how could the various stakeholders converge towards an acceptable outcome for debates that concerned fundamental rules of the protocol?
Impatience led various participants to advocate for formal governance models that would privilege high-profile actors and grant them control over the direction of the protocol. Unfortunately, these type of structures are antithetical to the user-driven consensus upholding the rules of the system. By lending disproportionate power to public figures, they create a target for coercion and undue influence by hostile forces.
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. — The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force, 2012
A more adequate decision-making process can be drawn from the “rough consensus” model adopted by the IETF. Several sections of the On Consensus and Humming in the IETF document provide insightful content that can help Bitcoin developers get appropriate perspective on what is expected of consensus-driven development.
Lack of disagreement is more important than agreement
A large part of advancing Bitcoin development consists of creating support for a proposal. Unfortunately, appearances of wide support is often confused with consensus. Measures of agreement might indicate that an idea has gained the favour of the community but cannot be said to have reached consensus if outstanding disagreements remain. If a valid technical objection is raised by even just a single contributor then it must be addressed by the group or it may prevent the implementation of a proposal if sufficiently strong.
Developers should therefore consider proposals according to a principle of “least-disagreement”. While getting everyone to agree unanimously might be a futile endeavour, it’s possible to reach “rough consensus” by weighting specific disagreements and ascertaining whether they are irreconcilable issues or simply a matter of engineering preference.
Rough consensus is achieved when all issues are addressed, but not necessarily accommodated
While it is essential that potential issues with a proposal be considered, it’s also important to acknowledge the existence of engineering tradeoffs and deal with them in the most pragmatic way. Another way to approach this is to not let “perfect be the enemy of good”.
The group of developers is encouraged to weigh every objections without bias, to be open about the review process and to be clear about its ultimate decision. The development process can make great progress if an individual’s concern is thoroughly examined in a way that allows the group to gain greater understanding about the potential alternatives and to reason coherently how or why they may be superior.
Simply having a large majority of people agreeing to dismiss an objection is not enough to claim there is rough consensus; the group must have honestly considered the objection and evaluated that other issues weighed sufficiently against it. Failure to do that reasoning and evaluating means that there is no true consensus. — On Consensus and Humming in the IETF, 2014
Issues may be of varied nature, some more critical than others, but as long as the group recognizes that all potential tradeoffs have been addressed satisfactorily then it’s more likely to reach the best technical outcome. The group should be wary of any attempt to accelerate development using “horse-trading” strategies where concessions are made despite strong and rational objections. Compromises where engineering takes the backseat to politics have no place in open-source development, especially in the case of Bitcoin where special interests should have no precedent over the safety of the system’s users.
Consensus is the path, not the destination
Though the IETF can never be perfectly principled with regard to rough consensus, failing to be vigilant about sticking to the principles makes it increasingly hard to stick to them in the future, and ends us up with worse technical output. — On Consensus and Humming in the IETF, 2014
One of the most frequent issues when discussing matters of consensus is about evaluating whether it has been achieved or not. Typical attempts often rely on headcount and other social signals that are easily misinterpreted or subject to manipulation. These efforts miss the big picture by focusing too much on the results rather than the process.
Consensus-building is better regarded as a systematic approach to open collaboration: an iterative process that works toward achieving the optimal technical outcome based on inputs from every participant in the ecosystem. As long as the latter can agree on a set of best practices and work together to adhere to basic open-source principles the likelihood of reaching a satisfactory result is improved. The transparency of the exercise is essential so that users who are not directly involved can judge the legitimacy of the changes they might want to adopt.
This last point is worth emphasizing because the consensus of the system is ultimately decided by the code that users run and by the rules that they enforce through their own validating nodes. While certain changes can be carried out without a long and gruelling process of ecosystem-wide vetting, those that involve the consensus layer require an extraordinary amount of coordination between every actor involved. Rushed attempts are unlikely to lead anywhere if a certain faction feel like their voice was not given due consideration because of the time constraint forced upon them by others.
One more thing that is important for newcomers: the IETF in no way “runs the Internet”, despite what some people mistakenly might say. The IETF makes voluntary standards that are often adopted by Internet users, but it does not control, or even patrol, the Internet. If your interest in the IETF is because you want to be part of the overseers, you may be badly disappointed by the IETF. — The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force, 2012
Bitcoin’s socio-economic impact creates unique challenges when it comes to reconciling the interests of everyone involved and preserving the decentralized nature of the protocol. Fortunately it is not without precedent and the history of Internet protocol standards provides valuable information about how we should approach these challenges. The IETF’s cultural norms highlighted in this article did not emerge out of nowhere but were acquired over a long period of trials and tribulations. Few users today might remember that the Internet had to deal with its own scaling problems and saw various constituents attempt to claim control over its destiny. The IETF’s insistence on open development played a crucial part in preserving the voluntary nature of the system & its technical integrity.
Today, our community finds itself in a similar predicament as the Internet’s own more than twenty years ago. The collective decisions we will make in the near future are likely to have a lasting impact on the evolution of Bitcoin going forward. While commercial interests are essential to the growth of the ecosystem, they should be cautious about interfering with the development process. Short term interests cannot stand in the way of the sound engineering necessary to protect the long term resilience of the protocol.
The Bitcoin network is ultimately supported by thousands of independent users all across the world voluntarily running their own instance of the software. In this context, any action that undermines the open-source development process will necessarily lead to mistrust amongst the userbase. While certain actors may be under the impression that a top-down initiative will expedite the progress of the technology, odds are that it is more likely to halt it. Worse, this appetite for accelerated development puts us at risk of causing irreparable damages to the protocol.
Understandably, it’s reasonable to assume that a lot of participants are looking after their own interest and might be worried about the impact that slow, incremental progress would have on their businesses. That is why it is vital for everyone involved to improve communications and collaborate in an open way so that we can deal with near term problems without sacrificing the long term prospects of a technology that will, hopefully, outlive us all.
After all, the future is Bitcoin.
