<p>Short answer: 4 [Prior to the <a href="http://bitcoin.org/chainfork.html" rel="noreferrer">March 12, 2013</a> fork]</p>

<p>The Value Overflow incident seems to be the longest ever blockchain split. The problem with blockchain forks is that once they are resolved the only trace they leave is a log entry.</p>

<p>To reconstruct the following I used the printblocktree output that theymos gave me in <a href="https://bitcoin.stackexchange.com/questions/4135/getting-orphaned-blocks-from-the-blockchain">this question</a> and the information from <a href="http://blockchain.info/orphaned-blocks" rel="noreferrer">Blockchain.info</a>.</p>

<p>As far as I can see from the <a href="https://gist.github.com/3635514" rel="noreferrer">printblocktree</a> there have been 90 blockchain forks observed by theymos in the blockchainrange [90392-189512].
This dataset has the following forks:</p>

<ul>
<li>1x block length 4 (starting from block 174161)</li>
<li>1x block length 3 (starting from block 174120)</li>
<li>4x block length 2 (starting from blocks 93669, 174233, 179217 and 179639)</li>
<li>87x block length 1 (starting from blocks 90392, 90676, 90858, 91405, 92094, 93047, 93088, 93619, 93642, 93669, 93670, 93671, 93855, 94671, 98529, 99365, 100740, 101902, 102674, 105401, 109912, 117103, 118553, 120406, 123583, 128501, 130077, 130200, 155180, 157929, 161673, 162257, 163959, 165439, 165519, 166890, 167283, 167620, 167742, 167863, 168920, 169517, 171064, 173494, 174102, 174104, 174121, 174174, 174182, 174185, 174187, 174232, 174242, 174291, 174307, 174313, 174330, 174343, 174414, 174452, 174531, 174593, 174605, 175998, 176210, 176478, 177854, 178119, 178293, 179791, 179890, 180143, 181230, 181591, 181618, 182210, 182321, 183193, 183405, 183500, 183519, 184932, 186561, 187866, 188347, 188682 and 189512)</li>
</ul>

<p>Blockchain.info does have quite a few more orphans in their database, apparently because they connect to a lot more nodes, but their history does not go back as far as theymos' printblocktree.
The first blockchain fork that bitcoin.info observed was based on block 142257 since then we observed 540 forks:</p>

<ul>
<li>2x block length 4 (starting from blocks 174161 and 173927)</li>
<li>4x block length 3 (starting from blocks 174120, 174056, 174050 and 173956)</li>
<li>14x block length 2 (starting from blocks 183873, 179639, 179217, 176924, 175847, 175226, 174233, 174093, 173988, 173985, 173691, 170059, 165518 and 155180)</li>
<li>520x block length 1 (far too many to put them here...)</li>
</ul>

<p>The problem is quite evident: while both see forks, theymos' set has a smaller view of the network and misses or misinterprets forks (the one starting from 155180 is marked as a length 1 fork in the first results and as a length 2 in the second). We cannot be sure that blockchain.info catches all of the forks but we can be pretty certain that there was no fork longer than 4, as the fork would survive longer and would be seen by more nodes.</p>

