August 24, 2015

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
Comments

....
Contrary to what we would like to believe, there is no such thing as a structureless group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. The structure may be flexible; it may vary over time; it may evenly or unevenly distribute tasks, power and resources over the members of the group. But it will be formed regardless of the abilities, personalities, or intentions of the people involved. The very fact that we are individuals, with different talents, predispositions, and backgrounds makes this inevitable. Only if we refused to relate or interact on any basis whatsoever could we approximate structurelessness -- and that is not the nature of a human group.

This means that to strive for a structureless group is as useful, and as deceptive, as to aim at an "objective" news story, "value-free" social science, or a "free" economy.

Posted by: Joreen - THE TYRANNY of STRUCTURELESSNESS at August 24, 2015 07:14 PM

Ian, that is an interesting idea about applying the three branches, executive, legislative and judicial to other types of community than the U.S. government. The executive and legislative branches of a decentralized corporation could be done using market operations, leaseholds, insurance, options, task markets and auctions.

The position of executive could be treated as a leasehold, and auctioned to the highest bidder, with an insurance requirement. The insurance requirement would be against liability for any claims brought against the executive to be decided by the judicial branch. The insurance requirement could be filled in a P2P insurance auction market. If an executive gets claims agains him which the judicial dept upholds, the insurance investors will have pay. The executive will then either have higher insurance rates, or be unable to obtain coverage, and be forced to yield his executive leasehold position in auction to the next highest bidder who can get the required insurance coverage.

The legislative branch could be done using task, insurance and options markets. Community members could buy options (or insurance) against legislative changes which they oppose or which adversely affect them. Proposed changes could be handled as a task market, where people who want the change would pay into the task market, but the market would not clear until it had enough payments to overcome or pay off any options or insurance policies held by people who oppose the change.

Posted by: Vincent Youngs at September 28, 2015 12:56 PM

Great, proven solution! The problem is - imposing this leadership structure retroactively would be next to impossible without spawning a fork.

Posted by: Ken at October 24, 2015 06:36 PM

Upon further thought, all you need to achieve this is to persuade a supermajority of the present dev team to get on board. Once you have the devs committed to the new leadership structure, those who refuse to join can fork, but probably won't have the development skill and bandwidth to get very far.

Posted by: Ken at October 24, 2015 06:40 PM

The elephant in the room, Ian, is that if an organization is formed with property rights over the system as a whole, that immediately creates a target for the regulators to attack.

Presently, Bitcoin cannot be shut down because no one owns it, and the cost of attacking every node is too high to be feasible.

However, if an organization is created that governs the protocol and the client, this legal entity and its leaders may be held to own and operate the network, and thus fall under regulatory law, reporting, and prosecution for failure to report, get licensed, etc.

Bitcoin's fundamental dialectic is, as Vinay Gupta said, an anarchist network following rules enables libertarian property rights. But if the rules must grow, the question becomes "who makes the rules?"

As you point out, anarchy cannot prevent forks. Attempts to replace anarchy with order produce bring the system back into the real world and under government control.

You could theoretically create a pseudonymous control system where each bitcoin gets one vote, and the directors, arbitrators and coders all use nom de plume with a public key. You could theoretically run an anonymous organization that way. But transactions and exchange create the connections that enable government to penetrate the veil of anonymity. Bitstamp, Coinbase and others maintain the id databases that a government can use to uncloak large segments if not the majority of the user base.

In the end, Bitcoin cannot escape government control.

Posted by: Ken at October 24, 2015 06:58 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.