Another “selfish node” type attack. Looking for comments:
Assertions:
*Chunks are dispersed by going to the node with the id closest to the chunk name
*close group is made up other vaults with id closest to yours
*you are directly connected to your close group. Eg: you can see their ip.
This would mean it is very likely that the members of my close group have many of the same chunks that I do.
If this is the case, what prevents me from DoSing the other members of my close group (out of band, rented server somewhere) so that any get requests take longer to get there, and are also returned slower, thus increasing my chances of winning the “get race”?
This is not correct. The nodes with ID’s close the chunk’s name become data managers. Data managers randomly choose a number of nodes to actually store the chunk. They maintain an active connection with these nodes. When you GET a chunk from the network that GET is send to the data managers first, who pass it on towards the nodes holding the actual chunk. Those nodes reply directly back to the client.
As you kill a node another automatically takes over (xor space).
The data exists in at least 3 very separate locations and not in your group only, even in your group only in 2 nodes not all (try to ddos and you kill your chance of farming as the back group kicks in, plus you get disconnected)
Such and attack would only be vandalism and if you could ddos hundreds or thousands of nodes to try and make this happen your likely slow the network down in the part thats needed to farm the main data leaving the back to work, unless you could ddos thousands more then the sacrifical group kick in.
As a group detects an attack and especially from a IP address of a group member the group member would be disconnected, so immediately no data you have, the force is strong in that group
There is no such thing as a static group, it;s like poking a hole in the sea, you cannot do it.
I am stopping now, but this is a very very long list
Thanks for the detailed response. Puts my worries to rest like that!
Keep up the fantastic work guys. You guys have put immense amount of thought into these things and the more questions I ask and that I read, the more I am impressed with just how well thought out and well planned this entire project is.
Vaults in a group must know each others IP to create the network. They do not go beyond (barring the other 32 connections that are random). This is an absolute requirement as they connect to each other via IP and IP routers etc. Group->group then IP is unknown, as soon as 1st hop is made the IP is gone for nodes and clients as we are on xor now.
By connecting to a group one can log vaults’ ip
I assume by disconnecting/reconnecting one gets another group? Thus one could cycle through the whole network and log all (or most of) ips then whitelist one’s final group and mildly ddos the rest of the network just enough to win the GET
Think what kind of resource you would need here! It’s pretty enormous you are talking of ddos’ing perhaps millions of nodes at once many of which will have changed through churn anyway
Sure it’s not feasible on the fully fledged network but someone could try that on the initial network just for sports
But if it’s indeed possible to map the vault network through cycling your own vault then (from the sysdocs):
“This passport contains a variety of key types that enable different tasks to be performed across the network. The location of this initial key is masked or at least not obvious in the SAFE Network.…”
Couldn’t the certain ABC’s with all their computing power and paralllelisation be able to map the whole network? And if they could do it faster than a churn rate couldn’t they locate the passport through traffic analysis?
Yes absolutely we should try all these kinds of attacks even on small networks (we do in house with simulations etc.). Explaining why they don’t work is incredibly hard though as it’s a mix of XOR (non linear) addressing and cryptography ciphers plus obfuscation algorithms. What I mean is that it’s incredibly hard to summarise. In these cases we try and just show results as a binary works / does not work is much easier to understand.
It’s technically possible, but computationally infeasible, like it’s possible I can type out a BTC private key for a wallet with millions of pounds in it or randomly type a password till it works for launch codes or similar. It’s all possible
To find that you would need to know the users keyword pin and password, there is no way to identify that on the network. No amount of searching would help in this case AFAIK,
100%, what we do not solve and need to (as a species I mean, not necessarily this project) is end point security. This is from the keyboard/input device to the network. I feel from the network we are OK with SAFE, the first part is a large red flag though and needs attention. What we can do is supply mitigation tools (account rollback etc.) but ultimately we need to attack the actual problem and that is end user devices.
