<blockquote>
  <p>So which is it? Does "hard fork" describe a condition of the network, or a software update?</p>
</blockquote>

<p>Either is acceptable. You can say that version so-and-so causes a fork, and you can say that the network is currently forked.</p>

<blockquote>
  <p>Was the March 2013 fork a hardfork?</p>
</blockquote>

<p>It depends on your definition. The March 2013 incident initially appeared to be a hard-fork, but a later investigation showed that it was possible to trigger the issue even when all nodes were running the same version.</p>

<p>Quoting from <a href="https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki" rel="nofollow">BIP50</a>:</p>

<blockquote>
  <p>This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).</p>
</blockquote>

<p>However, it was a hardfork in the sense that newer clients would create and validate blocks that an older client would not see as valid.</p>

CC BY-SA 3.0
2016-07-09T22:35:41.203Z
A little elaboration on how context-sensitive this bug was in practice, from Greg Maxwell: "... not only did only _some_ [0.7.2 nodes] reject [the problem blocks] but they only rejected that particular one when they saw it as part of a reorg."
ZakW
CC BY-SA 3.0
2015-02-19T04:48:11.853Z
2016-07-09T22:50:18.140Z
2016-07-09T22:50:18.140Z
Nick ODell
<p>In addition to the March 2013 bug, the bug introducing CVE-2018-17144 was also a hard fork, even if there was no chain split.</p>

<p>The fix was a soft fork, since it restored the old consensus rules.</p>

CC BY-SA 4.0
2018-09-24T16:59:02.197Z
2018-09-24T16:59:02.197Z
Janus Troelsen
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki#resolution" rel="nofollow noreferrer">2013 Post-mortem</a> was an undoubtedly intentional hard fork.</p>
<blockquote>
<h3>Resolution</h3>
<p>On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.</p>
</blockquote>
<p>Source: <a href="https://twitter.com/LukeDashjr/status/1044984995717279749" rel="nofollow noreferrer">Luke Dashjr</a></p>

CC BY-SA 4.0
2018-11-23T13:36:50.060Z
2018-11-23T13:36:50.060Z
2020-06-16T11:10:03.350Z
MCCCS
<p>To directly answer your question, "Has a hard fork ever occurred?", No.</p>

<p>The 2013 event that you reference was a temporary fork or chain split.</p>

<p>A hard fork would be both the result of deliberate action (as you have quoted) and persistent. If there is no consensus at the point of a hard fork, two distinct forward chains emerge. You may appreciate more information on forks in this response: <a href="https://bitcoin.stackexchange.com/a/30821/75001">link</a></p>

CC BY-SA 4.0
2018-09-24T17:00:22.743Z
A hard fork doesn't need to be deliberate, why do you think that? It is a technical term. CVE-2018-17144 was a hard fork, but it wasn't deliberate.
Janus Troelsen
CC BY-SA 4.0
2018-09-25T05:27:12.063Z
@JanusTroelsen A change in the software is not a hard fork. A hard fork is a condition of the blockchain. As it is, unpatched nodes could accept a block outside of what consensus allows but since already it is estimated more than 50% of the Bitcoin hashrate is upgraded there is no realistic probability of a chain split. If anything the situation is more similar to a soft fork and in any case, there is no change to the consensus.
Willtech
CC BY-SA 4.0
2018-09-25T09:20:48.990Z
As you can see in the question formulation, there are at least two definitions of hard fork.
Janus Troelsen
CC BY-SA 3.0
2018-01-23T09:00:53.743Z
2018-01-23T09:00:53.743Z
Willtech
<p>@Rich Apodaca, i believe that you may have answered your question somehow, as you pointed out that it was mostly a minor incompatibility of installed versions of bitcoind. </p>

<p>Maybe you will agree with me that hardfork would have to be an incompatibility of design between two versions of the same protocol. Take for instance one altcoin, like FeatherCoin, that abandoned their previous algorithm for Proof of Work to adopt another one, ASIC-resistant, and incompatible with the past one.</p>

