SAFE Network concerns from an old employee

[vtnerd]

@AndreasF

I agree, although I’m not sure whether storage space or rather bandwidth will be the bottleneck and should determine the weight of a node’s vote. I’ve argued for something like that - although my point will probably be too vague for your taste - here:

This was my main criticism on metzdowd. The most difficult problems are still unresolved; implementing solutions in this architecture is far more difficult than discussing the very high-level ideas being proposed. It certainly “feels” like there is a way out of this, but after all of these years the major progress has been to re-work the network topology / message forwarding / group selection with disjoint groups.

If you have not seen it, check out Greg Maxwell’s post about proof-of-storage, and the resulting project BurstCoin. BurstCoin stores complete garbage to your hard-drive, but there might be something to takeaway from it. Also, TOR does bandwidth estimation so it could be useful for comparison purposes.

---

@polpolrene

This wasn’t your claim before. Here is the statement you made about using POW.

@vtnerd

Getting into a disjoint group is a proof-of-work problem, with an easy difficulty. You try hash keys until you get a matching prefix. People generating vanity address for bitcoin are doing something similar already. If you notice, they have some pretty long prefixes.

Like I said before: your replies and the subjects covered are all over the place. You jump from a POW attack (which got debunked quite fast) to a “let’s keep connecting to the network to target a group”-attack.

As stated before, I thought the objection was to the difficulty of finding an address to a desired group. This thought was not absurd; @neo recently thought generating an address for a specific group would be difficult, even after I tried my best to explain that the difficulty will be low.

Once I realized that the confusion was in both, I tried to rhetorically ask questions that I hoped people would lead people to the fundamental voting issue:

@vtnerd

The client could connect to multiple proxy nodes in an attempt to collect multiple responses. If it gets different results, which one does it trust? The “closest” nodes (previous attempt) is probably not a good idea. The quorum? Can the system guarantee that quorum will never drop in this environment (through churn, etc.)? Does it then just become a majority “vote”? If you decide to let quorum drop (for churn, etc.) then it creates an incentive for a malicious node in the group to forcible delay responses from its peers (via overload) to influence the “vote” going through the system (which of course depends on how low of a “vote” can be accepted). And then there’s the possibility of me continually joining the network through different IPs to be “randomly” assigned to the same group. The number of groups is based entirely on the size of the network and targeted group size with disjoint groups. Has anybody thought about the expected number of groups, and the probability of an attacker getting into a desired group?

@AndreasF if the thought has not crossed your mind yet - the “authority” of a blockchain system is the longest chain, and the ability to update/change that authority is proportional to the CPU power. A voting scheme is fundamentally different; if the node cannot “vote” in a given time-frame, their input for status of the entire history of the resource is irrelevant.

---

@polpolrene

Vaults don’t log in to the network. Only users do with a Client. So to attack a group one uses Vaults that “join” the network using the bootstrap process. Attacking a group with clients is impossible as the clients don’t have any group authority. They can only request a service like getting a Chunk or spending a Safecoin.

So the answer to your question is probably close to infinity.

Read the post linked by @AndreasF above. There is still fundamentally a sybil issue that needs a solution, and group voting power provides ultimate authority on the resources for that group, message responses passing through it, and most likely group selection forgeries to any group desired (I was calling this login forgeries, which is confusing due to the clients account + login). The latter two are possible since generating an address for the desired group will be of low difficulty. There are simple things that may work, such as key-expiration, but this forces more churn. And the number of groups matter too - so counter-measures that delay vault-joining by IP or forced group moving is still potentially risky due to the number of factors and complexity involved.