<p>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.</p>

<p>But think about what can cause such a thing:</p>

<ul>
<li>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.</li>
<li>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.</li>
</ul>

<p>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.</p>

CC BY-SA 3.0
2013-04-20T10:35:53.333Z
"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
CC BY-SA 3.0
2013-04-20T11:22:19.293Z
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
CC BY-SA 3.0
2013-04-22T14:21:58.483Z
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
CC BY-SA 3.0
2013-04-22T14:30:17.237Z
"... 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. http://en.wikipedia.org/wiki/Nixon_Shock
Manish
CC BY-SA 3.0
2013-04-22T18:52:44.933Z
@Manish not sure why you're taking such an antagonistic tone--people are here to answer questions about Bitcoin, not to "defend it". Nonetheless I think even a quick glance through the development mailing list will show that there's no one in the Bitcoin community with power at all approaching that of a central government. Specifically with the March 2014 fork you'll note that Gavin's first suggestion wasn't the ultimate course of action. But consensus in the face of a glitch is easy. More important is the fact that despite multiple clients and four years of development, the _only_ hard forks
eMansipater
CC BY-SA 3.0
2013-04-22T18:57:19.943Z
have been due to glitches. Bitcoin is distributed precisely because the technology is stable enough not to _need_ regular decisions from the community about who to follow. Any significant technical change would require something Nixon never had--an advance supermajority of consensus. Otherwise no would care about a proposed change in the first place, and no one would bother downloading any new client which implemented it because the change is too controversial. The community trusts developers to fix glitches, not make radical protocol changes.
eMansipater
CC BY-SA 3.0
2013-04-24T21:06:56.117Z
"... then moving forward with a change is suicide for the system.". I don't mean this in the political sense. It's economic suicide for a currency if every coin can suddenly be spent twice, once on each side of a fork.
Pieter Wuille
CC BY-SA 3.0
2013-11-21T08:49:30.210Z
What baffles me is that in all technical explanations I read so far its said that the longest blockchain is automatically accepted. But in reality this doesn't seem to be the case, right? So when the protocol says to automatically accept the longest blockchain but in reality it doesn't happen, doesn't that mean that the protocol is not fully implemented at this point?
Mark
CC BY-SA 3.0
2013-11-21T19:21:55.193Z
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
CC BY-SA 3.0
2013-04-19T16:55:43.120Z
2013-04-19T16:55:43.120Z
Pieter Wuille
<p>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</p>

<p>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?</p>

<p>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.  </p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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. </p>

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

<p>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 </p>

<blockquote>
  <p>If there's a conflict among the parties involved, who has the final
  say?</p>
</blockquote>

<p>Whoever has 51% hash power. </p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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. </p>

<p>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. </p>

CC BY-SA 3.0
2013-04-24T02:29:39.223Z
2013-04-24T02:50:45.657Z
2013-04-24T02:50:45.657Z
Charles Hoskinson
<p>Those who will buy the coins from the miners are the ones who guide the miner's behavior.</p>

<p>This is called the <a href="https://en.bitcoin.it/wiki/Economic_majority" rel="nofollow">economic majority</a>.</p>

<p>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: "<em>What side of the fork is Mt. Gox on?</em>"</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2013-04-20T11:35:56.257Z
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
CC BY-SA 3.0
2013-04-20T02:16:57.870Z
2013-04-20T02:23:48.770Z
2013-04-20T02:23:48.770Z
Stephen Gornick
<p>In March 2013 <a href="http://bitcoin.org/chainfork.html">there was a fork</a> following the v0.8 release. The issue was resolved rather efficiently, as explained in the <a href="https://en.bitcoin.it/wiki/BIP_0050">post-mortem report</a>. 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.</p>

<p>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.</p>

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

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

<p>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.</p>

<blockchain-fork><march-2013-fork><decentralization><governance>
How is a hard fork resolved?
Manish
# How is a hard fork resolved?

(Asked by: username_0 on 2013-04-19)

In March 2013 [there was a fork](http://bitcoin.org/chainfork.html) following the v0.8 release. The issue was resolved rather efficiently, as explained in the [post-mortem report](https://en.bitcoin.it/wiki/BIP_0050). 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.

**Tags:** blockchain-fork, march-2013-fork, decentralization, governance


---

## 3 answers

### Answer by username_1 on 2013-04-19. Score: 15

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.

> **Comments:**
> **username_0**: "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.  
> **username_1**: 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.  
> **username_0**: 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.  
> **username_0**: "... 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. http://en.wikipedia.org/wiki/Nixon_Shock  
> **username_2**: @username_0 not sure why you're taking such an antagonistic tone--people are here to answer questions about Bitcoin, not to "defend it". Nonetheless I think even a quick glance through the development mailing list will show that there's no one in the Bitcoin community with power at all approaching that of a central government. Specifically with the March 2014 fork you'll note that Gavin's first suggestion wasn't the ultimate course of action. But consensus in the face of a glitch is easy. More important is the fact that despite multiple clients and four years of development, the _only_ hard forks  
> **username_2**: have been due to glitches. Bitcoin is distributed precisely because the technology is stable enough not to _need_ regular decisions from the community about who to follow. Any significant technical change would require something Nixon never had--an advance supermajority of consensus. Otherwise no would care about a proposed change in the first place, and no one would bother downloading any new client which implemented it because the change is too controversial. The community trusts developers to fix glitches, not make radical protocol changes.  
> **username_1**: "... then moving forward with a change is suicide for the system.". I don't mean this in the political sense. It's economic suicide for a currency if every coin can suddenly be spent twice, once on each side of a fork.  
> **username_3**: What baffles me is that in all technical explanations I read so far its said that the longest blockchain is automatically accepted. But in reality this doesn't seem to be the case, right? So when the protocol says to automatically accept the longest blockchain but in reality it doesn't happen, doesn't that mean that the protocol is not fully implemented at this point?  
> **username_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.  

---

### Answer by username_4 on 2013-04-24. Score: 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.


---

### Answer by username_5 on 2013-04-20. Score: 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](https://en.bitcoin.it/wiki/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.

> **Comments:**
> **username_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.  

---

