Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
net: Allow connections from misbehavior banned peers #14929
This allows incoming connections from peers which are only banned
These peers are preferred for eviction when inbound fills, but may
If they misbehave again they'll still get disconnected.
The main purpose of banning on misbehavior is to prevent our
A secondary purpose was to reduce resource waste from repeated
This can reduce the potential from negative impact due to incorrect misbehaviour bans.
4 times, most recently
Dec 12, 2018
Perhaps we should go further and not bother disconnecting inbound peers who misbehave, and just increase their likelihood of eviction? One of the changes I've been meaning to propose is to not disconnect inbound peers for relaying an invalid block or header, so that in the event of a future softfork, old peers don't get disconnected for not knowing about the new rules (which risks network partition).
The only benefit to disconnecting that I can think of is if we're using disconnection as a rate limit on the bad behavior itself -- but that seems like a poor remedy for limiting a determined adversary that we assume has access to an ~infinite IP range.
On further thought: this seems like it would be a more involved change to make than I realized (with all the associated testing changes), so we can postpone discussion to a separate PR.
@sdaftuar I think in the long run we should move in that direction, but it's a bigger change that requires more careful consideration.
Consider: disconnecting on an invalid block / header also potentially helps protect the peer when we're the one that is in the wrong (e.g. rejecting blocks due to corrupt state). Not a reason to not do it, but perhaps it's a reason to be first really confident that our outbound management of consensus rule incompatibilities is really good. Likewise, we might want to implement more holistic rate limiting or prioritized message processing (e.g. queue messages from peers, handle messages from helpful, outbound, peers first).
My only observation from testing is that the interaction between whitelisting and m_prefer_evict is not entirely obvious, but I think this is mostly due to the pre-existing not-well-defined behavior of whitelisting (for instance, I think a whitelisted peer should probably be exempt from eviction, which if I read correctly is not currently the case? But instead after this PR a peer could conceivably be whitelisted and have the prefer_evict flag set -- though that would only be in a strange situation where a such a peer received an automatic misbehavior ban prior to being whitelisted).
@sdaftuar pre-existing code unconditionally exempts whitelisted peers from consideration for eviction: https://github.com/bitcoin/bitcoin/blob/006a07de4e5c3de36ef84d186315a4a5f23da158/src/net.cpp#L1025
I think the remaining interaction isn't that weird, like if a peer gets eviction pref then gets whitelisted it won't get evicted while whitelisted, but if the whitelisting is removed, the remaining pref will still apply.