Financial Cryptography

The Great Bitcoin Fork - heartbleed or bleeding hearts?

Bitcoin has just had its first big security failure. Perhaps surprising to some, the security was breached at the human layer known as governance, and not at the cryptographic or protocol layers.

TL;DR: the threat that evaded the security model was this: the Bitcoin community has failed to agree on how to evolve the protocol, and this failure has taken concrete form in the announcement of Bitcoin-XT, an alternate that may be incompatible with the current client. To solve this failure, a new governance layer is needed.

If one subscribes to the triple entry thesis, Bitcoin underpins the most radical and productive innovation in finance since double entry accounting, and it thus behoves to analyse the nature of the security failure carefully. The failure for a group to reach consensus is a very old problem of humanity and is not easily susceptible to technological hack. Whilst we have some good algorithms and structures to manage these problems, it is important that the community recognise that fixes required to the threat model is as much to the community itself as to the protocol or cryptography.

---

A brief interlude to explain, before discussing solutions: This schism within the Bitcoin community resulted in the announcement of larger blocksizes in Bitcoin-XT to deliver higher transaction capacity, something which many claim is necessary to take Bitcoin commerce to the retail level. However, the process of changing the fixed parameters in the Bitcoin protocol is fraught because of the nature of the consensus algorithm.

Bitcoin is a replicated shared ledger system that batches transactions into 'blocks'. The network of distributed client programs comes together to agree on each block, the result being the Nakamoto Signature over each block.

It doesn't matter today how that signature works - the proof of work consensus protocol - what matters is that some 6000 nodes meet and sign every 10 minutes according to a very complicated set of rules. To change those rules is problematic because we can’t update all the clients at once, and so … problems can emerge.

That problem is broadly called a fork - when one part of the network fights for a block that differs to the block of another part, the consensus algorithm starts humming until there is an eventual winner. This is the genius of Nakamoto's signature - if there is a fork, the network just keeps humming away until one or other of the sides backs away and dies.

But, the fear is, if there are different protocol rules, the "erstwhile losers" will never back off and a permanent fork is possible - the shared replicated ledger enters the twilight zone where your transaction is both confirmed and lost at the same time. In this case, the older clients will never accept a block larger than 1,000,000 bytes; blocks greater than that size could conceivably trigger a permanent fork.

Conventional logic is that the community needs to manage such a change to software carefully and plan ahead. Which would be fine, if that were done, but as is the way with these things, this planning, which was first mooted 5 years ago, has been stymied by one means or another.

What's going on here? It probably helps to catalogue the forms of fork that exist, as of the moment, in a layered approach:

1. There is the fork in transactional block understanding, which the proof of work consensus algorithm strives to and ultimately suppresses. This works because statistically, the network of clients includes enough uncertainty and the algorithm provides enough incentive to push some nodes around and thus force one side or other to lose.
2. A fork in software is more problematic as the rules should be deterministic for the first fork to resolve. The normal statistical methods don't work here, but when it happens - once in recorded history - the core team can come together as they did in 2013, isolate the rule failure, and push software changes or recommendations out to fold back the competing blocks into one.
3. A fork in the core team is more problematic. When one side of the team wants path A and the other side of the team wants path B, arguments ensue. Against the threat of core team fork, the Bitcoin mitigation of 'we voluntarily agree' is too soft for a credible security project.

It is this third type of fork we now observe. To defend against this fork, the control of Bitcoin’s core algorithm has been left by custom to a small, tight team that manages one client software base called bitcoind. Five committers work closely together to put changes in.

However there was always a fork possible because in the open source world, forking the software base and starting a new project is considered normal, routine, and a cause for celebration: creativity. Indeed, there are many hundreds of projects called altcoins that have done precisely that - forked the software and started up a new chain - and there are several competing code bases that follow the same rules.

That part we know well, but an attempt to fork the software, change the rules and work on the same chain is novel.

Surely the core team knew well enough to not do that? Surely they had the discipline to not deliberately risk a permanent fork and bring down the entire $4bn Bitcoin community? That’s how many people are putting it - outrage - but we instead would like to point out that in the history of human affairs, one thing stands out:

If it can go wrong, it will.