CC BY-SA 3.0
2015-02-19T04:10:58.033Z
2015-02-19T04:10:58.033Z
hgfernan
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki" rel="noreferrer">BIP 50</a> describes the 2013 event in which a block chain fork persisted for several hours. Its first paragraph reads:</p>

<blockquote>
  <p>A block that had a larger number of total transaction inputs than previously seen was mined and broadcast.  Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected <strong>hard fork of the chain</strong> [my emphasis].  The pre-0.8 incompatible chain at that point had around 60% of the hash power, ensuring that the split did not automatically resolve.</p>
</blockquote>

<p>I interpret this to mean that the term "hard fork" describes a state of the network.  Some nodes have accepted a block, but others have rejected it.  The nodes accepting the questionable block keep and extend it.  The nodes rejecting the block neither keep nor extend it, but rather build their own branch.  The resulting "fork" is only visible to nodes which have accepted the questionable block.</p>

<p>However, <a href="https://en.bitcoin.it/wiki/Hardfork" rel="noreferrer">the Wiki</a> has this to say about a hard fork:</p>

<blockquote>
  <p>A hardfork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.</p>
</blockquote>

<p>In other words, a hard fork is a kind of update to Bitcoin Core (given that Bitcoin Core is the protocol).  The idea was repeated in the top answer to <a href="https://bitcoin.stackexchange.com/questions/9173/what-is-a-hard-fork">this SE question</a>.</p>

<p>The difference is subtle, but important.  For example, consider the question: has a hard fork ever occurred?</p>

<p>At least one Core developer says that <a href="http://www.reddit.com/r/Bitcoin/comments/2s2utx/the_hard_fork_missile_crisis/cnlqcd1" rel="noreferrer">Bitcoin has never experienced a hard fork</a>, apparently using the Wiki definition.  The 2013 fork was not caused by a software update (according to some new, but undocumented information), but rather was (caused by?) nondeterministic behavior that would have happened even without the update.</p>

<p>The answer seems to depend on how you define a hard fork. If a hard fork is a condition of the network, the answer seems to be "yes".  But if a hard fork is a kind of software update, the answer seems to be "no".</p>

<p>It's not hard to see how a software update could lead to a persistent block chain fork as seen by some nodes.  So clearly the two ideas are connected.  But imprecise language around hard forks can lead to confusion, and, more importantly, to incorrect conclusions.</p>

<p>So which is it?  Does "hard fork" describe a condition of the network, or a software update?</p>

