You can ship a client with a long list of "cached" nodes that were verified to be long-lived. I mean you need to obtain the client at some point, you can gather a fresh list of nodes along with it. From that point onward you keep your own cache fresh.

You could also run your own bootstrap node on an always-up server if downtimes making the lists stale is a concern.

You can also inject contacts when starting the client, you would have to obtain them out-of-band from somewhere of course, but it still does not require anything centralized.

If you're desperate you could also just sweep allocated IPv4 blocks and DHT-ping port 6881, you'll probably find one relatively fast. Of course that doesn't work with v6.

So there is no centralization and no single point of failure.

> The multicast neighbor discovery is a neat idea. I wonder what percentage of clients/connections it results in successful bootstrapping for.

It could work on a college campus, some conference network or occasionally some open wifi. Additionally there are some corporate bittorrent deployments where peer discovery via multicast can make sense.

If I understand TFA correctly scuttlebutt assumes(?) roaming through wifis and LANs. Those circumstances are ideal for multicast bootstrapping, so in principle the DHT can perform just as well as scuttlebutt, probably even better because once it has bootstrapped it can use the global DHT to keep contact with the network even if there is no lan-local peer to be discovered.

> You can ship a client with a long list of "cached" nodes that were verified to be long-lived. I mean you need to obtain the client at some point, you can gather a fresh list of nodes along with it. From that point onward you keep your own cache fresh.

There is no semantic difference between the two. The only difference is when you connect to the single-point-of-truth bootstrap, at download time (well, technically build-time) or at first startup time. And the latter probably gives you a more current, and not limited to long-lived nodes, thus better, answer.

> You could also run your own bootstrap node on an always-up server if downtimes making the lists stale is a concern.

Which itself needs to be bootstrapped. And once it is, it's equivalent to your local cache.

These are excellent ideas. Are any of them implemented? If I download e.g. uTorrent today and firewall off the hardcoded public bootstrap nodes, will it bootstrap?

> If I download e.g. uTorrent today and firewall off the hardcoded public bootstrap nodes, will it bootstrap?

Possibly, which mechanisms are used varies from client to client. Usually DHT bootstrap is not a primary goal but a side-effect of other mechanisms. Things that work in some clients:

  magnet -> tracker -> peer -> dht ping
  torrent -> tracker -> peer -> dht ping
  magnet -> contains direct peer -> peer -> dht ping
  torrent or magnet -> multicast discovery -> peer  -> dht ping
  torrent -> contains a list of dht node ip/port pairs

As you can see all but the last piggyback on regular torrent connections. But that's more because file transfers are the primary purpose and the DHT is not the raison d'etre of those implementations. If DHT connectivity were considered more important clients would also try more direct approaches.

> You can ship a client with a long list of "cached" nodes that were verified to be long-lived. I mean you need to obtain the client at some point, you can gather a fresh list of nodes along with it. From that point onward you keep your own cache fresh.

I believe this is how bitcoin works. Or at least it used to.