Bitcoin

Bitcoin has featured quite heavily in the previous sections as it is the blockchain with the longest and richest history. This page revisits some of the episodes from the scaling debate in light of the commons based constituencies framing.

• The UASF episode ¹ demonstrated that Bitcoin’s PoW miners do not have unilateral power to veto changes to the consensus rules. The fact that a range of actors in the Bitcoin ecosystem were willing to support splitting the chain, a risky and potentially chaotic move, demonstrates that PoW miners have some power to veto changes to the consensus rules which they dislike. In the case of SegWit activation, the miners backed down, indicating that they did not collectively feel strongly enough about SegWit to risk the disruption and damage of a UASF chain split. The UASF side won the game of brinksmanship in this case and did not have to follow through on their threat to fork non-cooperating miners on to their own chain - but it is not clear how the scenario would have played out if the UASF actually went ahead. Without enough mining power or an emergency difficulty adjustment the “BTC forced SegWit” chain would have progressed slowly for a time. If it commanded a price premium relative to the BTC non-SegWit chain then miners may have defected to collect its larger rewards.
• The BCH hard fork and chain split was orchestrated as a way for a segment of PoW hashing power and ecosystem actors to exit the main Bitcoin chain and strike out on their own. Bitmain, the dominant producer of ASICs and controller of Bitcoin hashpower, was instrumental in establishing BCH. By establishing BCH as a hard fork which was clearly differentiated from the Bitcoin chain, this approach likely caused less disruption than the UASF would have done. The BCH hard fork also incorporated an “emergency difficulty adjustment” that allowed the chain to progress with significantly less mining power, by updating the difficulty more frequently and drastically. The creation of a forked chain which could persist over time introduced the market as a key force which would determine the eventual winner. Bitmain stimulated demand for BCH by accepting it as payment for ASICs while rejecting BTC, and some other BCH supporting economic actors did likewise. In general though the PoW miners followed the economic incentives and collectively balanced their hashpower between the BTC and BCH chains in whichever way was most profitable for them, following price fluctuations closely. While miners have autonomy they also have costs to cover, and if the market determines that one chain’s assets are worth significantly less then it will not be able to support as many miners, lowering its security.
• The SegWit2x hard fork was proposed by a group of 58 companies in the Bitcoin ecosystem in what came to be known as the New York Agreement ². This agreement followed a meeting at Consensus in 2017, and much of the opposition which would be voiced focused on the fact that it came from a private meeting which most participants in the Bitcoin ecosystem could not attend, and which was not recorded. It quickly became clear that the SegWit2x fork would be contentious, with enough people opposing it to likely result in a chain split. SegWit2x was abandoned by its main supporters days before it was due to activate, citing lack of support within the Bitcoin ecosystem. The weeks and months leading up to this activation date saw significant volumes of often vitriolic opposition to SegWit2x voiced on social media platforms, and also the trading of 2x and no-2x futures on a variety of exchanges (SegWit2x futures had been trading ³ at $1,300 or around 20% of the BTC price).

Skilled Developers Required

Each of these (prospective) chain splits required software to be written which would implement the changes that cause the split. Furthermore, each prospective diverging chain would need its own group of developers who could maintain and enhance the software going forward.

The ultimate failure of the SegWit2x fork occurred not when it was abandoned by its main supporters, but when the small number of actors who tried to launch it anyway found their nodes stuck ⁴ on the block before the fork was supposed to activate, due to a bug in their code. Another demonstration that skilled and dedicated developers are a necessary part of any plan to fork (or found) a blockchain.

The last few years have offered much evidence and many demonstrations that maintaining the software for a decentralized cryptocurrency network is not easy. After some catastrophic issues in its early years (like allowing someone to mint billions of BTC) ⁵, it has been a number of years since any significant exploits have been identified in use on Bitcoin’s main chain.

In 2018 a bug was identified ⁶ by Bitcoin Core developers which would have allowed an attacker to take nodes offline. After a new version of the software had been released and adopted by the majority of miners, it was announced ⁷ that the bug was actually much more serious than indicated, as it would also have allowed an attacker to print unlimited BTC. The Bitcoin Core developers who patched the bug kept its severity a secret ⁸ until the patch had been adopted widely enough that the attack would not be able to permeate the network.

There simply cannot be show-stopping bugs that lead to unexpected outcomes in a cryptocurrency’s software, or that cryptocurrency will see faith in the solidity of its assets degraded. Respected and skilled developers have power because they are vital to any blockchain, and in short supply.

Is Code Blockchain Law?

In 2010, when an inflation bug was exploited to mint 184 Billion BTC ⁵, it was spotted immediately and enough miners could be coordinated to effectively roll back the chain. In 2018, there were orders of magnitude more users of Bitcoin, so it is not clear what would have happened if someone had exploited the 2018 vulnerability to mint BTC. If it was not immediately noticed, it is likely that some of the minted BTC could have been sold before anyone realized. A sum like 184 billion BTC stands out quite obviously, but smaller amounts may not be so easily detected.

If Bitcoin was exploited in this way, what would its stakeholders choose to do about it? Discussions about whether the network’s peers could or should do anything to mitigate certain kinds of attack/exploit are some of the most interesting ones in the space.

The potential of the social layer to intervene in a crisis by changing the rules is both a defence mechanism or deterrent, and a weakness, from different perspectives.

Bitcoin is software-based, and software is adaptable. For an attacker considering a major (and likely expensive) attack on Bitcoin, one of the considerations is whether the network’s stakeholders will be willing to suffer the damage their attack causes, in order to stick with the rules and the “code is law” principle. With blockchains, there is always the option in principle for the network’s stakeholders to rewrite their rules in a way which nullifies or mitigates an attack while maintaining the social contract as they see it. Use of FOSS software means this option is open to any developer who can code it, and from there available to any stakeholder who wants to take it.

The idea of an adaptable blockchain is disagreeable to others, who would tend to see this kind of move as a slippery slope towards stakeholders changing the consensus rules of the network more broadly. Cryptocurrencies are backed by faith that their rules will not change, in particular the idea of a “fixed supply” cryptocurrency rests on the assumption that stakeholders can not or will not change that rule. A cryptocurrency can have a stable monetary policy and predictable supply only in so far as the network’s nodes are unwilling to change this - they are always able, if there is collective will.

Mining Dynamics

When a fork occurs that results in two chains that share the same hash function, miners can switch between these at will but must at any given moment in time decide which chain to mine on. The chain with minority hashpower in this scenario is more vulnerable to attack because miners who rely on the dominant chain for their income do not have such a vested interest in the health of the network with lesser value. Where opportunities arise to extract profit for the miner at the expense of the network’s health, these are more likely to be taken when the miner can make a low friction exit to mine a different chain without suffering economic consequences. GPU mined coins also suffer from this effect generally.

A 2019 article ⁹by Nic Carter considers this weakness from the perspective of final settlement, or knowing when a transaction has enough confirmations to be considered irreversible. Carter concludes that GPU mined chains can only provide weak assurance that a transaction will not be reversed because it is always possible that significantly more hashpower could be added to the network and the chain could suffer a deep reorg. Blockchains mined with ASICs have a much lower limit on the amount of additional hashpower that could be deployed on the network.

Developers Have Power

Developer groups must also choose which side of a chain split to join, and for developers this may be a high friction decision, making it difficult to later switch to work on software for the other chain.

The Bitcoin Core group of developers, whose software is used by 97% of the Bitcoin public nodes, were as a collective on the “winning” side in each of these episodes. Surveying the cryptocurrency space as a whole, there are very few blockchains that have seen their founding group of developers displaced by an alternative group. Bytecoin is the only example that springs to mind, where revelations about 80% being secretly premined by its pseudonymous developers led to alternative implementations that surpassed Bytecoin in popularity (Monero being the highest profile).

In 2020, we saw another example ¹⁰ of a lead developer team being “outed” from this role, as part of a recent Bitcoin Cash fork. This example is a little different however, in that the developers tried to force a contentious hard fork of which they were the direct beneficiaries - the consensus change would see 8% of block rewards flow to the ABC dev team. This hash war had a clean outcome, although the miner signalling had been divided, and initial hashing was also split, all but a few miners quickly abandoned the ABC chain in favor of the new “BCHN” chain. This sets up an interesting scenario, because the ABC dev team have effectively no working chain using their new client, its block rewards are worth very little at a current price of $15 (Dec 2020) which is ~5% that of BCH(N), the clear winner. The BCH chain has lost most of the developers who worked on its software and miners have shown an unwillingness to fund this work out of block rewards.

The history of most other blockchain projects at this point indicate that developers of pure PoW cryptocurrencies with no formal governance hold the most power within those ecosystems. It remains to be seen what will happen if an issue arises which splits the developer constituency more evenly in two. The level of support from the other constituencies would clearly be important, but so might control of key assets like GitHub repositories. While it may be clear to direct participants that the developer constituency is divided, others may rely on signals like what’s happening in the Bitcoin Core repository or what the sticky thread or top post on /r/Bitcoin says.