CC BY-SA 3.0
2016-07-09T22:23:23.000Z
BIP50 since got [updated](https://github.com/bitcoin/bips/commit/072173f3c5290a355e5696b669c3703fcdd47ae3) to remove the term "hard fork".  Since your only source for the "network state" interpretation seems to be that text, maybe that settles it for you?
ZakW
<blockchain-fork><march-2013-fork>
Has a hard fork ever occurred?
Rich Apodaca
# Has a hard fork ever occurred?

(Asked by: username_0 on 2015-02-17)

[BIP 50](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) describes the 2013 event in which a block chain fork persisted for several hours. Its first paragraph reads:

> A block that had a larger number of total transaction inputs than previously seen was mined and broadcast. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected **hard fork of the chain** [my emphasis]. The pre-0.8 incompatible chain at that point had around 60% of the hash power, ensuring that the split did not automatically resolve.

I interpret this to mean that the term "hard fork" describes a state of the network. Some nodes have accepted a block, but others have rejected it. The nodes accepting the questionable block keep and extend it. The nodes rejecting the block neither keep nor extend it, but rather build their own branch. The resulting "fork" is only visible to nodes which have accepted the questionable block.

However, [the Wiki](https://en.bitcoin.it/wiki/Hardfork) has this to say about a hard fork:

> A hardfork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid, and therefore requires all users to upgrade.

In other words, a hard fork is a kind of update to Bitcoin Core (given that Bitcoin Core is the protocol). The idea was repeated in the top answer to [this SE question](https://bitcoin.stackexchange.com/questions/9173/what-is-a-hard-fork).

The difference is subtle, but important. For example, consider the question: has a hard fork ever occurred?

At least one Core developer says that [Bitcoin has never experienced a hard fork](http://www.reddit.com/r/Bitcoin/comments/2s2utx/the_hard_fork_missile_crisis/cnlqcd1), apparently using the Wiki definition. The 2013 fork was not caused by a software update (according to some new, but undocumented information), but rather was (caused by?) nondeterministic behavior that would have happened even without the update.

The answer seems to depend on how you define a hard fork. If a hard fork is a condition of the network, the answer seems to be "yes". But if a hard fork is a kind of software update, the answer seems to be "no".

It's not hard to see how a software update could lead to a persistent block chain fork as seen by some nodes. So clearly the two ideas are connected. But imprecise language around hard forks can lead to confusion, and, more importantly, to incorrect conclusions.

So which is it? Does "hard fork" describe a condition of the network, or a software update?

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

> **Comments:**
> **username_1**: BIP50 since got [updated](https://github.com/bitcoin/bips/commit/072173f3c5290a355e5696b669c3703fcdd47ae3) to remove the term "hard fork".  Since your only source for the "network state" interpretation seems to be that text, maybe that settles it for you?  

---

## 5 answers

### Answer by username_2 on 2015-02-19. Score: 6

> So which is it? Does "hard fork" describe a condition of the network, or a software update?

Either is acceptable. You can say that version so-and-so causes a fork, and you can say that the network is currently forked.

> Was the March 2013 fork a hardfork?

It depends on your definition. The March 2013 incident initially appeared to be a hard-fork, but a later investigation showed that it was possible to trigger the issue even when all nodes were running the same version.

Quoting from [BIP50](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki):

> This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).

However, it was a hardfork in the sense that newer clients would create and validate blocks that an older client would not see as valid.

> **Comments:**
> **username_1**: A little elaboration on how context-sensitive this bug was in practice, from Greg Maxwell: "... not only did only _some_ [0.7.2 nodes] reject [the problem blocks] but they only rejected that particular one when they saw it as part of a reorg."  

---

### Answer by username_3 on 2018-09-24. Score: 1

In addition to the March 2013 bug, the bug introducing CVE-2018-17144 was also a hard fork, even if there was no chain split.

The fix was a soft fork, since it restored the old consensus rules.


---

### Answer by username_4 on 2018-11-23. Score: 0

[2013 Post-mortem](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki#resolution) was an undoubtedly intentional hard fork.

> ### Resolution
>
> On 16 August, 2013 block 252,451 (0x0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) was accepted by the main network, forking unpatched nodes off the network.

Source: [Luke Dashjr](https://twitter.com/LukeDashjr/status/1044984995717279749)


---

### Answer by username_5 on 2018-01-23. Score: 0

To directly answer your question, "Has a hard fork ever occurred?", No.

The 2013 event that you reference was a temporary fork or chain split.

A hard fork would be both the result of deliberate action (as you have quoted) and persistent. If there is no consensus at the point of a hard fork, two distinct forward chains emerge. You may appreciate more information on forks in this response: [link](https://bitcoin.stackexchange.com/a/30821/75001)

> **Comments:**
> **username_3**: A hard fork doesn't need to be deliberate, why do you think that? It is a technical term. CVE-2018-17144 was a hard fork, but it wasn't deliberate.  
> **username_5**: @username_3 A change in the software is not a hard fork. A hard fork is a condition of the blockchain. As it is, unpatched nodes could accept a block outside of what consensus allows but since already it is estimated more than 50% of the Bitcoin hashrate is upgraded there is no realistic probability of a chain split. If anything the situation is more similar to a soft fork and in any case, there is no change to the consensus.  
> **username_3**: As you can see in the question formulation, there are at least two definitions of hard fork.  

---

### Answer by username_6 on 2015-02-19. Score: 0

@username_0, i believe that you may have answered your question somehow, as you pointed out that it was mostly a minor incompatibility of installed versions of bitcoind.

Maybe you will agree with me that hardfork would have to be an incompatibility of design between two versions of the same protocol. Take for instance one altcoin, like FeatherCoin, that abandoned their previous algorithm for Proof of Work to adopt another one, ASIC-resistant, and incompatible with the past one.


---