Murphy's Law has it that if there is a weakness, eventually someone or something will get around to finding the circumstances for triggering that precise set of conditions. This view would suggest that even if the core team could present that elusive quality of better discipline and better responsibility, something is going to happen, one day. The flaw isn't in the team, because they are human after all, the flaw is in the systems design or more properly the security model. Failure to agree is a well known failure mode, and should have at least had a higher likelihood assigned in the risk analysis. Accept the risk of core team failure was then always a short term mitigation.

---

Assuming the inevitability of human divergence, how do we solve the higher layer team fork?

There are several ways to deal with this. One is to not have a fork. Another way is to encourage forks to naturally resolve themselves. A third is to find a way to live with the fork.

Not having the fork means in essence better leadership - not have the core team decide to fork. But our Murphy's Law observation indicates that a small tight single team will always fork in one way or another. Or, to draw on political history, there is a contradiction between the ideals of Bitcoin as a system of property rights, and the lack of ownership of the system as a property right, and until that is fixed, Bitcoin is in trouble.

There are many ways to deal with this contradiction, but just one way that seems to keep emerging throughout time is to split the single team into three and establish joint ownership of the system for the commons: Legislature ⇔ Judiciary ⇔ Executive.

Popularised by the US Republic, the 'powers' are split between the three ‘heads’ in an inherently unstable fashion. The executive appoints judges, but cannot tell the judiciary what to do. In contrast, the judiciary can tell the executive what to do, but, the judge's power is limited by a given case, and by the body of law and precedent, which comes from the Legislature. The legislature can tell the other two what to do, but only in the future. In order to keep the legislature and the executive in check, the people assemble every 4 or so years and throw the buggers out.

Long term stability is ensured by the inherent instability of the triangle; fights are frequent and noisy but civil war rarely breaks out. This stable triangle of unstable nodes, sometimes called three heads of power, can be adopted by any community. For example, the CAcert community does exactly that model: Policy ⇔ Arbitration ⇔ Board. Same powers and roles, same fights, different labels. Alternatively, many other methods and variants have been trialled throughout history and through the open source world.

---

How might this work in practice for the Bitcoin community? Part of it is already in place - Bitcoin’s system of BIPs presents a legislature. Another part would be to fork (pun intended) the political decisions away from the engineering decisions. In this case, the decision to increase the blocksize would be made by the political or executive team, which would be subject to regular elections. The technical dev or engineering team would then simply implement the how, and not engage in the politics of the whether other than to provide the politicians with advice.

The third part is when the technical team and executive team, or any other participants, cannot agree on something. For this, a forum of dispute resolution is needed. This is simple to organise - everyone who participates simply agrees up front to refer their disputes to the forum - but is harder to run as an Arbitrator has a tough job of making a ruling over an already complex situation. However, that’s out of scope of this article, what's important is that there is always a path by which fights are resolved, before escalating into civil war and bloodshed.

This method turns a core team fork into a decision as to lead team, but it wouldn’t stop the fork from happening - a rival team could simply start a new core development. But even then, the separation between political, engineering and dispute decisions would facilitate negotiation and finding new agreement because there are now three potential paths with which to negotiate with the rival team. Each of the three heads of power could find different paths, and the instability of their arrangement would lead to a solution emerging.

The combined power of the three, and the better control by the community would lead to more faith. The presence of the judiciary and the possibility of your voice being heard would strongly tilt preference to the governed system and away from rival teams. It might also lay the foundation for treasured ideals such as clear fungibility in most circumstances, and reversals of clear wrongs in the exception.

In closing, we should remember that technology cannot fix all of mankind’s problems. Very often, in fixing one problem, we reveal knottier and usually deferred problems in higher layers; Bitcoin’s consensus algorithm fixes blockchain forks and thus reveals forks in the rules and in the team. How to build a protocol that can handle higher layer forks remains an issue as outsiders can still attack the mainnet chain with their own proposed codebase. This is beyond the scope of today's brief missive, indeed, it's quite a project in its own right, but it is not outrageous - have a look at treechains or sidechains or Tezos for alternate schools of thought in how to handle higher-layer forks.

That the Bitcoin design got this far, and the community has come to cross this Rubicon so early in life is no disaster, rather it is the mark of accelerated intellectual robustness and excellence in design. But design does not solve everything, it especially does not address the age-old problem of being unable to foretell the future, a syndrome which is commonly referred to as 'politics'.

---

Ed note: this essay received some comments and wordings from Arthur Doohan and Ada Lovelace.

Posted by iang at August 24, 2015 04:27 PM