if you are shunned then its forever. If a node shunned you while your node was off then you will never see it.
and if another node didn’t shun you then you won’t see it shunning you since the node is back online
So expected behaviour.
The consequence though is a loss of overall connectivity as now you have nodes that will never talk to your nodes again, and there will be no indication.
Actually I wonder if this is a reason for the network running poorly. People stopping and starting their nodes without the peerid/xor being renewed since its stop/starts or power off/on and causing those nodes to be shunned by long running nodes and only new nodes are talking to them.
On shunning, I am still hoping for clarification on what that means and how to judge node health. So what I’m actually referring to is the count of “bad node” messages appearing in the logs and displayed by vdash.
AFAIK the isn’t a state which can be called shunned. Maybe by a single other node, but collectively not.
So you could actually have a node go from ok, to shunned by almost everyone, but eventually be accepted back due to churn.
Maybe I don’t understand the routing and close groups enough, but here is as I see it.
In my mind simple power/internet glitch or reboot causes lot of shunn which then causes:
Nodes permanently “crippled” even when they are perfect citizens otherwise
Unnecessary lower network resiliency as we ignore nodes we could use for recovery
High global churn rate which degrades network performance
I know shun is bad actor protection, but is the permanency best solution? Imagine big, long running network and perfect node running from the start, how long will be it’s shunn-list? Will it be checking every new connection against list of 1M nodes were bad or had connection problem sometime in history?
Since the last update, through node manager, I have had a maximum of 5 shuns. I did a one time start and stop of nodes, again I see no more than 5 shuns. Before the update I had like 50 shuns of continuous running nodes. Everything seems the be working nicely with nodes from home. Data is flowing through like an easy river, thousands of records coming and going as expected. Only thing not being caught in my net are nanos.
The permanent is not for unintentional bad nodes but intentionally bad nodes. If its not permanent then they can just stick around and attack again.
The obvious reaction of any node if bad is to restart with new peerID and see if that fixes things.
Not good if intentionally bad, but you can do nothing about that
But for the unintentional bad then its way faster than having to wait hours till the shun times out.
It will have to be built into the launcher to do that and I see from the screen shot in news the launcher can determine if the node seems bad and could just kill the node and start a new one
Shunning hasn’t really been defined AFAIK so this is just how I’m using it.
A “bad node” message in the log means another node has a problem with you, but has not necessarily shunned or blacklisted you. (I may be wrong about that, but I think that was the initial implementation).
If enough other nodes “bad message” the same name node they may each decide that’s enough and blacklist it - or not - independently, there’s no formal consensus.
vdash counts received “bad node” messages. It can’t know when the node has been blacklisted or by how many others AFAIK.
As there’s no formal consensus or threshold the term shunned is nebulous, and a node that just sticks around long enough after being completely black listed could come back into the game due to churn, provided it’s behaviour has improved sufficiently.
Much of the above may be out of date or plain wrong. It’s what I’ve gleaned over time from what’s been said by the team.
Yeh, my memory is terrible these days. God knows how I can still write working code etc, I thought I was past it when I came to this project but
BTW, if it isn’t documented, it isn’t defined IMO and without investigating, I can say that there is a commit in the latest release which differentiates between the bad node message and being blacklisted. It implies that previously it wasn’t being sent for blacklisting but prior to that.