56

The orphaned blocks view 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 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?

Improve this question
6
  • 1
    Wow. Those are a lot of orphaned blocks. Why is this happening? Lack of communication between the miners?
    – Thilo
    Commented Apr 3, 2012 at 5:50
  • 1
    I can't say for absolute certain but I think 4 is the longest split since 2010. Probably due to the recent protocol changes.
    – user418
    Commented Apr 3, 2012 at 9:47
  • 1
    @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
    Commented Apr 8, 2012 at 20:45
  • @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
    Commented Apr 8, 2012 at 23:55
  • @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
    Commented Apr 10, 2012 at 9:51

2 Answers 2

Reset to default
25

Short answer: 4 [Prior to the March 12, 2013 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 and the information from Blockchain.info.

As far as I can see from the printblocktree 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.

Improve this answer
17

The March 12, 2013 blockchain fork 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.

Improve this answer
1
  • 2
    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
    Commented Mar 12, 2013 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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