Refactor hard-coded DNS seeds into configuration file

[bitcartel]

I didn't assign a BUIP number for this, as this is low hanging fruit.

Move hard-coded DNS server addresses to a config file because servers are not guaranteed to remain online and if they disappear, users have no way to change servers unless they modify the code. For example, this server went offline:
https://github.com/bitcoin/bitcoin/commit/e18378e53fb71c39236db35ab2d560b43602b1be

Server addresses could be stored as a list of key-value pairs in bitcoin.conf or a new configuration file e.g. bu.conf or bitcoin-dnsseeds.conf. Default values would be set in the example bitcoin.conf to make it easier for new users to set up. However, desktop (QT) users would expaect to be able to launch the application without having to first edit a config file, so a default config file may need to be bundled and copied to the correct config file location on first launch of the QT application.

References:

• https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
• chainparams.cpp (lines 103-108, 182-184) https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/chainparams.cpp

 

[freetrader]

I would vote for this, and I think even low hanging fruit deserve a BUIP if they are an improvement!

 

[theZerg]

Is it even a distributed p2p network if it uses hard coded servers to make initial contact? What other techniques are there?

 

[sickpig]

This is a thing that have always bothered me. This is even worst than Corallo's RN, adresses are hard coded in the source. The owners of such domain name servers could potentially hindering/hijacking the ability of a node to participate to the network, couldn't it?

Of course a skilled operator could work around it passing the IP addresses of known nodes, still this is quite inconvenient.

More than that, there's not so much diversity in the owners list of such service. Two out of tree are well known for their opinion on the scale debate, namely Peter Todd and Matt Corallo.

@theZerg I don't have an answer to your question just want to say that it is the same question I had the first times I noticed it, maybe @Gavin Andresen could shed a light on this matter.

edit: found this valuable resource, aven if a little bit dated, about node bootstrap phase: http://bitcoin.stackexchange.com/a/2030

 

[TrevinHofmann]

It might be different from the last time I checked, but nodes could broadcast their presence to an IRC channel to find peers.

 

[YarkoL]

@TrevinHofmann
I think the irc method was dropped in v.0.8 as it
was a point of failure (irc server down).

In addition of DNS seeds, there are also hard-coded
seednodes in chainparamsseeds.h, some of them I think have
gone missing, but are still there.

To provide a config file at installation time would mean that
we would have to prepare a list of nodes beforehand, and that
approach would have the exact same problems...

Other than that the remaining option is to share good node ip's
from time to time on forums and on Web, which is quite common
practice in the altcoin scene.

 

[TrevinHofmann]

I don't think bootstrapping nodes are a threat to decentralization. If there are better alternatives, I'd be interested in learning about them. It seems that the important thing is having plenty of bootstrapping nodes for the client to choose from randomly, and having those nodes be operated by a wide variety of entities. This keeps the risk of a sybil attack to a minimum.

 

[bitcartel]

@YarkoL There are academic papers on how to bootstrap a P2P network I think a pragmatic solution would be to have the default config file with DNS seeds pointing to well-resourced companies and organizations such as Bitnodes and BTCC (any others?) rather than individuals. If there are any problems with these seeds, at least users have the ability to share information and update the config file themselves rather than wait for the next release of the software.

@TrevinHofmann Agreed, important to get nodes connected quickly and from a wide variety of sources. A fall-back mechanism may be to make HTTPS queries to public APIs which return a list of Bitcoin nodes to connect to. For example - https://bitnodes.21.co/api/v1/snapshots/latest

 

[bitcartel]

@solex @theZerg I've updated this as BUIP018 with code. Please consider for voting. Thanks. https://bitco.in/forum/threads/buip018-seeding.1065/

 

[solex]

@bitcartel
Thanks for producing this. It is certainly an area which needs improvement. I don't think it is possible to avoid using some list of known nodes for bootstrapping, but as has been pointed out, using an initial DNS list is not really a threat to decentralization.

Updating a config list with each major release should be sufficient, and allowing users to modify it without recompiling is overdue.

Now that our formal v0.12 is out we can have a vote on the recent BUIPs. Three months from the previous is April 29th.