-whitelist for outbound connection
#10051
unsure why this wasn’t already being done, seems sensible to me that you also want to be able to whitelist nodes that you make an outgoing connection to?
trying to figure if there should be any tests added but I can’t seem to find tests that really cover ConnectNode specifically at all?
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 ;-) ?)
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.
Labels
P2P