search

handshake-org / hsd

Handshake Daemon & Full Node
Other
1.92k stars 279 forks source link

Use SRV records to bootstrap mainnet Brontide peers #176

Open kilpatty opened 5 years ago

kilpatty commented 5 years ago

I wanted to open up an issue for general discussion on mainnet seed nodes.

We are happy at the Handshake Alliance to run a seed node for mainnet, and I think it would be useful for us to discuss the process for getting a seed node merged into the official list in this repo.

Additionally I'm hoping this issue can be used to discuss different ways of discovering and registering seeds on the network. There has been some discussion around integrating Lightning Network's BOLT 10 for DNS bootstrapping-> https://github.com/lightningnetwork/lightning-rfc/blob/master/10-dns-bootstrap.md

I figured now would be a good time to open this up for discussion so that we can ensure that any additional software that needs to be built for this process has enough time to be completed.

chjj commented 5 years ago

I like the SRV record idea (LN might be the only thing that actually uses them).

In the spirit of discussion, one thing that's unique to our project is that we have a chicken and egg problem for SPV nodes: an SPV node may be used as a machine's primary DNS resolver. In theory, if the only seeds they have are DNS seeds, they would never be able to locate any peers on boot (they can't resolve anything without peers and they can't find peers without resolving something).

The easy way around this is to hit a nameserver's IP directly or use named DNS seeds and force using something other than the default OS resolver (like opendns -- but that sort of defeats the point of handshake).

Full nodes shouldn't have much of an issue except on first boot.

With that in mind, I feel like the hardcoded IP seeds bitcoin has in addition to DNS seeds are very necessary in our case.

All of this is part of the reason I've hesitated in setting up DNS seeds. I've long wanted to make a DNS seed plugin for bcoin. It would probably be pretty easy with our bns library. I'll try to whip something up.

tynes commented 5 years ago

I like the SRV record idea (LN might be the only thing that actually uses them).

I agree about using SRV records, I can see their use becoming popular for peer discovery in any p2p distributed system. Especially if the tools to manage a DNS zone are commoditized to the point where its really easy to set up a zone in a secure way.

The easy way around this is to hit a nameserver's IP directly or use named DNS seeds

Maybe we begin to organize people who are interested in running a seeder node and test their uptime over a period of time and then add them as a seeder. We could ask for some IPs and named DNS seeds to balance things

kilpatty commented 5 years ago

Maybe we begin to organize people who are interested in running a seeder node and test their uptime over a period of time and then add them as a seeder. We could ask for some IPs and named DNS seeds to balance things

I like this idea a lot, I think it would be useful to define maybe some standards in terms of what we want to see in a seed node: uptime %, average latency, etc. We could build a plugin to maintain these stats on nodes in the network, so that it would be easy to verify someone's proposal to be a seed.

@chjj if the DNS seed plugin for bcoin/hsd isn't too high up on your priority list, I'd be happy to take a crack at it over the weekend.

stp-ip commented 5 years ago

What most systems do with bootstrapping the resolving a specific domain is to use one of the bigger providers such as 8.8.8.8 or 1.1.1.1. Another option could be to hardcode a few IPs that are able to resolve our bootstrap seed domains, but are controlled separately. Less reliance on Google/Cloudflare, but reliance on less stable infrastructure.

For Lightning the DNS seed responder is running a node and checking uptime, latency and more continuously afaik.

stp-ip commented 4 years ago

Would still be up running a seed note behind anycast and hsnseed.com ;)

Edit: Our seeder node is live with simnet data and automatically switching to mainnet data: use.hnsseed.com

pinheadmz commented 4 years ago

Just doing some github issue housecleaning today. Since brontide isn't the default protocol to connect to new peers, should we still try to advance something like this?

hsd does not add gossiped addrs if a brontide key is included in the ADDR message:

async handleAddr(peer, packet) { ... https://github.com/handshake-org/hsd/blob/fb6ce9fe4a884048e54654a591f0b002e829b81f/lib/net/pool.js#L1667-L1668