neutroncoin/neutron

Client does not sync as expected

collapsedev opened this issue · 3 comments

collapsedev commented

accepted alert 5003, AppliesToMe()=0
ERROR: CheckProofOfStake : check kernel failed on coinstake 7c4757bfe92cf0febe940402e7719c43a1d2f46a78557fb4c581fd7faa983df4, hashProof=00000000000000000
00000000000000000000000000000000000000000000000
AcceptBlock : [WARNING] check proof-of-stake failed for block 750d2c02776c2caf5095965691ddfd23c8e99493f85c5b066dd9815ad7a32116
Misbehaving : [WARNING] *:65036 (0 -> 5, cause: ProcessNewBlock : AcceptBlock for 750d2c02776c2caf5095965691ddfd23c8e99493f85c5b066dd9815ad7
a32116 with parent c0e86aa30e4911ac084748379cf8114c508348c0abbaa5fd85fddc7bb210694c FAILED)
ERROR: ProcessNewBlock : AcceptBlock for 750d2c02776c2caf5095965691ddfd23c8e99493f85c5b066dd9815ad7a32116 with parent c0e86aa30e4911ac084748379cf8114c508348c0abbaa5fd85fddc7bb210694c FAILED

$ neutrond getblockhash 1911486
c0e86aa30e4911ac084748379cf8114c508348c0abbaa5fd85fddc7bb210694c

$ neutrond getinfo
"version": "v3.0.13",
"protocolversion": 60024,

Client gets stuck very often.

adam-waldenberg commented

This is related to the staking protocol. The only fix for this particular bug is to bootstrap the chain. The stored tx database data is causing the POS algorithm to fail. Basically the kernel check is failing.

An update to V2 staking protocol will fix this issue, Neutron is currently using V1.

Closing this, as this one is easily fixable with a bootstrap. We will eventually update to V2 POS, which should stop this from reoccurring.

collapsedev commented

I think with this bypass, invalid block becomes valid after 30 minutes.

        if (POS_HASHCHECK_MAX_BLOCK_AGE > GetTime() - nTimeTx)
            return false;
        else
        {
            LogPrintf("%s : skipping target protocol check on old POS block %d, time=%d "
                      "GetTime()=%d nTimeTx=%d\n", __func__,
                      mapBlockIndex[hashBlockFrom]->nHeight, GetTime() - nTimeTx,
                      GetTime(), nTimeTx);
        }

Distributed database becomes corrupt after some time. All invalid blocks are valid after 30 minutes.
This breaks POS consensus, in this part. The client can not know the correct chain.
The client waits 30 minutes with errors before a new fake sync.
In the other part, This #30 can break consensus and stop a initial download after install bootstrap downloaded from block explorer.
Example:

ConnectBlock() : Masternode list not yet synced or block too old (CountEnabled=68)
ProcessBlock : winner, payee=9ngDXKhHQxrqPKsRJEzUsKVa4Fk7H3rMLY, nBlockHeight=1931462
AddWinningMasternode : new masternode winner has an equal or higher score - replacing
ProcessBlock : winner, payee=9nJH4QScvWhayWw7T52g8L63is7Ryxa5XU, nBlockHeight=1931463
AddWinningMasternode : new masternode winner has an equal or higher score - replacing
ProcessBlock : winner, payee=9nJH4QScvWhayWw7T52g8L63is7Ryxa5XU, nBlockHeight=1931463
AddWinningMasternode : new masternode winner has an equal or higher score - replacing
ProcessBlock : winner, payee=9ngs8SoaQc3VWxWVUzqw6i84DRuRwjHMF8, nBlockHeight=1931464
AddWinningMasternode : new masternode winner has an equal or higher score - replacing
ProcessBlock : winner, payee=9X2bmZFkdtrSXRb9gqjznoLjmJTn4KuC7F, nBlockHeight=1931465
AddWinningMasternode : adding block 1931465
SetBestChain : new best=d89f553c8214c4c98afe height=1931462 trust=315407690829498956238 blocktrust=110685535 date=02/16/20 21:37:35
ConnectBlock() : *Block 1931463 reward=10.68537 - Expected payouts: Stake=3.26972322, Masternode=6.34710978, Project=1.068537
ConnectBlock() : Possible discrepancy found in masternode payment, recalculating payee...
ProcessBlock : winner, payee=9nJH4QScvWhayWw7T52g8L63is7Ryxa5XU, nBlockHeight=1931463
AddWinningMasternode : new masternode winner has an equal or higher score - replacing
ERROR: ConnectBlock() : Stake does not pay correct masternode, actual=9YucHfnuztHpTLDEYCsTM9w1n47FR6uga3 required=9nJH4QScvWhayWw7T52g8L63is7Ryxa5XU, bl
ock=1931463

InvalidChainFound : invalid block=ecfcdaece01442545e90 height=1931463 trust=315407690829579547569 blocktrust=80591331 date=02/16/20 21:41:20
InvalidChainFound : current best=d89f553c8214c4c98afe height=1931462 trust=315407690829498956238 blocktrust=110685535 date=02/16/20 21:37:35
ERROR: SetBestChain : SetBestChainInner failed
ERROR: AcceptBlock() : AddToBlockIndex failed

In this case "Masternode list not yet synced or block too old", does not avoid "Stake does not pay correct masternode".

Centralized bootstrap does not solve the problem.

adam-waldenberg commented

Yes. This is a temporary measure to get around the broken kernel check that occurs causing nodes to get stuck. It will be removed as soon as we have time to switch to POS V2.

And no, #30 is not a problem at all and the log you just pasted is completely normal. We have another check to handle this via spork whenever the list is slightly out of sync or in disageement. The "block too old" check has nothing to do with the masternode consensus, its a temporary measure to get around the problems with the broken POS V1 kernel check and it will be removed.

You should be able to sync up fine if you use the centralized bootstrap and make sure you clear the banlist and seed database before starting up. Considering the blockheight at the time I'm wrtiting this is 1931559, I'm guessing you probably are...