You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 mimblewimble/grin#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).
The text was updated successfully, but these errors were encountered:
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 at35 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, thengrin server ...
and it's not very automation-friendly yet. Maybe mimblewimble/grin#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).The text was updated successfully, but these errors were encountered: