Hi, Can you please take the time to explain what these log entries mean and how important they are to mining? I hae been mining for 4 or 5 months I guess with no reward so I am trying to determine what the issue may be. Thanks
From the logs…
Can we ignore anything with [INFO] ?
If not…
What do we need to be concerned with (for example)?
[INFO ]e m GID 151, Error handling msg: receive invalid block hash height 3021804 instead of 3021376
Answer: Your node received a new block proposal of height 3021804 from broadcast, but your node current height is 3021376.
Which one is correct depend on the network major consensus.
What are these WARNINGS? Are they important?
[WARN ]e[m GID 638, Remote node XXX.XXX.XXX.XXX:30001 stops because of error: Node with id
What are these errors?
[WARN ]e[m GID 799, Decrypt message from XXX.XXX.XXX.XXX:56828 error: cannot decrypt message: no shared key yet
[WARN ]e[m GID 1185, Remote node XXX.XXX.XXX.XXX:58972 stops because of error: Node with id
[WARN ]e[m GID 378, Decrypt message from XXX.XXX.XXX.XXX:57508 error: cannot decrypt message: no shared key yet
Answer: NKN network is encrypted communicate between neighbors. Node will verify
its neighbor’s ID:pubkey pair in ledger, and exchanged share-key before start P2P communicate.
*These errors means that your node met something wrong during handshake with several neighbors. *
*1. Doesn’t mind these errors with few neighbors if your node communicate with most of neighbors are normal. *
2. But if your node can not connect to most of neighbors, maybe your node met network issue.
[WARN ]e[m GID 175, Handle proposal error: wait for proposal timeout
Answer: Not received any block proposal during 20 seconds block duration.
[WARN ]e m GID 151, Receive block hash error when receive vote: receive invalid block hash height 3021842 instead of 3021841
Answer: Same as above mentioned. But the current height changed from 3021376 to 3021841 in short-time, maybe your node in syncing state.
What are these ERRORS? Are they important?
[ERROR]e[m GID 1, ocsp: error from server: unauthorized
[ERROR]e[m GID 87, create new certManager err: invalid character ‘\x00’ looking for beginning of value
Answer: OCSP(Online Certificate Status Protocol) is part of TLS protocol. certManager is the manager of Certificate. These errors means apply certificate failed during apply for x-x-x-x.ipv4.nknlabs.io. These only influenced 30004(tlsWebsocketPort) and 30005(tlsJsonRpcPort) port.
[ERROR]e m GID 386, Update finger table error: Wait for reply timeout
[ERROR]e m GID 177, Request block XXXXXXXXXXX error: Remote node has stopped
[ERROR]e m GID 12893, process relay message error: uint256 bytes wrong size 0, expecting 32
[ERROR]e m GID 319, Update successors error: Wait for reply timeout
[ERROR]e m GID 321, Find predecessors error: Wait for reply timeout
Answer: Wait for reply timeout or Remote node has stopped usually means one of your neighbor offline just now.
[ERROR]e m GID 22812, Pin sigchain error: sigchain element with hash XXXXXXXX not found
[ERROR]e m GID 156, Handle remote message error: Remote node has stopped
[ERROR]e m GID 177, Request block XXXXXXXX error: proposal fails to pass hard timestamp check: block timestamp 1630049290 exceed my tolerance 1630049357, 1630049376]
Answer: Your node received a new block proposal which signed at timestamp: 1630049290(2021-08-27 07:28:10 UTC), but current timestamp of your node was 1630049367±10s*(2021-08-27 07:29:27 UTC) already.*
Probably that’s why your nodes mining 4 or 5 months but no rewards —— your system clock digress from world clock too much(±10 second). Even your node got a right for new a block proposal, its proposal will be rejected yet by almost all others nodes due to block’s timestamp incorrect.
Suggest enable NTP service on your mining nodes for clock calibration.
[ERROR]e m GID 156, Handle remote message error: Remote node has stopped
[ERROR]e m GID 177, Request block XXXXXXX error: Wait for reply timeout