Add support for dnsseeds with option to filter by servicebits #8083

Opposite part of https://github.com/sipa/bitcoin-seeder/pull/36. Including new testnet seed that supports filtering.

Required for SW #7910.

Concept ACK, but I think it'd be simpler to have this be based on a bitmask rather than service-specific letters.

Yes. Agreed. Will change it to a bitmask. Maybe a hex representation of the uint64_t as subdomain.

Do we actually connect to DNS Seeds, or is it only for Tor where we connect to them, get a list of addresses, and then immediately disonnect?

When on Tor, we connect to one of the seed's results directly, and ask it for getaddr. This does not need filtering.

When not on Tor, we read in the list of IPs returned by the seed, and add it to addrman, without any TCP involved.

Updated this PR and sipa/bitcoin-seeder#36 to support non-bitflags-to-string mapping. Now, node-filtering via dnsseed is possible with a bitmap-filter-hex-string as subdomain.

Example: dig A 5.testnet-seed.bitcoin.jonasschnelli.ch (filter = 5 == 0101) will return only nodes with NODE_NETWORK and NODE_BLOOM service flags set. dig A d.testnet-seed.bitcoin.jonasschnelli.ch (filter = d == 1101) will return only nodes with NODE_NETWORK, NODE_BLOOM and NODE_WITNESS service flags set.

A bar main domain query will still result with the default NODE_NETWORK filter: dig A testnet-seed.bitcoin.jonasschnelli.ch

RBF nodes! dig A 4000001.testnet-seed.bitcoin.jonasschnelli.ch Cool!

Something I noticed was you could also query 0000000004000001.testnet-seed.bitcoin.jonasschnelli.ch instead - it'd probably be a good idea to fail the query if there are any leading zeros, to maximally ensure that everyone uses the same queries whenever possible - better for privacy, and a few less bytes on the wire.

RFC 952 did not permit hostnames to begin with a number. This has since been relaxed but many implementations still manage to screw this up (treating the names that begin with numbers as IP addresses), it might be better to begin the mask with a x, and also require it to be zero extended so that caching isn't degraded by clients using x00000005 vs x5.

Can one of the admins verify this patch?

@gmaxwell: Good point. I just force pushed a change that will require a leading x for the query subdomain. dig A x5.testnet-seed.bitcoin.jonasschnelli.ch for NODE_BLOOM, etc.

leading zeros will be ignored: dig A x0005.testnet-seed.bitcoin.jonasschnelli.ch also results in a NODE_BLOOM filter.

@jonasschnelli Better to not allow multiple encodings for the same request, as that may interfere with caching (see @gmaxwell's comment).

@sipa: Good point. Update the seeder PR to ignore/reject leading zeros. Rejecting = reply with standard NODE_NETWORK filter (same behavior as before this PR). https://github.com/sipa/bitcoin-seeder/pull/36/files#diff-118fcbaaba162ba17933c7893247df3aR263

How will you pass in the required flags to addrman?

I was imagining something simpler here, where a DNSSeedData struct just has a hostname and a servicebits value. For hosts where it is supported, we use ("x9.seeder.host.tld", 9), for others we use ("seeder.host.tld", 1).

@sipa: Right. The code is currently pretty much unused. At the moment, what we want is filter for NODE_NETWORK (which is the default). This results in not using the x<flags>.seed filter.

However, this will be required for SW and I though instead of extending the SW PR, try to get this into master because it can be useful anyways.

This also adds a testnet seed (last weekend only one testnet seed was running).

utACK https://github.com/bitcoin/bitcoin/pull/8083/commits/2d83013dc54320b3f0c978475517da6156f7b50d

what we want is filter for NODE_NETWORK (which is the default)

I think there's something (for consistency / future-proofness) to be said for always using filtering when the seed supports this, even to just request NODE_NETWORK, instead of relying on a default being the same server-side.

Though this would remove the flexibility for the DNS seed operator to change the default and have everyone use that by default, if that turns out to be necessary - which has been discussed in the context of segwit. So I'm not sure.

What is there to be done here?

utACK 2d83013dc54320b3f0c978475517da6156f7b50d