Closed bayk closed 2 months ago
We will ban a peer if it claims a higher total work but can't send us the real headers (stale in 120 seconds).
https://github.com/mwcproject/mwc-node/blob/4.3.0/servers/src/grin/sync/header_sync.rs#L137-L153
Before going to other investigations, a first trying could be changing this 120s
to a bigger value, to see whether it will continue receiving headers from the peer before ban it.
I can not reproduce the case of the banning. But the case of repeating receiving same headers from different peers here seems a behavior by the design:
It's reasonable that this node will not switch the header chain because its current chain still wins in its own view. The behavior is correct.
A possible "fix" for this exception case is, if seeing such kind of long fork, the node will request all the remaining headers on one shot, instead of still per-512 headers.
A "benefit" of this "problem" could be a "consensus" of forbidding any reorg longer than 512 blocks (i.e. about 8.5 hours).
@suemto , I am thinking that let's keep it as it is. It is really great that attacker will not be able to do reorg silently by mining privately and then release very long branch. Forbidding any reorg longer than 512 blocks make sense for me.
I will update discord channel with that
Didn't see for a while, closing the issue
Here are what I see at the logs. Node is not able to sync because it ban it's peers.
The node is requesting the same headers in the loop.
(modified with formatting).