I don't know if this is that simple to fix. I was perusing the blockchain. It seems to be that block 411228 is that block that caused the problem - it seems that the time on the wallet client was ahead by about 1 hr, which doesn't seem possible because usually the clients do time checks with each other when receiving block version messages (cannot really say for Orbit client, but does happen for other clients). Then the next block 411229 came from a client that was on the correct time, but due to this negative time, the difficulty changes dramatically.
Block 411225 December 30, 2013, 7:55 pm Diff 0.1701947
Block 411226 December 30, 2013, 7:56 pm Diff 0.17276514
Block 411227 December 30, 2013, 7:56 pm Diff 0.17286038
Block 411228 December 30, 2013, 8:56 pm Diff 0.17353002
Block 411229 December 30, 2013, 7:58 pm Diff 0.05879355
Block 411230 December 30, 2013, 8:07 pm Diff 0.00024414 Zero block nonce
Difficulty is increasing normally, so looks like single block difficulty retarget, but 411228 is reported by a client at 8:56 pm, so it looks like the mining power disappeared, but in fact it hadn't - however due to the long time between blocks, the difficulty is lowered. Block 411229 comes along - now here is the interesting thing - the block time should have been checked and rejected because it came before the last block time, but it is allowed to be incorporated into the blockchain. After that is when the block nonce is zero for future blocks - something else that needs to be looked at.
Ok, so it appears that there might be several different occurrences. One is the difficulty retarget due to an incorrect time client (maybe malicious). Second is allowing a block to occur before the previous block (again - it could be that someone has hacked the client to remove this restriction to allow it to occur, or maybe just an oversight in the client code). Third is this zero nonce - that I don't understand as yet, but must be causing a problem.
I looked at the blocks using the Orbitcoin Block Crawler
https://andarazoroflove.org/explorer/orbitcoin/block_crawler.phpNow the developer would need to look at this issue, maybe we have to remove 411228 from the blockchain or cause a hard fork to occur. The current block appears to be 411512 so we are not looking at a lot of coins, but there will be lots of transactions that have confirmed and now - what happens to them!
Patching the client is another thing - it looks like two (or more) things, the retarget problem, and the block time problem - then examine the zero nonce and see how that is happening. The dev is saying that it is an attack on the coin and doesn't think the retarget change is needed - and he could be right, however the block time problem would allow the blockchain to continue, i.e. reject finding of blocks until the actual time catches up with the bad block time - but I think both is needed. What happens if a client was 1 year ahead and reported a block - that would stop blocks from being mined for a year, not acceptable. Then confirm that the clients does check time sync so that we avoid the issue of a client with the wrong time, i.e. not accept blocks from clients where the times do not within reasonable limits.
Anyway, my ten cents worth - I don't mine or trade Orbitcoin, but I was researching it with a view to mine, but then found out about this issue.
