Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Added -whiteconnections=<n> option #5288
Refactored, after conversation with gmaxwell on #bitcoin-dev.
Default of whiteconnections is now 4 (if user isn't using whitelist feature at all, default is 0).
Now acts to essentially reserve slots for exclusive use by whitelisted peers, against the given maxconnections limit, instead of increasing the maxconnections limit.
Warning message given if whiteconnections value is so high that it will reserve all inbound slots, preventing any non-whitelisted peer from ever being able to connect.
If user has not given a maxconnections value, then as a special case it adds the value of whiteconnections to the default for maxconnections. This is to avoid establishing a new default which would inadvertently reduce the number of incoming slots available for public (non-whitelisted) use. With the popularity of SPV wallets these days, incoming slots on full nodes are a rather precious resource.
This whiteconnections feature is rather nice, especially for long-lived full nodes which reach their capacity of inbound connections. Now, you don't have to restart your node whenever you restart your miner, just to free up a slot so that your miner can get in!
I thought about that as well, during initial implementation thoughts over IRC. Talked about it with a few others. Tried to avoid surprise and unintended behavior as best as possible, and this was a compromise.
If the increase was done always, then it would be surprising to the user, because it would look like we were blatantly disobeying their given
If user doesn't provide
So, there's thinking that went into both sides of this decision.
The "increase the maxconnections if not specified, don't if it is" is fine, I think, but I wonder if the -whiteconnections default = 4 is needed. An existing user of one of the white* features won't expect a change in behaviour.
I wonder if this isn't a concise way to specify it:
Seems easier to explain, and wouldn't violate the least surprise principle either?
There, as requested, changed the default from 4 to 0. Made no other code changes, just these constants. Also rebased to latest upstream.
So, the behavior is now unchanged, by default. If the user wants the benefit of reserved slots for their whitelisted incoming connections, they will have to explicitly specify how many slots they want to reserve.
This sets aside a number of connection slots for whitelisted peers, useful for ensuring your local users and miners can always get in, even if your limit on inbound connections has already been reached.