A Theory of Bitcoin Governance
Co-authored with Buck Perley
Bitcoin has won the battle to be recognized globally as a potent Store of Value. As long as blocks keep getting mined every ten minutes and no security vulnerabilities make their way into the protocol, no more soft forks or upgrades are needed for it to provide incredible value to the world. Thus, the ideal bitcoin governance system should be conservative, focused on minimizing the chance of bad upgrades getting forked in, rather than maximizing the chance of good proposals sailing through.
Like in the US Constitution, we believe that bitcoin governance has three branches, and that each branch should have the ability to check and balance the other two, leading to a Mexican Standoff (see header image) as the most likely outcome in the event of disagreements between stakeholders. The most relevant addition to the common understanding is defining where Core Developers’ responsibility should stop, and where the responsibility of the Economic Nodes should begin, assuming we want bitcoin to remain a user-owned system.
This essay will explore the powers each branch is delegated, and the checks on each of those powers. Exploring the various factions within each branch is beyond the scope of the essay, as their impact will be seen in the final output that is their branch’s action. Embedded throughout are select quotes from the Federalist Papers — the bitcointalk forums & dev mailing list of the early American Republic.
The Branches of Bitcoin’s Governance
“It is in vain to say that enlightened statesmen will be able to adjust these clashing interests, and render them all subservient to the public good. Enlightened statesmen will not always be at the helm” — Federalist #10
Miners
Miners have the most desired power in all of bitcoin: they get to execute transactions, and claim block rewards and transaction fees. Because of this, they are the most dangerous branch to bitcoin governance. If miners were to gain supremacy over the other two branches they would be able to behave tyrannically by censoring transactions and printing themselves seigniorage. The failure mode in which miners gain supremacy is well known: increasing the load on verifiers centralizes control in the hands of the most powerful miners.
Thankfully, the bitcoin ecosystem has already demonstrated how both the Core Developers and the Economic Nodes can check potential miner tyranny. In 2015, the most powerful miners wanted to raise the block size limit. Core Developers checked this desire by simply refusing to merge the requested code changes, and forcing miners to fund and develop their own forks of the codebase that saw minimal adoption. Economic Nodes agreed with the Core Developers that the codebases incorporating the hard fork proposals were no longer Bitcoin by shorting fork coin futures and selling their fork coins for more Bitcoin. Now that the market has decisively chosen Bitcoin as the most valuable fork, Economic Nodes are starting to spin down their fork nodes, and will soon delist the coins.
More indirectly, Core Developers consistently check the power of the miners by decreasing verification time, ensuring no new soft forks increase verification time, and decreasing bandwidth of block transmission, ensuring full nodes can keep up with the chain even in the remotest locations. Economic Nodes indirectly check the power of the Miners by attempting to minimize the amount of on-chain transaction fees they pay via off-chain execution and on-chain batching.
Nodes
Importantly, merely the threat of a User Activated Soft Fork (UASF) was enough to force miners to comply, demonstrating that ultimately Economic Nodes are the supreme branch of bitcoin governance. They have the power to both propagate transactions to miners and to validate transactions executed by the miners. This makes bitcoin a user-owned system, which lines up with the ethos of bitcoin and the open source community more broadly.
However, user-owned systems can be susceptible to “democratic passions”, and as users cannot be expected to be experts in the cryptography itself, nor the economics of mining, they must be checked by the two other branches.
“the majority, having such coexistent passion or interest, must be rendered, by their number and local situation, unable to concert and carry into effect schemes of oppression.” — Federalist 10
Core Developers directly check Economic Nodes in the same manner they check Miners: by ensuring the barriers to entry to run a node are as low as possible, and refusing to merge code that raises that barrier to entry. They indirectly check the power of the Economic Nodes by running a lengthy, deliberate process around each proposed change that will help to mitigate any strong, transitory feelings (described by Jameson Lopp in 2018).
Miners directly check Economic Nodes in a similar fashion: by simply refusing to run the software with the requested code changes. They indirectly check the Economic Nodes by tying the security of the chain to their on-chain fee revenue (in the long run). If fees do not rise as block rewards decrease, Economic Nodes will request changes from the Core Developers to increase Miner fee revenue, or risk the fixed supply cap.
The Founders phrased the prudence in balancing against such democratic institutions as
“not less indicated by the propensity of all single and numerous assemblies to yield to the impulse of sudden and violent passions, and to be seduced by factious leaders into intemperate and pernicious resolutions.” — Federalist 62
Such a check is also enforced within the body of Economic Nodes themselves, as each Economic Node is seeking to protect its own sometimes diverging interests, whether it be run by a business, an exchange, a dissident, or a hobbyist.
Developers
Core developers have a more subtle, but maybe the most impactful power: they get to create new rules for Miners and Economic Nodes to follow. As mentioned in the introduction, because the system works so well for so many people right now, bitcoiners should be wary of any suggested new rules. A soft fork that harms bitcoin’s immutability and on-chain property rights would be disastrous and should be avoided at all costs.
“For it is a truth, which the experience of ages has attested, that the people are always most in danger when the means of injuring their rights are in the possession of those of whom they entertain the least suspicion.” — Federalist 25
As the branch that actually executes transactions, Miners can simply refuse to run the software with the Core Developers’ new rules. If no miners consider transactions with the new rules as valid, they will simply not be executed no matter how many Core Developers or Economic Nodes want them to be. More indirectly, miners check the Core Developers by jealously guarding their block rewards, rather than allowing them to cut in on the seigniorage privilege via a developer fund.
Economic Nodes check Core Developers by mandating that all consensus-critical upgrades are soft forks, rather than hard forks. This allows them to update at their leisure, when the new soft fork feature becomes economically desirable, with minimal security implications (described by Pieter Wuille in 2015). Their indirect check is to jealously guard their “right” to run a node for cheap or run one with support for their favored feature set.
How Does This Apply To Taproot?
The final disagreement when it comes to Taproot is over what the default lockinontimeout setting should be. When the block height for the Taproot upgrade is reached, nodes with lot=false will comply with whatever the Miners decide (which importantly is actually decided by the economic majority as demonstrated with Segwit2x), while the nodes with lot=true will UASF. There are technical and game theoretical pros and cons to which approach should be set as the default, but through this lens of Bitcoin Governance as a system of checks and balances the ideal approach seems clear.
Economic Nodes check the power of Core Developers by opting in to the new soft fork features at their leisure. If Core Developers release proposed soft fork software with lot=true, they leverage the power of defaults (and take advantage of user trust in their diligence) to make the decision to support the fork on behalf of users, and essentially subvert the governing responsibilities of the Economic Nodes. This is not a balanced system of checks and balances.
In order to complete the balanced system of checks and balances in Bitcoin governance, Economic Nodes must opt-in to a proposed soft fork by changing the default from lot=false to lot=true. Otherwise we may find ourselves in a world where Core Developers have the power to auto-update large swathes of the Economic Nodes to new software at high risk of causing a fork, which nobody wants to happen — least of all the Core Developers.
“It is of great importance in a republic not only to guard the society against the oppression of its rulers, but to guard one part of the society against the injustice of the other part. Different interests necessarily exist in different classes of citizens. If a majority be united by a common interest, the rights of the minority will be insecure” — Federalist 51
Can We Get An Example?
It’s possible that the next really contentious battle in Bitcoin governance will be whether or not to include Confidential Transactions (CTs). Let’s consider hypothetical opinions of the three branches, and how this could play out:
- Core Developers like it because privacy is a value they hold in high esteem
- Economic Nodes are split: some believe it ruins auditability of 21M, others don’t care
- Miners are split: the minority in remote oil fields are against (assuming CTs increase verification time or block transmission bandwidth), but the majority are in favor due to potentially higher fees
So large Miners align with the Core Developers. Bitcoin Core v42 is released with the activation software for Confidential Transactions.
In a lot=true scenario, majority hashpower upgrades their software, some percentage of the Economic Nodes try to campaign to keep the rest from upgrading, potentially releasing a UASF fork of Bitcoin Core, but the power of defaults carries the day and the Miner Activated Soft Fork (MASF) occurs largely without user consent. Is this still a user-owned system?
In a lot=false scenario, majority hashpower upgrades their software, some percentage of the Economic Nodes try to campaign to keep the rest from upgrading, potentially releasing a UASF fork of Bitcoin Core, there is no intransigent minority pushing for lot=true, and the power of defaults again carries the day as miners are forced to downgrade instead of producing blocks that the majority of Economic Nodes will reject. This sounds like a user-owned system to us.
What Happens Next?
Assuming Core Developers set the default to lot=false, the upgrade is set to a game of chicken between the Miners (who can MASF the change in whenever they please) and the Economic Nodes (who can UASF the change in regardless of what the miners do). Economic Nodes who want the Taproot upgrade to happen quickly must change their setting to lot=true, and campaign to get the rest of the Economic Nodes to join them. In the worst case, an intolerant minority setting lot=true will force the Miners to MASF in order to avoid the messiness of a chain split, and the Economic Nodes who left lot=false will follow the heaviest work chain as usual (risking an edge case during a 51% attack specifically targeting their SPV node, to be fair).
Going forward, we think this sets the ideal precedent for future upgrades, and defines where the limits of where Core Developers’ responsibility stops, and the responsibility of the Economic Nodes begins. Throughout the Taproot saga, Core Developers have felt the burden of proposing, writing, and testing the code, reaching out to miners to gauge sentiment, and reaching out to Economic Nodes to gauge sentiment, on top of actually deciding on how the soft fork actually gets activated. That’s too much responsibility!
In a lot=false world, Core Developers can feel comfortable releasing soft fork activation software and letting the actual decision to activate rest with the Miners and the Economic Nodes (possibly several soft forks at once!). The politicking is left up to the intransigent minority of Economic Nodes who really want the soft fork to occur by the proposed blockheight, and the Miners to upgrade according to the wishes of the Economic Nodes.
In our humble opinion, this version of bitcoin governance has the greatest potential to minimize the chance of bad upgrades getting forked in while still leaving open sufficient possibility for upgrades that are acceptable to the widest majority of the community in all three branches, which is ultimately what is Best for Bitcoin.
