Peer Production on the Crypto Commons

Version 0.8

Toward a Commons Based Economy

Software Developers

Blockchain developers can implement a change to their software which changes the consensus rules, but this will only take effect if the other constituencies apply this update. For some networks, there is only a single viable node implementation, and in those cases the other constituencies have limited choice in whether to accept or reject any proposed changes to the consensus rules. Rejecting a change may mean abandoning the chain which is being actively maintained in favor of a chain whose software is no longer updated, or is updated with weaker quality controls. Where multiple node implementations are available, other constituencies may have greater choice in whether to accept or reject proposed changes. Dominant implementations benefit from inertia and trust, as some participants may choose to defer to the judgement of a group that has already proven itself to be a reliable custodian of the code.

These decisions about which chain to follow blend the political with the technical. The decision of whether to embrace the BCH fork was not just about the merits and demerits of big blocks as a scaling solution, it was also about whether to use software produced by the Bitcoin Core or Bitcoin ABC teams. In an environment where unforeseen issues with code quality can have detrimental affects on utility and value, the developers’ capacity to reliably produce robust software is a pragmatic consideration.

In pure PoW cryptocurrencies like Bitcoin, miners have to some degree the power to veto a change to the consensus rules proposed by developers. If a majority of miners refuse to update their software to allow for the new rule’s implementation, they can effectively block it by refusing to process transactions that rely on the new rule.

User Activated Soft Fork

One episode from Bitcoin’s history involved a showdown between dominant PoW miners and other constituencies of the Bitcoin ecosystem - the User Activated Soft Fork (UASF). The Bitcoin Core developers coded a set up updates and new feature (SegWit) which would help Bitcoin scale by relaxing the block size limit and allowing Lightning Network to be used safely. SegWit was incorporated in the Bitcoin Core software along with a miner signalling activation threshold - the change would not activate unless enough PoW miners signalled support for it. This is a common method of deploying Bitcoin soft forks, as they cannot be used without miner support, and this support must be almost unanimous to avoid a chain split. After some months of miners failing to signal the necessary support to activate SegWit, a proposal was made whereby other nodes would force miners to signal support or see their blocks rejected by a significant component of the network. The number of Bitcoin nodes increased significantly, and many of them started to signal support for this UASF.

Ultimately, the PoW miners backed down in this game of brinksmanship, signalling SegWit support before the deadline imposed by the UASF code. If the miners had not backed down, the Bitcoin chain would likely have split in two, with many of the network’s “economic nodes” (exchanges, payment and service providers) refusing to accept new blocks from miners which did not signal support for SegWit. If enough miners had stuck to their position of refusing to activate SegWit, their chain would have had the most accumulated Proof of Work (the usual method to determine which chain is the legitimate Bitcoin chain). However, if “the market” had decided to prefer the UASF chain, miners may have lost out economically by mining on a chain whose rewards were worth less. Such a chain split may have damaged the reputation and value of Bitcoin in general, leading to two chains that were in combination worth less than the Bitcoin chain had been before the split - an eventuality which miners (and other constituencies) would wish to avoid.

It is difficult to know how much power the PoW miners really have in a contentious issue, as it depends on how constrained they are when deciding how to use their hashrate. A miner that must sell most of their rewards to meet operating costs has limited scope to mine on the less profitable side of a chain split in pursuit of some political agenda. Such miners are therefore bound to follow rather than set the market’s view of the chains’ relative worth.

Miners are Influenced by Markets

The UASF, BCH and SegWit2x stories from Bitcoin’s history illustrate how constituencies other than developers and miners can play a role in determining Bitcoin’s future. This is a complex and drawn out process, but to simplify: miners will tend to go along with whatever is most profitable for them. If other constituencies can create a scenario where miners will benefit economically by changing their position and behavior, that is probably what they will do. The abandoned SegWit2x fork was interesting because futures markets (where participants could buy options on coins from the SegWit2x and non-SegWit2x chains, effectively betting on which would be worth more) seemed to play a bigger role in the build-up and ultimate abandonment of the 2x fork.

When the developers have the users/merchants/businesses on their side, 2017 indicated that they can rely on the market to control the power of miners. Market dynamics around cryptocurrencies are famously volatile however, and in the case of a more contentious split than Bitcoin Cash one might anticipate even more erratic behavior in the markets. This kind of event is not conducive to the use of cryptocurrency as currency, where stability and predictability are desirable characteristics. It is therefore not in the interests of any of the ecosystem participants for the governance process to behave this way and have these effects.

Last updated on 10 Sep 2019
Published on 10 Sep 2019
Edit on GitHub