Quote from: ComputerGenie on June 17, 2017, 08:54:06 PM

Quote from: sonic90046 on June 17, 2017, 08:31:39 PM

@genie
You are saying there's an error in the algo? Or the pools?

15+% orphaned blocks indicate error in algo...but should be "patch-able"?

Just trying to understand.

The issue is not the pools otherwise it wouldn't be all throughout the network with several different types of pool servers having the exact same issue.
The issue seems to be that the wallet ignores consensus in that, anytime a block is sent out with a timestamp older than the most currently accepted block, the entire chain gets orphaned to the point where that block would have been the "next block" and only blocks built on that one are then considered valid.

An overly simplified example would be....

The current chain is:
Block AAAAAB - timestamp 9:15:02
Block AAAAAC - timestamp 9:15:06
Block AAAAAD - timestamp 9:16:02
Block AAAAAE - timestamp 9:16:32
Block AAAAAF - timestamp 9:17:15
Block AAAAAG - timestamp 9:17:27
Block AAAAAH - timestamp 9:17:43

And there exists a previously unaccepted:
Block AAAABA - timestamp 9:15:04 (built upon AAAAAB)

When AAAABA gets broadcast to enough nodes, the fact that 6 blocks have been built upon AAAAAB (and rendered valid by consensus) becomes irrelevant, blocks AAAAAC through AAAAAH get orphaned and the new chain becomes:
Block AAAAAB - timestamp 9:15:02
Block AAAABA - timestamp 9:15:04
Block AAAABB - the next block the network is working on.

It creates "nice" doublespend attack opportunities for anyone using a merchant that uses less than 7 confirmations (fact, not FUD). Undecided

If this is what is happening, there is a basic coding error somwhere. Longest chain is supposed to win. One latecomer block should not possibly invalidate a longer 6 block prong.