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.

Code changes look good, haven't tested yet.

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

Rebased.

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.

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

Closing in favor of #4378