CC BY-SA 3.0
2012-09-05T13:21:32.130Z
2013-03-12T05:13:58.413Z
2017-04-13T12:47:33.660Z
cdecker
<p>The <a href="http://bitcoin.org/chainfork.html">March 12, 2013 blockchain fork</a> started with 225430 and so far has reached block 225461, so it is 31 blocks long.  Some of those were mined long after the fork supported by v0.7 clients had regained longest chain.  At the peak the fork which supported by v0.8 clients was at least a dozen blocks higher meaning transactions that had more than ten confirmations could then have been reverted to unconfirmed status (and if double spent, ignored as if the transaction had never been made.</p>

CC BY-SA 3.0
2013-03-12T06:25:47.530Z
As of the time when the fork caught up, it was 25 blocks, from 225430 to 225454.  The last block took over 2 hours, so there may or may not be another one as miners finally abandon it.
nealmcb
CC BY-SA 3.0
2013-03-12T05:19:19.043Z
2013-04-01T16:37:16.117Z
2013-04-01T16:37:16.117Z
Stephen Gornick
<p>The <a href="https://www.blockchain.com/charts/n-orphaned-blocks" rel="noreferrer">orphaned blocks view</a> from BlockChain.info shows a recent fork of the blockchain (starting with block 173,928) that went four blocks long before being orphaned.</p>
<p>Other than the controlled rewind following the <a href="https://en.bitcoin.it/wiki/Incidents#Value_overflow" rel="noreferrer">Value Overflow bug</a> in August 2010 in which 53 blocks were orphaned, is there a fork of blocks orphaned as long or longer than this one that occurred at 173,928?</p>

CC BY-SA 3.0
2014-05-22T09:38:28.170Z
It might be due to a pool on purpose trying to build on their own chain, because they could gain several rewards at once by getting a lucky additional quick block. It is a known "selfish mining" strategy to keep building off your own chain as long as it is not too far behind.
Murch
CC BY-SA 3.0
2012-04-03T05:50:37.037Z
Wow. Those are a lot of orphaned blocks. Why is this happening? Lack of communication between the miners?
Thilo
CC BY-SA 3.0
2012-04-08T20:45:38.010Z
@Thilo: No, you frequently have situations where more than one block has been generated and are now competing to become part of the primary chain, usually whichever one is heard by the network first wins; except, due to the size and latency of the network, you sometimes have one side saying theirs was first and the other side saying theirs was... but then you can have descendants of either of those blocks also go head to head, and then another one on top of that, eventually one side out mines the other. 4 sounds rather high, though.
Diablo-D3
CC BY-SA 3.0
2012-04-08T23:55:14.043Z
@Diablo-D3: I can see that sometimes happening, but so frequently? There are minutes between the creation of those competing blocks. That cannot be network latency, can it?
Thilo
CC BY-SA 3.0
2012-04-10T09:51:09.330Z
@Thilo: Yup, network latency. Sometimes a block just has to make quite a few hops to get to the other side. Like I said, I also find it strange it can happen 4 times in a row to preserve the chains that far. It almost sounds like the process is being enhanced by post-P2SH blocks mined by pre-P2SH miners (thus broken P2SH tx) continuing to be extended by pre-P2SH miners.
Diablo-D3
<blockchain-fork><history><chain-reorganization><stale-block>
What is the longest blockchain fork that has been orphaned to date?
Stephen Gornick
# What is the longest blockchain fork that has been orphaned to date?

(Asked by: username_0 on 2012-04-02)

The [orphaned blocks view](https://www.blockchain.com/charts/n-orphaned-blocks) from BlockChain.info shows a recent fork of the blockchain (starting with block 173,928) that went four blocks long before being orphaned.

Other than the controlled rewind following the [Value Overflow bug](https://en.bitcoin.it/wiki/Incidents#Value_overflow) in August 2010 in which 53 blocks were orphaned, is there a fork of blocks orphaned as long or longer than this one that occurred at 173,928?

**Tags:** blockchain-fork, history, chain-reorganization, stale-block

> **Comments:**
> **username_2**: Wow. Those are a lot of orphaned blocks. Why is this happening? Lack of communication between the miners?  
> **username_3**: @username_2: No, you frequently have situations where more than one block has been generated and are now competing to become part of the primary chain, usually whichever one is heard by the network first wins; except, due to the size and latency of the network, you sometimes have one side saying theirs was first and the other side saying theirs was... but then you can have descendants of either of those blocks also go head to head, and then another one on top of that, eventually one side out mines the other. 4 sounds rather high, though.  
> **username_2**: @username_3: I can see that sometimes happening, but so frequently? There are minutes between the creation of those competing blocks. That cannot be network latency, can it?  
> **username_3**: @username_2: Yup, network latency. Sometimes a block just has to make quite a few hops to get to the other side. Like I said, I also find it strange it can happen 4 times in a row to preserve the chains that far. It almost sounds like the process is being enhanced by post-P2SH blocks mined by pre-P2SH miners (thus broken P2SH tx) continuing to be extended by pre-P2SH miners.  
> **username_1**: It might be due to a pool on purpose trying to build on their own chain, because they could gain several rewards at once by getting a lucky additional quick block. It is a known "selfish mining" strategy to keep building off your own chain as long as it is not too far behind.  

---

## 2 answers

### Answer by username_0 on 2013-03-12. Score: 17 | Accepted answer

The [March 12, 2013 blockchain fork](http://bitcoin.org/chainfork.html) started with 225430 and so far has reached block 225461, so it is 31 blocks long. Some of those were mined long after the fork supported by v0.7 clients had regained longest chain. At the peak the fork which supported by v0.8 clients was at least a dozen blocks higher meaning transactions that had more than ten confirmations could then have been reverted to unconfirmed status (and if double spent, ignored as if the transaction had never been made.

> **Comments:**
> **username_5**: As of the time when the fork caught up, it was 25 blocks, from 225430 to 225454.  The last block took over 2 hours, so there may or may not be another one as miners finally abandon it.  

---

### Answer by username_4 on 2012-09-05. Score: 25

Short answer: 4 [Prior to the [March 12, 2013](http://bitcoin.org/chainfork.html) fork]

The Value Overflow incident seems to be the longest ever blockchain split. The problem with blockchain forks is that once they are resolved the only trace they leave is a log entry.

To reconstruct the following I used the printblocktree output that theymos gave me in [this question](https://bitcoin.stackexchange.com/questions/4135/getting-orphaned-blocks-from-the-blockchain) and the information from [Blockchain.info](http://blockchain.info/orphaned-blocks).

As far as I can see from the [printblocktree](https://gist.github.com/3635514) there have been 90 blockchain forks observed by theymos in the blockchainrange [90392-189512].
This dataset has the following forks:

* 1x block length 4 (starting from block 174161)
* 1x block length 3 (starting from block 174120)
* 4x block length 2 (starting from blocks 93669, 174233, 179217 and 179639)
* 87x block length 1 (starting from blocks 90392, 90676, 90858, 91405, 92094, 93047, 93088, 93619, 93642, 93669, 93670, 93671, 93855, 94671, 98529, 99365, 100740, 101902, 102674, 105401, 109912, 117103, 118553, 120406, 123583, 128501, 130077, 130200, 155180, 157929, 161673, 162257, 163959, 165439, 165519, 166890, 167283, 167620, 167742, 167863, 168920, 169517, 171064, 173494, 174102, 174104, 174121, 174174, 174182, 174185, 174187, 174232, 174242, 174291, 174307, 174313, 174330, 174343, 174414, 174452, 174531, 174593, 174605, 175998, 176210, 176478, 177854, 178119, 178293, 179791, 179890, 180143, 181230, 181591, 181618, 182210, 182321, 183193, 183405, 183500, 183519, 184932, 186561, 187866, 188347, 188682 and 189512)

Blockchain.info does have quite a few more orphans in their database, apparently because they connect to a lot more nodes, but their history does not go back as far as theymos' printblocktree.
The first blockchain fork that bitcoin.info observed was based on block 142257 since then we observed 540 forks:

* 2x block length 4 (starting from blocks 174161 and 173927)
* 4x block length 3 (starting from blocks 174120, 174056, 174050 and 173956)
* 14x block length 2 (starting from blocks 183873, 179639, 179217, 176924, 175847, 175226, 174233, 174093, 173988, 173985, 173691, 170059, 165518 and 155180)
* 520x block length 1 (far too many to put them here...)

The problem is quite evident: while both see forks, theymos' set has a smaller view of the network and misses or misinterprets forks (the one starting from 155180 is marked as a length 1 fork in the first results and as a length 2 in the second). We cannot be sure that blockchain.info catches all of the forks but we can be pretty certain that there was no fork longer than 4, as the fork would survive longer and would be seen by more nodes.


---

