Concept ACK. SPV nodes use dns seeders to get addresses, so they can filter for service bits.

Side-note: The memory savings aren't substantial (#17164 (comment))

Concept ACK. I think ideally there should have been separate node / capability flags for this instead of piggybacking on NODE_NETWORK / NODE_NETWORK_LIMITED. But that bridge was already crossed with MayHaveUsefulAddressDB.

I'm unconvinced that we shouldn't relay IP addresses to lightweight nodes entirely; there is no reason why they can't do their own IP address management, or shouldn't hear about this information from the network. If it's the case that currently none of them care because they 100% rely on DNS seeds, that sounds like a flaw of theirs, and not something to encourage further by making it harder to use real IP management.

On the other hand, I do see that we may assume that they won't relay the IP addresses further, and we should take that into account when determining where to gossip incoming addr data to.

I don't have a good solution, though.

Now after Pieter's comment I'm leaning towards allowing them to learn, but not choosing them to forward addr messages.

I'll wait a bit for other opinions, and if everyone agrees there — I'll re-implement it according to what I said above. Should be an easy clean change.

Unrelatedly, should we discard/discount addr messages coming in on incoming connections?

I think address management is resource expensive when done correctly. At the very least your SPV wallet would need to connect to the node and check the version message for service bits. Then maybe it should also ask for a block or txs to identify obvious spy nodes. This seems to not fit in well where SPV nodes are deployed (mobile wallets).

@MarcoFalke If wallets rely solely on DNS seeds, that's a scary thing. If we're going to go as far as codifying that as the only option, and giving up the hope that they'll ever do something sane, I will probably stop running a DNS seed.

My gut response is to agree with @sipa... but light wallets are also trust-based, so they should only be used in tandem with your own node anyway. I'm not sure doing their own address management makes sense, in that context.

In other words, the "sane" thing isn't doing their own address management nor relying solely on DNS seeds - it's peering with the user's own full node. And not sharing addresses with them is perfectly compatible with that.

@sipa: Unrelatedly, should we discard/discount addr messages coming in on incoming connections?

If we do what you're suggesting, then

1. Older nodes are very likely to forward their <10 addr messages in the blackhole (ok, that's fixable with work-arounds)
2. I believe forwarding <10 addr messages would substantially degrade. Like, it's very likely that this "stem" will end up at a private node very fast (just graph-wise), and it will drop it on the floor. Can measure.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17164 (p2p: Avoid allocating memory for addrKnown where we don't need it by naumenkogs)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Closed in favor of 17194

I should have kept this code to let reviewers see the difference, but it's too late I guess.

This PR suggested also not responding to SPV's GETADDR. 17194 allows SPVs to request addresses, but avoids unsolicited forwarding addresses to them.

The previous branch was 989e85aecfc59ef0778d188cbcfed7c4f1878485