Why Bitcoin development moves slowly

The review process exists to find the errors that would otherwise become permanent. A consensus change is read by people who did not write it, who look for edge cases the author did not consider, and who are expected to say so publicly. The discussion is adversarial by design: the useful contribution is not agreement but a concrete case in which the proposal behaves badly.

Testing is part of the same effort. A change is expected to come with tests that exercise the new rules, including the cases at the boundaries where the rules are least intuitive. Bitcoin Core maintains a functional test framework that runs a network of nodes against each other, and a consensus change is expected to be covered by it. The tests are not a formality; they are the mechanism by which a rule that behaves differently on different implementations is caught before it is deployed.

The process is also slow because it is open. Anyone can read a proposal, comment on it, or object to it, and there is no mechanism for closing a discussion that has not reached agreement. That makes the process inefficient in the ordinary sense, and it is the reason a change can take years to move from an idea to a deployed rule. It is also the reason a change cannot be pushed through by a group that happens to be in a hurry.

Even a change that passes review is not deployed until the network adopts it. Node operators have to upgrade, miners have to signal and then produce blocks under the new rules, and the change takes effect only when enough of the network enforces it. That is a second filter, independent of the technical review, and it is the one that decides whether a proposal becomes a rule.

The mechanism for measuring that adoption is described on the version bits and soft-fork signalling page. Its significance here is that it makes adoption a deliberate act rather than a consequence of a release. A node operator who does not want a change can decline to enforce it, and the network has to reach a threshold without them.

The distinction between a proposal and a rule is set out on the how BIPs work page, and the difference between a change that tightens the rules and one that loosens them is the subject of the soft forks and hard forks page. Together they explain why the path from an idea to a deployed rule is as long as it is.

The obvious cost is that Bitcoin is slow to improve. Features that other networks adopt in months take years here, and some never arrive. Proposals that would be uncontroversial elsewhere become multi-year arguments, and the arguments themselves consume attention that could go into building. Anyone who wants a network that iterates quickly will find this frustrating, and the frustration is legitimate.

What the caution buys is predictability. A holder of bitcoin can be confident that the rules governing their coins will not change without a process they can observe and participate in, and that no group — developers, miners, or large holders — can alter those rules unilaterally. That confidence is the thing the network is selling, and it is not separable from the slowness. A system that could change its rules quickly would be a system whose rules could be changed quickly by whoever held the most influence at the time.

The 2017 fork is the clearest evidence that the trade-off is real rather than theoretical. A substantial group wanted a different rule, could not persuade the rest of the network, and implemented it separately. The original chain continued unchanged. That outcome is the conservatism working as intended, and it is also the reason the conservatism persists: the episode showed both that a determined minority cannot force a change, and that leaving is possible for anyone who wants one.