If whitelist option is used, any previously banned nodes that match the whitelist should be unbanned upon restart #9562

Issue

I was running node version 0.13.2 (official binary package Linux 64 bit) that had banned a IPv4 address, e.g. 1.2.3.4 I wanted to whitelist that address, so I added the option whitelist=1.2.3.4 to bitcoin.conf and restarted the node. But the whitelisted address still showed up as banned in the GUI debug connections tab.

Expected behaviour

I expected the now whitelisted address not to be banned after startup.

Actual behaviour

Address matching the new whitelist option pattern is still banned, showing up in the GUI debug window tab "remote peers" in a banned nodes section, with a button "Unban node". So I clicked that button to manually unban the address. It was lucky that I watched the connections debug tab in the GUI as a routine after startup. I was really surprised about seeing the just whitelisted address there as banned.

I'm not sure we should do this, since it leads to edge cases and interactions which are difficult to reason about. For example, what should happen in the following scenario:

• there's a current ban for subnet 1.2.3.0/24
• there's whitelist configuration for 1.2.3.1

should we remove banning for the entire subnet? Or remove the ban for the subnet and add bans for all other address in the subnet? Or keep the subnet ban configuration?

I'd prefer that the UI issue a warning if it detects that a configured whitelisted address is banned at startup. For example:

"1.2.3.4 is configured as a whitelist address, but is within banned subnet 1.2.3.0/24. To remove the ban, go to <place> and do <thing>"

I would say for this example: "first match wins", with whitelist match checking before ban match checking:

1. check for whitelist match
2. check for ban match
3. if neither matches, do the default action: allow

So, the ban match checking for 1.2.3.0/24 would be kept, but before that ban match check, there would be the (successful) whitelist match check for 1.2.3.1, at which point further matching is stopped and access is granted. 1.2.3.2 would stilll be banned, because first match would be for banned subnet 1.2.3.0/24, at which point further matching is stopped.

Hum, generally for stuff like this you want most-specific to match first, not always whitelist first. Still, the UI issue of the ban appearing in the ban list with a conflicting whitelist is hard... Likely need to just add the whitelist list to the same dialog, and have whitelists that are identical to bans remove the ban (ie most-recently-set-matches-first)

On February 19, 2017 2:00:02 AM EST, wodry notifications@github.com wrote:

I would say for this example: "first match wins", with whitelist match checking before ban match checking:

1. check for whitelist match
2. check for ban match
3. if neither matches, do the default action: allow

So, the ban match checking for 1.2.3.0/24 would be kept, but before that ban match check, there would be the (successful) whitelist match check for 1.2.3.1, at which point further matching is stopped and access is granted. 1.2.3.2 would stilll be banned, because first match would be for banned subnet 1.2.3.0/24, at which point further matching is stopped.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/9562#issuecomment-280900708