The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

No conflicts as of last run.

Would it make sense to instead offer this feature as an extension of the banning functionality (through setban / listbanned RPCs). That way it'd be runtime-configurable, get expiration, and the ability to export/import banlist.json files.

Would it make sense to instead offer this feature as an extension of the banning functionality (through setban / listbanned RPCs). That way it'd be runtime-configurable, get expiration, and the ability to export/import banlist.json files.

I'm testing different approaches and I think makes sense to expand banlist (I think i've a branch with some work about it), gonna change it.

Apparently I even opened an issue about that once: #19129

@sipa, adding it to the ban stuff would not work for only inbound connections I guess. If I set a ban based on AS, maybe all my connections with them would be affected, wouldn't it? This approach is more like to avoid any inbound, but not affecting me to connect to any of them.

@brunoerg Why would you only want to avoid inbound? And if so, maybe that's generally useful as a feature for banmap?

Why would you only want to avoid inbound?

An example: an attacker is using AWS to create multiple nodes and connect with me, I want to avoid it. However, it doesn't mean all the nodes from there are malicious, even I can have another node hosted there.

@brunoerg For that I think it suffices to just have an asmap loaded that treats all or most of AWS as the same ASN (which I believe is the case). The inbound connection logic already prioritizes connections from diverse networks (evicting connections from groups with many networks if a new incoming connection appears from a different one).

Still, it doesn't seem unreasonable to have a way to just ban for just inbound connections, but I feel like that applies equally to other IP ranges, so perhaps it is better to add that as an orthogonal feature to banman?

I think this feature should be called something like -ban-as rather than -avoidas, as the functionality is similar to IP banning. The word "avoid" doesn't give that connotation and needlessly introduces a new term for users to understand.

Closing it for now. I agree on moving it to ban, will work on it.