Node regulary stuck on a certain block and/or no peers

Tech Support
1

Some feedback, running a node for ~2 months now
latest release, compiled for my machine.

At the moment my node is stuck at block 326370, this happened a lot in the past and i have to delete chain_data and start from scratch again -.- this sucks…
log says (since hours):
20190831 13:27:53.585 INFO grin_chain::chain - Rejected block 0000006736fd at 326371: Error { inner: Invalid Root }

so i guess i’ll have to start all over again

Another common problem i face with running a node is that my peer count drops to 0, which is annoying but not that bad. i just rm -rf peer/* and start the node again…

Also: pls clarify why i have to opt-in to run a full archive node?:
#run the node in "full archive" mode (default is fast-sync, pruned node) archive_mode = false

top also tells me grin is using all my CPU resources while stuck on a certain block, i have given grin a higher priority on this machine because it’s sole purpose is to be a full grin node :slight_smile: renice -n -10 -p PID

2

At the moment my node is stuck at block 326370, this happened a lot in the past and i have to delete chain_data and start from scratch again -.- this sucks…
log says (since hours):
20190831 13:27:53.585 INFO grin_chain::chain - Rejected block 0000006736fd at 326371: Error { inner: Invalid Root }

It was fixed recently, see Fix invalid root by antiochp · Pull Request #3005 · mimblewimble/grin · GitHub

Another common problem i face with running a node is that my peer count drops to 0, which is annoying but not that bad. i just rm -rf peer/* and start the node again…

Make sure node is reachable from the outside, that should help.

Also: pls clarify why i have to opt-in to run a full archive node?:

Emphasis on ‘archive’. By default everyone is running a full node (validates the whole state). Archive nodes just never delete full blocks from their db, while regular nodes will delete them after a certain period. Since full blocks are not required to do a chain state validation, it makes sense to delete old ones to save some space.

1 Like
3

Epic, thx! Will recompile and set the “archive” again to false. IMO the naming convention is improvable :slight_smile:
P.S. My node is reachable and on a reliable unmetered 100Mbps connection.

Edit: Regarding the archive node. When a new node wants to join the network it needs old pruned blockdata, don’t they? So it actually benefits bootstrapping nodes if i have archive set to true?!

4

A new node needs:

  • block headers
  • kernel set
  • utxo set

Regular nodes have all of this information, we don’t need the full blocks

1 Like
5

The reason blocks are needed in traditional chains is to verify the validity of the UTXOs which is done by tracing them back to their coinbase transactions. With Mimblewimble, the verification is instead done with the kernels.

6

I know about block headers and the utxo set and i know about scripts (which aren’t part of grin) but tell me more about kernels and how a new node joining the network bootstraps. merci bien :kissing_heart:

edit: So … i tried to wrap my head around the init process … a new node downloads ~350MB of the last chain state (is this just a agreed upon magic number? x last blocks…? or is this the UTXO + Kernel size atm?) and knows nothing about the past. a “archive” node saves blocks from where it joined and doesn’t prune new blocks, arguable not useful at all, so why is this option available anyway :confused: .
A kernel seems to be containing all information (pubKey, sig, fee) from all participants in the same tx to (magic math i don’t looked into) have the property of a 1 in 1out TX, am i right so far? thx!

7

newest git pull, stuck on 327935.
same message:

Invalid Root }
20190902 09:17:55.760 INFO grin_chain::chain - Rejected block 000000dbce95 at 327936: Error { inner: 

Invalid Root }

deleted whole ./grin besides wallet_data and try to resync now
edit: Working fine now :slight_smile: THX