13

In March 2013 there was a fork following the v0.8 release. The issue was resolved rather efficiently, as explained in the post-mortem report. However in this process there were winners and losers: the miners building on the v0.8 chain had to give up their block creation fee.

The next time there's a fork like this, it may not be so straightforward. The miners may not all agree on the proper resolution for the issue.

Is there any documented set of rules (bye-laws) explaining how such forks are to be resolved in the future?

If there's a conflict among the parties involved, who has the final say?

PS: Any comments on Bitcoin's so-called (faux) "decentralized" architecture are also welcome, given my other question has been censored. The decentralization doesn't seem to work after all, which begs the question as to what the whole point of the proof-of-work scheme is anyway.

14

A hard fork is by definition one that does not get solved. At least not by the rules of the system, as it is essentially an incompatibility between the rules assumed by separate nodes.

But think about what can cause such a thing:

  • An incorrect (=not identical to the rest of the network) implementation forks off. In this case it will always certainly be clear who is "at fault". For example, in the 0.7 vs 0.8 fork, there was a bug in the 0.7 (and older) clients that limited them in an unknown way, but 0.8 was at fault for not correctly mimicking the bug. As keeping such a weird and inconsistent limitation would hold the network back, and be risky in itself, the bug-free behavior will become allowed after may 15. However, if old full clients remain on the network after that date, they will end up on a fork, and this fork will not resolve.
  • Two implementations arise that knowingly implement different rules, perhaps because of ideological disagreement about what the rules should be. If both are economically significant and have significant mining behind them (which in neither case necessarily means a near-majority), this is pretty much a disaster. The incentive for consensus is huge, as disagreement effectively means granting every old coin hold to spend it once on each side.

Regarding decentralization, I think you mistake consensus for centralization. There are of course degrees, but ultimately it is Bitcoin's users who decide which rules to enforce by the software they run. However, as explained, there is a huge incentive for making sure no real disagreement arises. In some cases that may mean discussion will be needed, and an agreement has to be reached, perhaps a compromise. But it doesn't mean one party gets to control others.

  • 1
    "I think you mistake consensus for centralization." How does one achieve consensus among a million nodes without deferring to a few (elected) representatives? By that logic, all currency issued by a democratically elected government is decentralized. It's "decentralized plus consensus," you might say, and (oh!) it can always be forked. That makes Bitcoin no different. – Manish Apr 20 '13 at 10:35
  • 2
    Well if no consensus can be reached (by whatever means), then the default is that the rules stay the same. If people refuse the change their software, perhaps by disagreeing with what their 'elected representatives' decided, and even if they are a minority, then moving forward with a change is suicide for the system. And as the system matures, the need for changes to the rules will hopefully decrease as well. – Pieter Wuille Apr 20 '13 at 11:22
  • You're right, of course, but the same could be achieved with a more honest centralized-but-distributed design. People could still fork the ledger if they didn't like the rules. Advantages: no 51% attack, faster transaction processing, energy-efficient, etc. It's not clear what is achieved by Bitcoin's proof-of-work other than to give the false appearance of being decentralized. – Manish Apr 22 '13 at 14:21
  • "... then moving forward with a change is suicide for the system." This is an article of faith in the Bitcoin community. Real life experience with fiat currencies suggests otherwise. If the US Federal Reserve printed any more money, it would be "suicide for the system," but alas no one really cares (more interested in Kim Kardashian). No one cared when Nixon went off gold in 1971. en.wikipedia.org/wiki/Nixon_Shock – Manish Apr 22 '13 at 14:30
  • 1
    The rule is that the longest valid blockchain is accepted. A hard fork is when for some reason (usually unintentionally) two sets of nodes disagree about what is valid. – Pieter Wuille Nov 21 '13 at 19:21
5

The core concept has always been accept the largest blockchain that passes the predetermined proof of work tests. Hard forks like the one that occurred in March happen as a result of some software in the p2p ecosystem having a different understanding of what the legitimate blockchain should be. This reality is ok with all distributive networks to some extent and usually gets resolved rather quickly and in many cases autonomously

