I removed .grin and after a couple of hours running latest testnet1 code, I'm seeing " 1 / 4 / 320" peers, can't get any more good ones and ping/pong lines show 0 @ 0 vs us 135 645 922 @ 15032 and a single node stuck at 35 432 595 @ 0
Meanwhile, gitter chat talks about seeing >8 healthy peers and grinexplorer is at 138 194 082 @ 20429 so my node is clearly behind, just can't find the healthy nodes. Maybe because I'm only talking to nodes already banned by the more long-running healthy ones. Either way, exposing the grin explorer list of known good nodes in a best-effort way could be very helpful.
Maybe format it like grin server -s $IP:$PORT start.
Note: It seems multiple server start commands won't work without stopping your grin server in between, so the instruction should be: stop grin, then grin server ... and it's not very automation-friendly yet. Maybe https://github.com/mimblewimble/grin/issues/218 will mean adding a feature that accepts an ip:port that gets queued up to be asked for peers, and that could be used for reviving a stuck node like mine currently is (at height 15xxx for hours and hours).
I removed .grin and after a couple of hours running latest testnet1 code, I'm seeing " 1 / 4 / 320" peers, can't get any more good ones and ping/pong lines show
0 @ 0 vs us 135 645 922 @ 15032and a single node stuck at35 432 595 @ 0Meanwhile, gitter chat talks about seeing >8 healthy peers and grinexplorer is at 138 194 082 @ 20429 so my node is clearly behind, just can't find the healthy nodes. Maybe because I'm only talking to nodes already banned by the more long-running healthy ones. Either way, exposing the grin explorer list of known good nodes in a best-effort way could be very helpful.
Maybe format it like
grin server -s $IP:$PORT start.Note: It seems multiple
server startcommands won't work without stopping your grin server in between, so the instruction should be: stop grin, thengrin server ...and it's not very automation-friendly yet. Maybe https://github.com/mimblewimble/grin/issues/218 will mean adding a feature that accepts an ip:port that gets queued up to be asked for peers, and that could be used for reviving a stuck node like mine currently is (at height 15xxx for hours and hours).