In order to speed up block propagation, it is possible for some blocks
to arrive out of order due to propagation delays combined with 2 or
more blocks mined very quickly.
Additionally futurestamping blocks allows a high hash rate miner to
produce blocks that would be valid after a passage of time.
Previously such blocks triggered an extreme response that banned the
peer that broadcast it. Since these are temporary issues, if the block
is still valid when it is within the allowed timestamp window, this
update will process it normally.
Prior commits relate to supporting a limited size network.
It looks like there is an edge case where it is possible for a hash to
be in the mapIndex, without a pindex. If a block with such a hash is
tried to be Accepted, the AcceptBlockHeader returns true but with a
null pindex, and AcceptBlock fails.
The code says that this indicates that the hash was added from a
blockheader without a block, but I didn’t see that happening. In any
case, it happens a lot on a 2 node network. So much so that if one node
is just mining, before too long the other node will not accept the
block and once that happens, no subsequent block would work as the
prior block is missing.
Of course, with more nodes, these blocks will be around a lot more and
likely it won’t be such an issue, but not so sure that it doesn’t
require restarting the node to get it back on track again.
These prior commits implement a KOMODO_LIMITED_NETWORKSIZE logic where
if it sees that a block has come in which is in the mapIndex but has no
pindex, it automatically addtoblockindex.
There is one edge case still left where both the current block being
processed and its previous block are in this limbo state. Since the
pindex is not mapped to the block, it is problematic to retrieve the
CBlock for the pprev and without the valid pprev the pindex will have a
null pprev and no nHeight set. It is possible that all the other code
will properly deal with such a case and automatically fix it, but
rather than rely on that, in such a case the automatic addtoblockindex
is not done.
A node in such a state would need to exit and restart or somehow fill
in the data from other nodes.
From what I can tell, the above is the main reason why the PoS/PoW
networks were having problems staying in sync. Since even with one
mining node, it was just a matter of time before the other node got
stuck, with more than one mining node we end up with independent forks
that won’t reconcile until the node is restarted.
jl777