Add network node whitelisting (cannot be banned) #3403

1. 
   jgarzik commented at 7:01 pm on December 12, 2013: contributor

   Includes ‘addwhite’ and ’listwhite’ RPCs.
2. 
   sipa commented at 8:20 pm on December 12, 2013: member

   I had a similar idea about this once, though never got around to implementing it:

   • One other use case for whitelisted nodes is always-relay-everything; e.g. if you have an internal network with several nodes behind a single frontend node, you want their wallet broadcasts to be relayed, and more than just the first time.
   • Just using addresses doesn’t suffice. Right now, we never ban localhost, and that isn’t optimal, as it means never banning incoming onion connections.
   • We could have a -whiteport, which adds another P2P listening port, but connections to it are automatically whitelisted. For outgoing connections, a -addwhitenode or something could exist. In general, I don’t think using IP-based filtering is optimal here - for outgoing connections you want to connect to them anyway, and for incoming connections IP filtering doesn’t suffice.
3. 
   laanwj commented at 1:33 pm on December 14, 2013: member

   Code changes look good, haven’t tested yet.
4. 
   laanwj commented at 10:58 am on January 12, 2014: member

   @sipa but I suppose this is useful enough in its current state to merge? As there is no way for nodes to authenticate to each other yet, there is no way to do anything but IP-based whitelisting. Those other ideas can be implemented later.
5. Add network node whitelisting (cannot be banned)

   Includes 'addwhite' and 'listwhite' RPCs.

   85519ff687
6. 
   jgarzik commented at 8:45 pm on May 20, 2014: contributor

   Rebased.
7. 
   BitcoinPullTester commented at 9:18 pm on May 20, 2014: none

   Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/85519ff6875296dc929c179eff1b2ce95b34787a for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
8. 
   laanwj commented at 9:04 am on May 21, 2014: member

   @gmaxwell @jgarzik @sipa @gavinandresen Regarding this: what are we going to do? I think that we all agree that some kind of whitelisting functionality should be in bitcoin core, but what implementation are we going for?

   There are two pulls requests that implement this functionality at the moment, this one and #3584.

   I do like @sipa’s -whiteport idea as well. I vaguely remember some discussion on IRC a while ago and we came up with that solution as preferable, as it allows using the existing network access control to determine who gets ‘preferred’ access, but I don’t know anymore who was involved in that discussion.

9. 
   jgarzik commented at 2:37 pm on June 21, 2014: contributor

   Closing in favor of #4378
10. jgarzik closed this on Jun 21, 2014

    ---

11. jgarzik deleted the branch on Aug 24, 2014
12. DrahtBot locked this on Sep 8, 2021

Contributors
jgarzik sipa laanwj BitcoinPullTester