KOMODO_LIMITED_NETWORKSIZE

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.

src/komodo_defs.h

@@ -5,5 +5,6 @@
 #define KOMODO_ELECTION_GAP 2000
 #define ROUNDROBIN_DELAY 61
 #define KOMODO_ASSETCHAIN_MAXLEN 65
+#define KOMODO_LIMITED_NETWORKSIZE 4
 
 #endif

src/main.cpp

@@ -3544,7 +3544,7 @@ CBlockIndex* AddToBlockIndex(const CBlockHeader& block)
     BlockMap::iterator miPrev = mapBlockIndex.find(block.hashPrevBlock);
     if (it != mapBlockIndex.end())
     {
-        if ( vNodes.size() < 4 || it->second != 0 ) // change behavior to allow komodo_ensure to work
+        if ( vNodes.size() < KOMODO_LIMITED_NETWORKSIZE || it->second != 0 ) // change behavior to allow komodo_ensure to work
         {
             // this is the strange case where somehow the hash is in the mapBlockIndex via as yet undetermined process, but the pindex for the hash is not there. Theoretically it is due to processing the block headers, but I have seen it get this case without having received it from the block headers or anywhere else... jl777
             //fprintf(stderr,"addtoblockindex already there %p\n",it->second);
@@ -4155,7 +4155,7 @@ bool ProcessNewBlock(bool from_miner,int32_t height,CValidationState &state, CNo
         }
         // Store to disk
         CBlockIndex *pindex = NULL;
-        if ( vNodes.size() < 4 )
+        if ( vNodes.size() < KOMODO_LIMITED_NETWORKSIZE )
         {
             // without the komodo_ensure call, it is quite possible to get a non-error but null pindex returned from AcceptBlockHeader. In a 2 node network, it will be a long time before that block is reprocessed. Even though restarting makes it rescan, it seems much better to keep the nodes in sync
             komodo_ensure(pblock,hash);

src/miner.cpp

@@ -635,7 +635,7 @@ static bool ProcessBlockFound(CBlock* pblock)
         return error("KomodoMiner: ProcessNewBlock, block not accepted");
     
     TrackMinedBlock(pblock->GetHash());
-    if ( vNodes.size() < 8 )
+    if ( vNodes.size() < KOMODO_LIMITED_NETWORKSIZE*2 )
     {
         int32_t n = 1;
         //fprintf(stderr,"broadcast new block t.%u\n",(uint32_t)time(NULL));