I don’t know, maybe it’s needed. But most of the vaults will create a number of identities won’t they?
I am currently looking at the identities at the Routing layer, which are used to allow the nodes to communicate securely and as part of groups to mitigate the impact of malicious nodes. I am not familiar enough with the behaviour of Vaults yet to comment on how they manage identities.
I changed the original post to say that I was actually talking about a Routing identifier. The rest of the post still applies since farming nodes also participate in Routing so an up-front cost would show up for farmers.
And if you want to join a group, the group will decide your address isn’t it?
As far as I understand, at the moment you generate identities and try to join groups near each identity generated until one accepts you.
So how can the same node appear multiple times in the same group?
In the absence of any limitation mechanism, a malicious node could run a different version of the code that would create additional identities to join in with multiple identifiers simultaneously.
You need to create a big number of them than?
Yes, if a malicious node can generate enough identities, some of them would fall within the same group. If that happens, the assumption that a quorum of 28/32 nodes can tolerate up to 4 malicious nodes in the same group does not hold anymore because it implicitly rely on the direct correspondance between a malicious entity and a single identifier.
It is therefore necessary that something limits the creation of identities.
I thought a minimum level of rank is required to be able to effectively vote in a consensus group? That way there is an upfront proof-of-work requirement.
If that is the case, then that could potentially be a good limitation mechanism. We would need to look then at how to bootstrap such a mechanism because you need a certain number of nodes in the first place to challenge the nodes that join later. Who assess the initial nodes then?
In addition, we need to look closer at that proof-of-work mechanism because it effectively might limit the rate of growth of the network. If chosen incorrectly, that might prevent the network from accepting a sudden surge in popularity from legitimate users.
Moreover, what if that 1$US would have to be sent to an address controlled by the MaidSafe Foundation?
That would deteriorate the neutrality of the network in my opinion.
I am not quite sure about what you mean by neutrality here. I am thinking that the funds could then be allocated to community projects through a democratic vote by farmers.
I think it’d scare regular farmers off more than attackers, especially the state sponsored ones with virtually unlimited money to burn. A lower number of regular farmers in turn weakens the security, since there’ll be far less small nodes with no ulterior motives.
If the amount was chosen such that a farmer would get back the upfront cost in a few hours/days/weeks in revenues, it could still be attractive to farm. It would however add an additional step to joining in, which would add friction and certainly deter some users.
I thought there was no need for this and am surprised its an issue. Is it? If so, please can you explain why the network is vulnerable - or at least detail the sybil attack and how it is possible given the network behaviour planned.
See above. I am still thinking through the actual damage such an attack could cause, I’ll come back with more details as I figure things out.
Regarding the up-front barrier to farming this is a massive the bad thing from the network point of view and to be avoided unless absolutely necessary.
Farming as a checkbox confirmation on installing SAFE is a great feature and to be retained if at all possible!
I fully agree that to ensure the widest adoption possible there needs to be as little friction as possible for new users to join in. We also need to ensure the good guys outnumber the bad ones ;-).