Yet march was special in that the 0.8 clients could never agree with the 0.7 clients due an issue processing a larger than normal transaction volume, but 0.7 clients still had 60% or so of the total hash power. In essence the network had two different legitimate bitcoins floating about. Your question was who got to decide which one was the legitimate chain and what happened to the coins?

BTCGuild and Slush got to decide as they collectively control over 51% of the network's hash power. And also some people had to accept that the blocks in the orphan fork had to be lost for the good of Bitcoin. It isn't necessarily fair. It isn't fun. But Gavin and others handled it both quickly and transparently.

The next time there's a fork like this, it may not be so straightforward. The miners may not all agree on the proper resolution for the issue.

This is a valid concern and is something we accept as a community to be an issue. Generally speaking people tend to be self-interested and miners have a vested interest in preserving the value of Bitcoin. Thus always assume behavior will be economically motivated as Satoshi did in his paper discussing honest nodes.

Is there any documented set of rules (bye-laws) explaining how such forks are to be resolved in the future?

No and there will never be because that implies an organization asserts the right to prescribe behavior in the community, which defeats the whole point of having a decentralized p2p currency. Only when pool operators decide to group up with more than 51% hash power can they make decisions for Bitcoin. This rarely happens unless an event like March occurs that could damage the integrity of the entire system

If there's a conflict among the parties involved, who has the final say?

Whoever has 51% hash power.

PS: Any comments on Bitcoin's so-called (faux) "decentralized" architecture are also welcome, given my other question has been censored. The decentralization doesn't seem to work after all, which begs the question as to what the whole point of the proof-of-work scheme is anyway.

I've been censored as well and no bitcoin is currently not decentralized as envisioned. I mention this in my Bitcoin course using the notion of oligarchiness as a measure of central control. There are a handful of very influential people currently developing and maintaining the bitcoin ecosystem. They have a dramatic say in how the money works and the software to use it. Over time as more actors enter the marketplace and nation states begin to use Bitcoin, this will be reduced until eventually no one party has control.

Remember that at one time Satoshi had 100% of all bitcoins in circulation and the software running the network. We have made wonderful strides over the past 4 years and will continue to do so over the next 4 years.

2

Those who will buy the coins from the miners are the ones who guide the miner's behavior.

This is called the economic majority.

At the level of maturity of the Bitcoin economy in March, 2013, the decision as to what the economic majority wanted was the response to a very short question: "What side of the fork is Mt. Gox on?"

The answer to that was that Mt. Gox was still using the v0.7 client. That response alone was enough to instantly know the will of the economic majority. Until there isn't a single exchange holding the vast majority of economic value, then simply that one exchange is the decider.

Now if, for instance, BTC Guild's miners didn't want to abandon the v0.8 side of the fork, they could have switched to other pools such as Slush's (which was still on the v0.8 side) or switched to P2Pool, etc., and continued mining on the v0.8 sid.e Then there wouldn't have been enough hashing on the pre-v0.8 side to cause that to become the longest chain. But if Mt. Gox were to have held firm with v0.7, the newly mined coins would not been spendable and eventually miners would likely have defected to the v0.7 side eventually.

If Mt. Gox had been using the v0.8 client already, the hard fork issue would have been resolved likely by new configuration settings (or a patch) to previous releases being released to fix the newly re-discovered limitation that had existed with all pre-v0.8 clients.

  • 1
    Though it was BTCGuild suggesting to switch to 0.7 to resolve the fork, and this was indeed after asking Mt.Gox what they were using, we (several people in #bitcoin-dev at the time, including me) immediately agreed that was the best solution. I can't speak for others, but for myself that had nothing to do with Mt.Gox, but simply with the fact this was the only solution that didn't require an immediate hard fork of the network. – Pieter Wuille Apr 20 '13 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.