Change default bantime #91

From BTC 0.18 relnotes:

Network
-------

- This release allows peers that your node automatically disconnected
  for misbehavior (e.g. sending invalid data) to reconnect to your node
  if you have unused incoming connection slots.  If your slots fill up,
  a misbehaving node will be disconnected to make room for nodes without
  a history of problems (unless the misbehaving node helps your node in
  some other way, such as by connecting to a part of the Internet from
  which you don't have many other peers).  Previously, Bitcoin Core
  banned the IP addresses of misbehaving peers for a period of time
  (default of 1 day); this was easily circumvented by attackers with
  multiple IP addresses. If you manually ban a peer, such as by using
  the `setban` RPC, all connections from that peer will still be
  rejected.

BTC now has drastically changed their internals of ban management, and keeps track of manual vs automatic bans, and allows automatically banned nodes to reconnect in some situations. This is no doubt because many bans happen to honest nodes which are not attacking, potentially almost all bans are from nodes which are accidentally misbehaving, not attackers. A real attacker can easily just use another IP address, banning nodes for 24hrs mostly hurts honest nodes and basically does nothing against a determined attacker.

Hush currently bans nodes for 24hrs, we should decide on a more reasonable time, somewhere between 2 and 4 hours. For instance, if you are a Hush full node admin, and some issue causes your node to be banned (potentially from the entire rest of the network), the problem is often fixed within a few hours, but you still cannot connect to other nodes for a full day.

Additionally, banning IP addresses doesn't even make good sense when you take into account ISPs often changing residential internet IP addresses. You end up blocking the the IP of an honest person that happens to get that IP next.

Finally, banning IP's for 24hrs allowed for an interesting attack against Bitcoin Tor nodes that goes like this: Say I am an attacker that wants to prevent Bitcoin nodes from submitting transactions via Tor. Then I simply submit invalid transactions via Tor so that every single Tor exit node IP gets banned by the Bitcoin network, which lasts 24hrs. Repeating this once every 24hrs effectively cuts off anybody in the world from submitting transactions via Tor. I believe this is why BTC devs changed the way banning works, and now even has a concept of "discouraged nodes" which is different from "banned nodes".

From the BTC 0.20.1 relnotes:

Changes regarding misbehaving peers
-----------------------------------

Peers that misbehave (e.g. send us invalid blocks) are now referred to as
discouraged nodes in log output, as they're not (and weren't) strictly banned:
incoming connections are still allowed from them, but they're preferred for
eviction.

Furthermore, a few additional changes are introduced to how discouraged
addresses are treated:

- Discouraging an address does not time out automatically after 24 hours
  (or the `-bantime` setting). Depending on traffic from other peers,
  discouragement may time out at an indeterminate time.

- Discouragement is not persisted over restarts.

- There is no method to list discouraged addresses. They are not returned by
  the `listbanned` RPC. That RPC also no longer reports the `ban_reason`
  field, as `"manually added"` is the only remaining option.

- Discouragement cannot be removed with the `setban remove` RPC command.
  If you need to remove a discouragement, you can remove all discouragements by
  stop-starting your node.

From BTC 0.18 relnotes: ``` Network ------- - This release allows peers that your node automatically disconnected for misbehavior (e.g. sending invalid data) to reconnect to your node if you have unused incoming connection slots. If your slots fill up, a misbehaving node will be disconnected to make room for nodes without a history of problems (unless the misbehaving node helps your node in some other way, such as by connecting to a part of the Internet from which you don't have many other peers). Previously, Bitcoin Core banned the IP addresses of misbehaving peers for a period of time (default of 1 day); this was easily circumvented by attackers with multiple IP addresses. If you manually ban a peer, such as by using the `setban` RPC, all connections from that peer will still be rejected. ``` BTC now has drastically changed their internals of ban management, and keeps track of manual vs automatic bans, and allows automatically banned nodes to reconnect in some situations. This is no doubt because many bans happen to honest nodes which are not attacking, potentially almost all bans are from nodes which are accidentally misbehaving, not attackers. A real attacker can easily just use another IP address, banning nodes for 24hrs mostly hurts honest nodes and basically does nothing against a determined attacker. Hush currently bans nodes for 24hrs, we should decide on a more reasonable time, somewhere between 2 and 4 hours. For instance, if you are a Hush full node admin, and some issue causes your node to be banned (potentially from the entire rest of the network), the problem is often fixed within a few hours, but you still cannot connect to other nodes for a full day. Additionally, banning IP addresses doesn't even make good sense when you take into account ISPs often changing residential internet IP addresses. You end up blocking the the IP of an honest person that happens to get that IP next. Finally, banning IP's for 24hrs allowed for an interesting attack against Bitcoin Tor nodes that goes like this: Say I am an attacker that wants to prevent Bitcoin nodes from submitting transactions via Tor. Then I simply submit invalid transactions via Tor so that every single Tor exit node IP gets banned by the Bitcoin network, which lasts 24hrs. Repeating this once every 24hrs effectively cuts off anybody in the world from submitting transactions via Tor. I believe this is why BTC devs changed the way banning works, and now even has a concept of "discouraged nodes" which is different from "banned nodes". From the BTC 0.20.1 relnotes: ``` Changes regarding misbehaving peers ----------------------------------- Peers that misbehave (e.g. send us invalid blocks) are now referred to as discouraged nodes in log output, as they're not (and weren't) strictly banned: incoming connections are still allowed from them, but they're preferred for eviction. Furthermore, a few additional changes are introduced to how discouraged addresses are treated: - Discouraging an address does not time out automatically after 24 hours (or the `-bantime` setting). Depending on traffic from other peers, discouragement may time out at an indeterminate time. - Discouragement is not persisted over restarts. - There is no method to list discouraged addresses. They are not returned by the `listbanned` RPC. That RPC also no longer reports the `ban_reason` field, as `"manually added"` is the only remaining option. - Discouragement cannot be removed with the `setban remove` RPC command. If you need to remove a discouragement, you can remove all discouragements by stop-starting your node. ```

One additional idea I had was this:

We can make "automatic bans" (bans that are done automatically by internals, not by a user calling the setban RPC) use a smaller ban-time, since those can often ban accidentally misconfigured nodes for an entire day. "Manual bans" from the setban RPC would still default to a full day ban, which is more backward-compatible. This is also more in line with the latest behavior of BTC full node banning logic.

We should probably just change the default bantime to 4hrs as an intermediate step. Changing our internals to use "discouraged nodes" instead of banning nodes is a big change