This post investigates a targeted google attack, ie offline key generation to initialize a vault into a specific section.
Thanks to @digipl for provoking this line of thinking in a prior post.
The relocation mechanism requires targeting to be not only possible but to also be viable. Vaults are relocated to a neighbouring section, which means the vault must be able to generate a key matching that section prefix. This is exactly the same thing an attacker would do to target a specific section.
“When a churn even does force a node to relocate to a destination group (D)… The relocating node then generates a key that will fit in D and attempts to join D.”
from RFC-0045 Node Ageing, more info in this post in the Data Chains topic.
The reason this targeting is damaging is due to relocation to neighbouring sections only. This means the possible sections to be relocated to is quite small, as outlined below.
Sections: total sections in the network
Neighbs: how many neighbours an average section would have (log2(Sections))
Reachable%: the percentage of sections available as a relocation target (Neighbs/Sections)
Sections Neighbs Reachable%
1K 10 0.997
10K 13 0.133
100K 17 0.0166
1M 20 0.00199
10M 23 0.000233
This is not great! Vaults can only ever be relocated to a tiny subset of the network (typically less than 1%).
Targeted vs NonTargeted
The previous simulation was a nontargeted attack, akin to an intern at google deciding to start a bunch of vanilla vaults which are randomly located through the network.
A targeted attack means the attacker is always joining the same part of the network, which means their vaults will always reside in a small subset of the network as indicated above, even after relocation.
This concentrates their influence much more strongly than using random starting locations.
The ability to target a section is not only possible but is an essential feature for the current design, since vaults must be able to relocate to a specific neighbour.
100K vaults (500K join interleaved with 400K depart). Then 10 attacking vaults all targeting the same section + 1 normal vault join + 1 normal vault depart. Repeat until a section is controlled by the attacker.
No disallow rule.
Full details in google_attack_targeted.go.
Targeted NetSize Test 1 2 3 4 5 | Avg Pct
No 100K 125776 98073 137955 103118 97975 | 52.7
Yes 100K 1852 4893 2598 2366 3694 | 3.0
This is probably a great example of where the disallow rule might be considered useful since it should prevent any single section being flooded by an attacker.
But it doesn’t work because it leads to a denial of ALL vaults to that section until the youngest vault moves away. An attacker spamming the section with joins makes the chances of a normal vault joining much lower, so all new joins are very likely to be from an attacker.
I think there are better alternatives to the disallow rule and it should be scrapped completely. I’m confident that punishment for misbehaviour is good enough. There’s no need to be strict at the point where users are simply trying to participate.
Also, at a more ‘social’ level, turning enthusiastic new recruits away is really poor. This is a legitimate marketing problem (and by marketing I don’t mean ‘impressing people’ I mean ‘increasing the size of the market for safenetwork users’).
It’s worth considering, do vaults actually want to be elders? Intuitively I’d say ‘yes’ since it’s the end result of a long process, so surely it must be good! But in reality, being an elder means a lot more work and demand on resources, but for what benefit to the vault operator?
If vault operators only want to earn safecoin, they’re better off not being elders so they can put all their resources into serving user requests and getting maximum chances to farm new safecoins. Any work done ‘managing the network’ (ie being an elder) is ‘wasted’ from a safecoin perspective.
So I think eldership must be viewed as a chore not a privilege. To me this is a very significant change in perspective with significant consequences through the entire incentive structure and the design of participation, rewards, punishment, security… the whole lot.
At the very least it’s worth considering that maybe being an elder isn’t desirable to all operators and it’s possible that many elders will immediately leave the network upon being promoted to avoid doing the work so they can get back to earning safecoin with minimum effort.
My suggestions for potential ideas:
no disallow rule
relocate to anywhere on the network, not just neighbours (a very large and technical discussion needed here)
farm rate varies depending on the amount of work done (so elders have economic incentive to take on the extra work they must do. A complex discussion to be had here)
elders are assigned on a ‘rotating’ basis, so the ‘chore’ is distributed rather than retained, many possible mechanisms for this, but maybe turns out not to be a desirable feature…?
more discussion of punishment as a way to replace the disallow rule
there are so many potential paths, these are just some of many, but they are the ones I currently think are the leading contenders. I’m totally open and excited to explore other potential paths.
It’s obviously not great to have major rethinks of critical security algorithms. I would love it if the existing design could be made to work. But so far I’ve not been clever enough to smooth the rought bits into a habitable design. Hopefully further thinking and discussion can get us there.