Isn't this a weak spot?

From the primer PDF: “The first connection to the SAFE Network that a Vault or Client makes is to a MaidSafe bootstrap server, one of a number of servers run by MaidSafe to allow new machines to join. The public keys for these bootstrap servers are hard-coded into the Client software, so the communications between the network and the user are always encrypted, never in plain text.”

So there is a hardcoded set of IP addresses, all controlled by MaidSafe, for the clients to bootstrap themselves? I realize that it’s probably impossible to not do it this way, but isn’t this a major weak spot?

1 Like

There is a number of discussions over this and some interesting aspects to explore

  • bootstrap is cached so that when you rejoin you use previously used nodes that nearly always will be other nodes.
  • Maidsafe have said they will retire those nodes so that you have to join other nodes.
  • The nodes could be blacklisted by company or ISP or China or …
  • people will provide node IP addrs to bootstrap off (allow chinese etc to join without need for hardcoded nodes)
  • etc

Do some searches on boot strap and explore these topics. Way to much to answer quickly

Basically this will be developed further when the code is further down the development stage and its considered perhaps a hindrance but not a weak point as such.


Yes, this was badly worded. This is the revised text

For a Vault to join the network it requires the IP addresses of other Vaults to connect to. For the initial connection MaidSafe provides a small number of bootstrap servers. These are internet-connected machines running the Vault software. The IP addresses of the bootstrap servers can be added to the new Vault’s configuration file, or it can connect to other Vault in the network if their IP addresses are known. The connection itself is fully encrypted, the randomly generated public keys of all valid Vaults being stored on the network, and the initial connection is dropped after the first hop when the new Vault connects to others in the network.


@EvilMaid was referring to the clients connecting though

While similar consequences, it is the majority of connections to the network since its every person browsing the safe network rather than the vaults/nodes.

1 Like

Perhaps this should be ‘For a node (Vault or Client) to join…’ then?


As far as I know the logic is similar. But it is 2 separate parts and there maybe differences since the node joins to many other nodes in a section, but a client connects to one or more relay nodes. But maybe the initial joining the network might follow the same logic — I just do not know.

1 Like

Bitcoin has the same problem and solution, at least conceptually speaking. Nodes need a way to find one another on the internet before they can join together to form a p2p network. A hardcoded list of servers (IP or dyn) are the first port of call, after which nodes can find and remember their ‘favourite’ peers to stay in touch with and maintain that list themselves. Bootstrapping is the difficult part and you are correct to consider this a weakness, at least though it is a weakness common to all[?] p2p system on the internet (Bittorrent too).

During the Arab Spring, and pursuant internet censorship controls, people resorted to graffiti-ing walls with google’s DNS server numbers which are intentionally easy to remember…


Yes, I think so. If I have understood correctly, both kinds of nodes (clients + vaults) have a common initial bootstrapping phase. This means that they can share the same contact list. This common list can be managed in several ways:

  • hard coded

  • cached from last session

  • exchanged between people (by mail, in web sites on clear net, text messages, …)

Edit: As shown by @opacey it can also be painted as graffiti on walls.


The bootstrapping methods mentioned are most efficient to quickly join, but Ipv4 address space isn’t that big… As the network grows what is the probability that a randomly selected address is already in the network? I think dirvine had mentioned the use of network beacons or other search methods for nodes and clients to knit themselves together without bootstrapping servers…


No reason that a contact address couldn’t be an IPv6 address (except that it is longer to paint on the wall :smile:).

1 Like

i guess he’s saying that there is a possibility of connecting to random ip addresses and hitting running vaults (+ ~2 random bytes for the random port).

1 Like

Yes, I probably shouldn’t have just said ipv4, didn’t want to get into talk about oodles of possible ip addresses when considering ipv6. Regardless, whether or not you are dealing with ipv4 vs. ipv6, as the network size grows there is a growing probability of selecting a random ip with port number and hitting a node on the network. In the beginning this probability is infinitesimally small, so knowing bootstrap nodes is vastly more efficient. However, if the network grows as intended, I don’t think it would take to long to find a node through a random walk. Granted, this is the least efficient fallback method in case the other (better) methods already discussed have failed.

1 Like

This is a very pertinent point. Here’s more info because imo this is a totally solved problem already

It will be very hard to spoof the real network using a malicious bootstrap. And even if it does happen the value to the attacker is probably not very high since login credentials stay local.

But if you’re running a malicious client which is the cause of the malicious bootstrap, well that’s gonna be a problem!