This is the 3rd time that I can remember this happening. Does anyone know why they get it every time?
I've updated the web info.
Looks like I also need to work on the orphan detection code, it does a pretty simple check that seems to not spot it well.
I really never expected to get orphans very often, so it wasn't something I cared too much about, but I guess I should make a few changes there and make it automatically detect them better.
Since now we get around 100 blocks a month, we can of course expect to get more orphans.
The last orphan was 96 blocks ago, so another one now is not really statistically unexpected.
The run down of what happened:
UTC
2016-05-04 15:29:16.334 - eu relay sent BTCC block to the DE node ...0000234618ae...
2016-05-04 15:29:16.341 - we got the block from the miner ...00003e16d314...
2016-05-04 15:29:16.564 - our main bitcoind accepted our block
2016-05-04 15:29:16.647 - us-east relay got our block
2016-05-04 15:29:16.653 - us-west relay got our block
2016-05-04 15:29:17.271 - us-east relay sent BTCC block to us
2016-05-04 15:29:17.281 - us-west relay sent our block back to us
2016-05-04 15:29:17.715 - us-west relay sent BTCC block to us
2016-05-04 15:29:17.854 - eu relay sent our block to the DE node
2016-05-04 15:29:18.136 - us-east relay sent our block back to us
Really only the first 2 lines are needed to explain it all though.
So unfortunately for our block, there was really no 'expectation' to win since our block was actually 7milliseconds after one of our nodes first knew about the BTCC block
A double block would of course made us win, but in this case, while obviously all of 'GFW' was already working on BTCC's block, already some outside GFW would have been working on the BTCC block also.
The next block was by f2pool, so of course, due to the BTCC block actually being just before our block, that meant they confirmed the BTCC block.