Will users' IP addresses be discoverable?

Will the IP addresses of users of the Maidsafe network be discoverable?

Nope. Only to maybe 3 or 4 of your closest nodes. They know port and IP but they don’t have a clue what you’re doing. If your in a group op 32 nodes, and you want to get Chunks you request a connection to another group of 32. So the closest group of 32 connects you to another group using private and public keys (only you have the private one). So your close nodes are like a “proxy” to you. Here’s some more details:


Not clients who will relay via nodes. nodes will be only if the node that asks is good for thheir routing table. so as an example in a network of 1 million nodes the next node that will be valuable to you may be 11 million nodes later. so pretty hard, but not impossible as we do use ip. IP addresses are scrubbed on first hop of normal messaging though. Only connect request/connect response will have IP addresses and it’s the requester that give his first, if the responder want to connect he confirms cryptographically the ID of requester and if it’s a good fir will send back his ip address. For clients they do not do this as part of running, only vaults.


Is it fair to say that clients are immune to a sybil attack in this context?

Yes, a bit more info on this page

1 Like

But with a sufficient number of attacking sybil nodes, the client’s IP address is revealed to the attacker, correct? Would the attacker be able to monitor the client’s activity?

The client connects to random addresses and does not disclose it’s identity. So it becomes a problem of scale, the number of nodes required becomes huge if you want to grab a clients IP. Don’t be too scared of IP though it’s not our security to mask that, but it helps.

The client connects to random IP addresses previously known, not possible to gues what they will be. It’s not geographic etc.

So what would you know?

Well if you are routing a message you would get to know some things but not others as they are encrypted to actual end user (not you), but you will route the packet.

When we are up and running then you can see how hard this attack would be. Humans are terribly bad a scale and exponential difficulties, but we will show you :wink:

1 Like

What about website or app data passed between a client and a vault? Is that data known to a routing node? Does a vault ever know the requesting client’s IP like a routing node does?

1 Like

Is a sybil attack to discover a user’s IP address less feasible in Maidsafe than it is in a typical blockchain network?

It is the scale you need to consider, you are one node and a client may connect via you, but you will not know which one :wink: Scale is hard to see.

Typical any networks expose IP addresses all the way through (see TOR exploits on this, it’s frighting). Bitcoin for instance does nothing really, no encryption single protocol (tcp) and single port. So very simple to see what is happening and where.

What we are doing is trying very hard to ensure there is no obvious protocol (hence crust multi protocol strategy), no obvious ports used (these are random) and a few other things like scrub IP completely on first hop. There is a lot more but it’s a very deep area. It’s also full of “but what” and "OK then but " questions that go on forever :slight_smile:

It’s possible to do many things in this network as true p2p networks have not attempted this NAT traversal and random port/protocol combination. So very interesting.

Bottom line assume folk have your IP, if your traffic is then susceptible you have done something wrong. Design notes though, make getting your IP as hard as possible within realms of reality. You will never get the 100% but you can make things extremely hard to monitor.

If you are to be monitored as a hard target then the actual wire coming out of your house will be tapped. We are OK there too :slight_smile: Mind deep packet inspection, whitelisting (we cannot beat whitelisting easily)

So an enormous area, I Will get into it all much more after launch.

In terms of Sybil and Spartacus attacks these are terms folk throw about in a weird way, like coutnerparty risk, psi epsilon attacks etc. It’s much better to look deep and take a whole tool-kit as your defence. This means Obfuscate what you can, encrypt what you should and do not create static locations to attack. If you focus there then security will just increase :wink: A huge area is create a mechnaism to have a decentralised PKI network that cannot be controlled by people, but fixed in maths. Then things get very interesting. Then MiTM problem goes away nicely as it should as it’s is daft. So you will see the toolkit is an array of protections that all mesh together to provide security.

People will take a while to get all this stuff, but we need to have eyes on, so please keep looking, but it’s not something easy to give a quick answer to.


Very informative post, thank you.

If I broadcast a transaction on a blockchain network, that transaction passes through many different nodes/computers on its way to consensus. If I submit a piece of data to a website on the Maidsafe network, how many different nodes/computers does that data pass through?

Approaches Olog(n) hops but reduced as the routing table is not populated fully therefor large jumps across the address range happen. So approaches Olog(n) but should be much less. Hugely dependent on population of network.

Again no quick answer here.

1 Like

Here’s some more info:

It may seem that sending and receiving files over the network would be a time consuming process with so much going on, but routing over the network is quite efficient using a Kademlia4-like distributed hash table (see below). With millions of nodes, it seems impossible to find a node closest to a certain ID. However, the amount of hops required to find a node closest to a particular address is O(log n), where n is the total number of nodes in the network. Put simply, in the absolute worst case scenario it will take 23 hops to locate a node with a particular ID in a network of 10 million nodes! Once located, they can communicate directly with each other.