whiteconnections should be re-added #8798

1. 
   theymos commented at 8:16 pm on September 22, 2016: none

   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.

2. 
   BitPopCoin commented at 4:23 am on September 23, 2016: none

   I also run into this with armory.
3. jonasschnelli added the label P2P on Sep 23, 2016
4. 
   paveljanik commented at 7:22 am on September 24, 2016: contributor

   @EthanHeilman Can you please look at this issue?
5. 
   EthanHeilman commented at 4:59 pm on September 24, 2016: contributor

   @paveljanik I’ll take a look. I am not familiar with the new connection exhaustion countermeasure code and I should be.
6. 
   asoltys commented at 8:05 pm on November 15, 2016: contributor

   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.
7. 
   theymos commented at 9:04 pm on November 15, 2016: none

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

   0# add any number of the below whitelist rules, replacing 1.2.3.4 with an IP or CIDR subnet
   1iptables -A INPUT -p tcp --syn --dport 8333 -s 1.2.3.4 -j ACCEPT
   2# except for the whitelisted IPs, limit to 100 connections
   3iptables -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.)

8. 
   asoltys commented at 1:57 am on November 16, 2016: contributor

   @theymos thanks I hadn’t even thought of using iptables but that should do the trick!
9. 
   rebroad commented at 5:06 am on November 16, 2016: contributor

   @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.

10. 
    micressor commented at 11:12 am on February 10, 2021: none

    it would be helpful, with a whitelist= permission, to override the maxconnections= option.
11. pinheadmz assigned pinheadmz on Apr 27, 2023
12. 
    pinheadmz commented at 8:02 pm on May 8, 2023: member

    Possible solution WIP: #27600 looking for concept ACKs !
13. 
    pinheadmz commented at 4:05 pm on November 8, 2023: member

    Ping @theymos @asoltys take a look at #27600 please and leave a comment if this is still an issue that concerns you
14. 
    pinheadmz commented at 2:23 pm on April 9, 2024: member

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

Contributors
theymos BitPopCoin paveljanik EthanHeilman asoltys rebroad micressor pinheadmz

Labels
P2P