Consensus, Not Command & Control
There is no authority in Bitcoin - even the principles outlined in this article are by no means authoritative, they are simply observations made by myself and other ecosystem participants.
- Bitcoin is a system that automates the continual discovery of consensus amongst its participants. It is machine consensus that enforces human consensus.
- Consensus failures can destroy the whole system by causing loss of confidence in its reliability.
- Consensus code should be ringfenced and rarely touched.
- Protocol changes should not be forced upon users without their consent. That is, users should opt into changes rather than having to opt out.
- As such, software clients should not update automatically, as that would take power away from users and put it in the hands of developers.
- Due to the distributed nature of the network, it should not be assumed that every user is paying attention to protocol changes.
How do we make changes to the system? In order to change the consensus code we must somehow achieve human consensus to change the rules of the system. The Bitcoin Improvement Proposal process is described here. It's not perfect, but consensus-building is a messy process. How have changes been made historically?
- By Satoshi decree
- On-chain miner ‘voting’ (BIP 16)
- Flag day upgrade (BIP 30)
- IsSuperMajority (double threshold switchover) mechanism (BIP 34, BIP 65, BIP 66)
- Version Bits (BIP 9)
Who gets to accept or reject proposed changes? At the developer level the goal is to achieve “rough consensus” which means you don’t need 100% agreement, but you need to develop any proposal to the point that there are no reasonable objections remaining against implementing it.How do we measure support for changes to the system? Ultimately, the governance of the protocol does not occur via a well-defined, top-down fashion. Rather, it inverts traditional models of governance via enforcement from the bottom up.