whiteconnections should be re-added

[theymos]

The whiteconnections option was added in 0.12 but later removed in #6374 because it was viewed as being redundant. While whitelisted connections can no longer be evicted as of that PR, whiteconnections is still useful because it allows for new connections. For example, you could have a full node that you use as a gateway for several of your lightweight nodes, and in this case it may be impossible for you to connect to your gateway due to insufficient connection slots. whiteconnections solved this, but it is now removed.

Here's a real-world complaint about this issue: https://www.reddit.com/r/Bitcoin/comments/540hoj/can_whitelistnetmask_free_up_a_connection/

Perhaps it would be more elegant to detect when a whitelisted peer is trying to connect when we have no more connection slots, and trigger the eviction of a non-whitelisted inbound peer in this case. But it's probably easier to just re-add whiteconnections.

[BitPopCoin]

I also run into this with armory.

[paveljanik]

@EthanHeilman Can you please look at this issue?

[EthanHeilman]

@paveljanik I'll take a look. I am not familiar with the new connection exhaustion countermeasure code and I should be.

[asoltys]

I'm hitting this issue now as I have an SPV node running on limited hardware that connects to a trusted full node on another machine. The full node accepts public connections as well and sometimes doesn't have a slot for my SPV node even though the IP it's connecting from is whitelisted. It'd be nice if the full node would eject some other non-whitelisted node to make room for my SPV node when it's trying to connect.

[theymos]

@asoltys As a temporary measure, I believe that these iptables rules will limit the number of incoming connections:

# add any number of the below whitelist rules, replacing 1.2.3.4 with an IP or CIDR subnet
iptables -A INPUT -p tcp --syn --dport 8333 -s 1.2.3.4 -j ACCEPT
# except for the whitelisted IPs, limit to 100 connections
iptables -A INPUT -p tcp --syn --dport 8333 -m connlimit --connlimit-above 100 --connlimit-mask 0 -j REJECT --reject-with tcp-reset

Note that the --connlimit-above 100 limit will only apply to connections that actually hit that rule -- whitelisted connections will not be counted. So the above rule allows for (by default) 8 outgoing connections, 100 non-whitelisted incoming connections, and 12 reserved slots for whitelisted IPs.

(This is largely untested.)

[asoltys]

@theymos thanks I hadn't even thought of using iptables but that should do the trick!

[rebroad]

@theymos thanks for raising this - I was wondering why my whitelisted SPV node had stopped being able to connect to my full-node - this would explain why.

I don't think reverting #6374 is the best solution though - at least, not in a way that available inbound connections are reduced while the white connections are not in use. Ideally I would like to see the feature where when a white connection comes in, an existing low-rating inbound connection is evicted to make room for it. This way it's simply a case of white connections having priority over other inbound connections, without needing to state how many slots to reserve.

[micressor]

it would be helpful, with a whitelist= permission, to override the maxconnections= option.

[pinheadmz]

Possible solution WIP: #27600 looking for concept ACKs !

[pinheadmz]

Ping @theymos @asoltys take a look at #27600 please and leave a comment if this is still an issue that concerns you

[pinheadmz]

Proposed alternative to #27600 is a setting such that bitcoind listens for inbound connections but does not advertise itself