The “authority” of the group is tied to the majority vote of the nodes in the group. Getting a node into a desired group (with a login procedure that selects the group for you) will be a probability determined by the number of groups. The number of groups will be determined by network_size / target_group_size. How many login retries before an attacker gets majority control of a group? Once this occurs an attacker can generate group addresses easily for spoofed response messages, and likely spoofed logins.
Ideally the vote would be proportional to proven storage space, but I cannot recall seeing this mentioned before. Either way, I thought it might be worth thinking about moving parts that are likely to be necessary sooner rather than later …
Ideally the vote would be proportional to proven storage space, but I cannot recall seeing this mentioned before.
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 wasn’t your claim before. Here is the statement you made about using POW.
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.
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.
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.
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:
@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.
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.
Again confusion as you can’t be part of the network in an empty group. That’s not my claim but from the main dev who’s working for over 10 years on this stuff:
If you make a number of claims and confuse people with the basic terminology of the system nobody understands what you mean. It causes conversations which are all over the place.
That’s in a topic I started myself, I know that reply. That wasn’t my point. My point was: you talk about logins while it isn’t called logins on the network like you agreed above. And you jump from a POW-thing with prefixes to an attack using bootstrap and hundreds/thousands of nodes. Like I said, all over the place. It’s like talking Bitcoin and jump from a 51%-attack to a spam-attack as if it was all the same. It isn’t.
Yes, I could have done better anticipating what people were asking. But this does not necessarily invalidate things I have said. My original post on metzdowd (the ultimate reason for this thread), stated that I thought disjoint groups still had sybil problems. I did not expand on this thought, so it was likely ignored by everyone. But no one questioned that particular statement either. From that post 2 weeks ago:
There is no confusion. An attacker that wants to create a network-address for a group of their choice with the goal of spoofing messages or spoofing group joins is fundamentally facing a proof-of-work type scenario. You will have to stop reading my responses with such haste to get this.
Using the term consensus does not mean that the code was actually doing that. The code could drop below 51% in several use cases (two-writers each doing back-to-back writes, three-writers, two writers then churn to “flip” to a different value unintentionally, etc.). The nodes of a group were simply not communicating with each other the value they intended to store. The github patch referenced above was in response to this, but there are still bugs with churn, machines under load, and a malicious coin owner getting a single node into the group (it becomes the deciding vote in a 1-vote-per-node scheme). There might be more scenarios, I would have to re-read the literature.
It has been proven that this can be “converged” if 2/3rds of the participants are legitimate. Implementing such a scheme with churn adds complications. Groups (which I suspect are going to increase in size), increases the difficulty further.
I responded to Davids question directly:
I think a group split is fundamentally going to be racy with churn, although the conditions to trigger that scenario might be unlikely.
For example, consider group 0100 with members: [01001000, 01001100, 01001010, 01001001]. If this group were to “split” into 01001 and 01000, then the latter group would have no members since no node in the set matches that next prefix.
That’s why a group just can’t split in an instant. It needs to create consensus with other close groups before doing so.
For example, assume that group G(01) just got a new member, the new member is now fully connected and the group is ready to split. Assume that it is currently connected to G(11), G(000) and G(001). Every member of G(01) now sends a GroupSplit(01) to all its contacts. When these messages have accumulated in all the groups, every affected node now knows that there is no group G(01) anymore, but there are new groups G(010) and G(011). At this point, G(000) will disconnect from G(011) (it was connected to its members because they were members of G(01) before, but now it can drop them) but keep the connections to G(010). G(11) will stay connected to both. And G(001) will remain connected to G(011) and disconnect from G(010). The two new groups themselves remain connected to each other.
This one is important:
Every member of G(01) now sends a GroupSplit(01) to all its contacts.
Same for this one:
The two new groups themselves remain connected to each other.
There’s no disconnect before all the nodes in several groups agree on the new state in the network. And even after the split they’re still connected. No empty groups.
The condition for a split is that both parts satisfy the group requirement - currently that they have at least 8 members. A group doesn’t split unless both the “0” part and the “1” part have 8 members each.
I agree, of course, that synchronisation is a problem in general (both with this and the previous group definition) and will still need a lot of attention in the future.
thread title honestly should be “Waste of time deliberately purposed to waste everyone’s time; come join 90% of the SAFE Network forum’s focus in delaying quality and freedom”
This thread seems to have has gone full circle from FUD to unintentional hype.
It’s pretty clear that the main reason MAIDs are so underpriced is because there is so much misunderstanding about how SAFE works. Even some ex-employees who specialise in this kind of stuff have misunderstood the design and drawn irrational conclusions from that misunderstanding. No wonder it has such a low market cap next to its potential if even technical and informed people find it very hard to wrap their heads around so much innovation. You can’t blame outsiders for being sceptical or expect them to see how clever the design really is.
Complexity and ignorance/misunderstanding create the opportunity MAID currently offers. If it was all obvious and easy to understand everyone would be on board already
Ex employee thinks it wont work = FUD!
Even ex-employee doesn’t understand the basics and has to have them explained to him in great detail = no wonder it’s so underpriced/misunderstood if it that hard for qualified/experienced people to get their heads around!
TY to the forumites and staff members who took the time to clear the muddy waters for everyone who got stuck in this quagmire of confusion and ‘debate’. As a non-technical person I feel about as reassured as I could hope to be at this point.
How did you arrive at hype? Maidsafecoin was over 20k just 15 days ago when this thread was posted, and now it has tanked hard to 16,5K and heading down. Would we not be over 20K if this generated hype instead of FUD?
Well btc also jumped up a bit in that time frame which also usually causes a disproportionate drop beyond arbing fiat value. I also thought I’d explained my thinking, whether you agree or not. I certainly feel reassured having been through this process and seeing how flimsy the assault really was.
I guess it depends whether you are a glass half full or half empty kind of guy.
I don’t know about you, but I’m still very happy with where all these ups and downs are headed as far as the market perception/value go… no upset to my long term plans/expectations here, we’re basically still around ATH and the trend is up?!
I was looking in the split groups section of the RFC too, but a check for the next bit is never explicitly stated in that section. I found it listed above in the group requirements section as checking for 8 per-group before splitting (as Andreas mentioned). This was the obvious way to handle it, and the synchronization (Andreas term) / racy (my term) was referring to delayed detection by downed nodes - its possible as the split is being coordinated that all members of the group leave in the time window before the group is created (a split to empty). The inverse case is also true - its possible that the group-merge cannot be coordinated fast enough to prevent the group from losing all of its members (delayed/slow merge leading to empty group). The neighboring groups will notice this, and one of them could take up the authority (assuming data was not lost during this quick drop). A minimum of 8 nodes seems low, but the number is going to be guess until the reaction and completion time for the group-split and group-merge operations are better known.
There are so many possible solutions to your presented problem i wonder why do you even present it? I thought we are talking about fundamental problems that have theoretical solutions at best.
These are no longer concerns from a former employee. This is clearly abuse by @vtnerd disquised as legit banter. This is not DEVELOPMENT and the amount of resources commanded by this abuser is telling me he - the abuser- is in control here, not Team Maidsafe, not the devs, not the community. This is a complete failure.
I would like to see the @moderators close this thread and either move it to the DEV Forum and let it take its proper course or shut it down.
EDIT: Further, set a precedent here that similar attempts to run over the community with techno razzmatazz - legit or otherwise - will be dealt with in the same fashion.
I find it very disturbing that the most technical thread this forum has seen in a long time is the one people want to close down. So much for ‘freedom’.
Technical debate is the foundation of advancement. “Techno razzmatazz” is the bedrock of the project. I fail to see one post where he has not been civil. Do you care about short-term price or do you care about the project succeeding long term? Because if it’s the latter, I’d like to see more of this discussion from the community and the ones knowledgeable about the system. Not less.
Conveniently neglected to include my suggestion to move it to the DEV forum. So much for “integrity” Razzmatazz is used by magicians to distract and confuse the audience. Which is what this dude has been doing. If you understand clearly the necessity of this rambling worthless group of words - go enjoy it over on the DEV forum or Github where “freedom” abounds and people are measured by the legitimacy of their argument not by smoke and mirrors.
And tell us all how you come to characterize this as the “most technical thread this forum has seen in a long time”. Thats a slam to many here.
- here:
