中文

This article is a companion article to a more technical document. Check out also the accompanying decentralized cooperation proposal and writeup.

Hi all, for those of you that don't know me yet, I've been quite obsessive about an evidence-based model for Bitcoin's development. In this article I'll try to explain the details of why I think it's important, along with an example of how to follow it.

Rationale

I've been pondering this since the blocksize debate. Famously one part of the debate seized the main communication channels, and settled the debate not on merit, but on censorship of opposing views. How can we prevent that in the future? Let's make the merit of our ideas the central point of our discussions.

I've been thinking about this for the longest time, and described this informally in several occasions, but didn't get myself to do a more formal writeup yet. I'm not going to act that recent events didn't contribute to this decision, but it doesn't matter in the end: I think this process is valid regardless.

A crucial component to avoid a new capture is to have a decentralized development model, so that no one party is in control of the protocol. But how can collaboration in a distributed development environment work?

Open-source principles are important, but not sufficient. We're doing something new here, something that has never been tried before. It's on us to invent this. My proposal tries to go in this direction.

Scope

In a distributed environment disagreements are to be expected. We all want peer to peer electronic cash for the world, but can disagree slightly (or severely) on what it is exactly and how to get there.

Not all disagreement can be solved by an evidence-based process, but it can help greatly with technical matters. Evaluating technical propositions on their merits removes a whole lot of sources of disagreement and animosity before they even form. If you provide reproducible evidence that your solution is better than mine, I can't but concede. But this is explicitly not a consensus building process, it can only support one. And, I hope, support it well.

This process is aimed at consensus changes mainly. It's the most critical part of the protocol, and it requires the highest level of review. Other non-consensus protocol changes could be subjected to this process.

Implementation specific changes (ex. performance changes) should belong to individual implementation/team channels, but anyone can subject any change to these rules if they want, I'm not the boss of you and can't forbid it. In that case, do explicitly define who your peers are (to avoid outside troublemaker interference).

Process

The process is intentionally general. Only few essentials are required.

Going forward, we choose to be bound by this process for consensus changes. The process is intentionally loose, meant to be followed in the spirit. More specifically this is not meant to be a formal step-by-step process, but rather a rule of thumb for minimal requirements of judging the merit of contributions.

0. Not pictured: What to do before engaging

It could help to chime in with people about a change proposal to gauge interest, and possibly look for allies/helpers/hires. This makes loads of sense especially if you're an individual.

Premise

This process is explicitly available to anyone in the ecosystem, not just people that are already developers. Non-technical people can ask or hire someone technical to help them (step 0.). There is nothing special you need to do before undertaking this process. Permissionless development is cool.

If you want a change to happen, you'll need to spearhead it. This means that you'll work your ass off to convince a squabbly bunch that your change has merit. The upside is that you can go at your own pace, and if you follow this process, they will be willing to listen. Congratulations, you are now the leader of your initiative!

The platform for this to happen is intentionally left out. Platforms come and go. It just needs to be public and permanent. If you're unsure a public git repository will do. It's also a good idea to state where people can reach out to you.
This doesn't mean that you need to refrain from private communication for the time of your initiative, or that all your development needs to be public, just the parts pertaining to this process.

1. Objective

Define what the change aims to achieve or what problem it needs to solve. This should be plain English, but sufficiently precise to be actionable. This is also referred to as a "problem statement". It is important to circumscribe the scope of your change to one problem at a time (unless it makes sense to do otherwise). Once a problem has been stated, it should define a clear goal for what's an acceptable solution (ie. not over-engineer stuff). It's also a good idea to state what is not the scope of the objective, to set boundaries.

It is important for this to be clear, so that everyone can get on the same page from the get-go. An objective can be stated even if there is no known solution (yet), as a Request for Comments of sorts (but you should check step 0. above, it will help with the success of your initiative).

2. Solution

Now that you've identified an objective it's on you to provide a solution that provides a clear improvement for the objective. Each problem can be solved in a number of ways, and be prepared to consider other people's alternative solutions.

Make an attempt to explore tradeoffs and downsides: all changes have them. Being honest about it will make your proposal more convincing, not less.

Actually, be prepared that the accepted solution is not the one you proposed. You don't loose the leadership of your initiative for this alone; on the contrary, you demonstrate and consolidate leadership (in an evidence-based sense) by welcoming other people's ideas based on merit.

3. Specification

Goes without saying that a consensus-level change needs a formal language-agnostic specification. It should be sufficiently precise, helpful and actionable for everybody to unambiguously implement the change based on the spec. This point is the only one with a single paragraph to support the blunt importance of it.

4. Implementation

Provide a reference implementation for testing. This doesn't mean that you need to write code for free for each and every team, just one reference implementation to test things out and let other people test their implementations against it.

I know that this is technical, and can be the barrier for entry for many people. BUT! If you can't do this yourself, you can hire someone else to do it for you. This is also a great way to attract talent to Bitcoin Cash, and spread the knowledge of its technicals.
If there is sufficient traction people will even help you do this for free. Developers just can't help themselves.

5. Burden of proof

Provide a clear case in favor of the change and reproducible evidence (possibly a test suite). This is the evidence part of the evidence-based process, goes without saying that it's crucial for convincing others of the merit of your initiative. It's best that the evidence be provided as language-agnostic data for test cases, where applicable. The implementation needs to validate against these tests and data.

You'll get criticism. Understandably people will want to deploy only the very best consensus change, and your first iteration will probably not be it. Also, you might get competing solutions; for those, the burden of proof is on them. But for merit to be judged, the proofs should be somehow comparable. You should work with the other solutions (and they with you) within reason to provide such comparisons. Because that's what leaders do.

The competing solutions part is important. They will have their own leaders. There is nothing you can do about it - the process is permissionless for them as much as it is for you. We're here to find the best solutions. Let the evidence speak.

6. Feedback

Gather feedback to improve all of the above. Actively reach out, not only to social media, but to all individual implementations. It would be strange if they were not available for comment (developers can't help themselves). What you do with the feedback is on you. You'll get to improve and enrich the spec, the implementation and the tests based on it. Or not, and that's fine too.

Obviously you should seek feedback early and continuously. But if you haven't already, now it's a good time to do so. Be sure to reach out to all players in the ecosystem, and get an assessment for cost/benefits for them. You're most certainly missing some pieces of the whole picture, since you're not all of the following: user, miner, protocol dev, script dev, wallet dev, service sev, exchange and merchant. Reaching out to all parties will gain you insights and make your change much less controversial. It's generally as easy as sending an email or writing a text.

7. Evaluate

Allow reasonable time for people to evaluate and propose alternative solutions. If the idea is sufficiently novel, it will take time to convince people, and to independently validate the evidence.

We all want our new shiny idea to make it into the protocol, so we can grow impatient. But it will ultimately be so if other people value its merit, and this will take time. Also, if anyone else wants to propose a competing solution/implementations, it will take time to do so. But do encourage them to state their intention right away.

Also, there are possibly other things being worked on that could be more urgent. The ecosystem can handle just so many consensus changes in year, so be ready to assess priorities with other players and possibly postpone your change.

How long is "reasonable"? Reasonable is reasonable. You'll know it when sufficient consensus builds. Don't force things, but also don't stay passive.

Epilogue

While the steps are general and loose, they all need to be satisfied for an evidence-based process to be in place. The steps need not be completed in order, and there will almost certainly be iterations, especially if competing solutions emerge.

Again, if it's not your solution the one that ends up accepted, you will still be remembered as the leader of your initiative. It will have happened on merit, and you should be happy that the best solution is found to the objective you've identified.

Passing leadership on

It might be the case that the leader of the initiative cannot bring it to completion for whatever reason. Sometimes IRL strikes hard! Sometimes a bus strikes, we can't foresee everything.

Should a leader need to pass his burden on to someone else, they can do so publicly; they will discuss the details of the handover as they prefer. Should a leader disappear without notice someone else can pick up their burden, but only after doing an honest attempt at reaching out. A champion could nominate their squire from the very beginning in case something happens. It is wise to do so.

Commentary

This process allows for a loose framework against a new capture. It provides a level playing field for everybody, as it should be. Everyone needs to provide the same level of evidence to deploy a consensus change, no one gets a free pass. No matter if they're me, Satoshi, a newcomer or a seasoned developer. We hold everybody to the same (high) standard.

We can't 100% avoid capture, especially against actors that can always print more more money and make credible threats of violence. But we sure as hell can make their life difficult.

Having a rough process for changes lowers the barrier to entry for new people to contribute. They don't need to "build a reputation", but make a sufficient point and provide sufficient evidence for their contribution to be judged on its merit.

You don't even need to be liked to contribute. Actually people can hate your guts, and still accept your contributions based on their merit. That's one level of animosity down! (Such a situation can't last though, and if people hate your guts, you need to do some introspection)

This framework is explicitly not a "doacracy". You can't expect that your change be merged just because you've completed all the steps. Big projects have been taken over by the reasoning that the people who do get to make the decisions. This doesn't mean we don't value people who do, on the contrary we give credit where it is due, they just don't get a free pass.

It might happen that your contribution is simply ignored. It might be that there is no interest in it. For example if you advocate for a blocksize limit reduction, it won't be merged in even if you provide an implementation. Tough luck!

Other times it might be that your proposal has not been presented well. If you think it has merit, try to reach out. It might be that it's too revolutionary for people to realize it right of the bat.

There are tradeoffs obviously. This will be understandably slower than a centrally developed protocol. I think this is a tradeoff we are all willing to accept. I don't want a new capture, and I don't want a protocol with a bus factor of 1.

As the saying goes, "If you want to go fast, go alone. If you want to go far, go together". I want to go far.

This process provides a framework for solving technical disagreements, but obviously not all disagreements are technical. As people, we can try to work together as long as it's reasonable to do so. If there are disagreements that can not be overcome, then forking is always an option.

It could also be the case that malicious actors take over several dev teams and block any incoming contribution. We do need to plan for that, as that's what has already happened with the blocksize debate. In that case we can always fork them off/fork away from them. Forking is always an option, even if the last possible option.

I hope that, going forward, this process can help to reduce the need for forking to the bare minimum.