Chain Splits

In the case of a chain split, holders of the asset have an equal number of units on each chain, and now have a choice about which one to use. From a technical perspective, users are not compelled to pick a side. As long as precautions are taken to make transactions incompatible between chains (to avoid replay attacks), users should only be exposed to damage from a chain split to the extent that the two split chains are weaker than the former sum of their parts. Nevertheless, the Bitcoin community did appear to fragment as a result of the episodes described above, with many members announcing their preferred fork and becoming hostile to supporters of the other variants.

Exchanges have some work to do to accommodate the existence of a newly split chain and ensure that their systems handle it appropriately - but they also stand to benefit from collecting trading fees on markets that allow the assets (or futures) to be traded against each other.

Bitcoin has also had a number¹¹ of “chain split” forks (of the 44 since Bitcoin Cash) where rather than splitting the Bitcoin community the intention is to leverage Bitcoin as an airdrop type distribution method for a new project. Anyone can fork the UTXO set of Bitcoin or any UTXO-based cryptocurrency and award their new coins (which will follow the rules they set) to Bitcoin holders. This seems to have been used as a tactic by some teams for getting a headstart on recognition and awareness - as well as gaming the market capitalization metric with a lot of units that are technically circulating but whose holders are unaware.

Commons-based Deliberation

The Bitcoin Core developers conduct a significant degree of deliberation about the project in public spaces like mailing lists, GitHub, and logged IRC channels - and as with most FOSS projects the work itself and coordination around it happens quite openly. Discussions about these decisions percolate out into social media more broadly (blogs, twitter, reddit), where a more diverse array of ecosystem participants make their perspectives known. This kind of public review process is integral to Bitcoin, as can be seen in the rejection of SegWit2x based in some part on how the proposal originated from a closed meeting. Due to its CBPP roots, Bitcoin has a degree of transparency in its governance that far surpasses any other organizational form producing a public resource on this scale - thinking here about private corporations, non profits, government departments and central banks.

Bitcoin’s governance is largely informal, as with many CBPP projects. There is however a commonly accepted method of tracking proposed changes to the software - Bitcoin Improvement Proposals (BIPs). I have written about this approach elsewhere ¹² and won’t repeat it here, suffice it to say that there is considerable discretion on the part of key contributors in determining whether a BIP advances.

Bitcoin Core contributors also communicate in publicly accessible mailing lists, in IRC chat rooms (with weekly meetings that are logged and summarized, although 2019 meeting logs are harder to find), and on the Issues and Pull Requests of the Bitcoin GitHub repositories.

As the network grows in significance, the stakes get higher - strategic decisions about the Bitcoin Core software are arguably the most important of any FOSS project. The lack of formal governance means that resolving disputes can be a long drawn out affair, as ad hoc signalling mechanisms may produce conflicting signals and are all susceptible to manipulation. Miner voting, the only signalling method available to a Bitcoin constituency that’s not easily manipulated, has been discounted by most Bitcoin advocates as a legitimate aspect of governance.

As noted in the developers constituency section, Jo Freeman’s The Tyranny of Structurelessness ¹³ is relevant here. Without formal structure to guide decision-making it is likely dominated by the interactions of its elite members, and only people who are directly involved would be able to follow and understand the dynamics in play.

A 2020 article ¹⁴ by Pete Rizzo and Aaron van Wirdum provides a well sourced account of one of Bitcoin’s formative governance events following the departure of Satoshi, the “Battle for P2SH”. Pay to Script Hash (P2SH) is a way of protecting funds with multi-signature transactions that require multiple private keys to unlock funds. In this episode, a soft fork was seen as an undesirable way to deploy the update because mining power was so centralized that the decision came down to a few pool operators who did not feel qualified to make it or want to have that responsibility. The idea of “miner voting” to choose between two competing multi-sig implementations was considered because it aligned with what was required to activate the changes (hashpower). However, this was rejected due to the precedent it would set, certain developers were keen to avoid the impression that miners were making such a technical decision. Instead, they set up a process where an inner circle would discuss the issue for two weeks and hold a vote. The miners would the be presented with a single option (P2SH) which they would be encouraged to “vote” to activate.

• Additional Resources
  • Jameson Lopp’s Bitcoin resources page
  • Hasu’s Unpacking Bitcoin’s Social Contract
  • Bitcoin Magazine Map of Bitcoin Forks

References