Outbound connections are already privileged in a number of ways, and the white-listing by default has strange effects on transaction propagation that you probably don't want for outbound connections.

the reason for wanting to whitelist the outbound connection is cuz I'm using connect to connect only to 1 specific node.
without whitelisting the trickling mechanism can cause transactions to take several seconds before being relayed.

I think you might have misunderstood as well based on the title, the PR Is to adhere to the whitelist options when making outbound connections, not whitelist them by default.
though if you don't mind I'd love to learn what you mean by "strange effects" (if not here maybe on IRC ;-) ?)

I agree this would be useful.
There should be some mechanism for whitelisting outgoing connections.
Closing because this is a duplicate of #9923

Oops, missed that this was a PR, not an issue. This happens to be exactly what I need for my tests, thanks!

We might consider using a different option for outgoing network ranges to whitelist, though. It can be unexpected to users if this is merged as-is, as it widens the meaning of an (arguably ill-defined) existing option.

@laanwj Agreed on all points. I've hacked this in for myself a few times for addnode=/connect= nodes. But as you said, tacking it on to whitelist is moving in the wrong direction.

I'd much prefer to get rid of whitelist and replace it with explicit privileges, generated at connection time based on inbound/outbound, config options, etc. That way there's less guessing in the later code, and there's a single place for the logic.

I can whip that up if you agree.

without whitelisting the trickling mechanism can cause transactions to take several seconds before being relayed.

Whitelisting isn't really the correct fix for single outbound connect=1 resulting in slower relay.

I'd much prefer to get rid of whitelist and replace it with explicit privileges, generated at connection time based on inbound/outbound, config options, etc. That way there's less guessing in the later code, and there's a single place for the logic.

I'd prefer that too. Something like, say, a bit field. The current whitelist is both too fine-grained and too course-grained. It's just vague what it does and different people want different things from it, and we can't change it without breaking other people's use cases.

hmm, for me the whitelist makes sense cuz I can easily ensure it covers my local servers without too much ufss

There seems to be no agreement to do this, and quite a lot of time elapsed without new discussion, so I'm closing. Looking forward to alternative solutions as were discussed in this PR.