DragonX/hush3
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Test

Browse Source
This commit is contained in:
jl777
2018-04-21 15:16:44 +03:00
parent a36c1a705a
commit 64b45b7192
2 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/main.cpp
View File

@@ -3551,7 +3551,7 @@ CBlockIndex* AddToBlockIndex(const CBlockHeader& block)
if (it != mapBlockIndex.end())
{
//if ( ASSETCHAINS_STAKED == 0 || 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
if ( it->second != 0 ) // vNodes.size() >= KOMODO_LIMITED_NETWORKSIZE, 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);
@@ -4162,7 +4162,7 @@ bool ProcessNewBlock(bool from_miner,int32_t height,CValidationState &state, CNo
}
// Store to disk
CBlockIndex *pindex = NULL;
if ( vNodes.size() < KOMODO_LIMITED_NETWORKSIZE ) //ASSETCHAINS_STAKED != 0 )//
//if ( vNodes.size() < KOMODO_LIMITED_NETWORKSIZE ) //ASSETCHAINS_STAKED != 0 )//
{
// 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);