SAFE Network concerns from an old employee

I’m swimming. :thunder_cloud_rain: :cloud_tornado:

1 Like

That sounds very interesting. But maybe just 1 hour, if it’s every week.

We could start a thread on here and everyone asks questions that they think are important to know about the network, and we vote on which ones are best each week, to fit into the time slot.

If this had existed, it may have helped prevent this FUD attack, because there would have been an open place where people can Voice their questions and expect a thought out answer.

Also, maybe don’t have it on a certain week, if not enough / no questions are posted

3 Likes

Why don’t we just compose, pin and update a Q&A on this forum. As new unanswered questions arise, they could be added to it along with the answers. I vote @polpolrene aggregate the current data. He has been around for as long as the forum has been operational and he has in many cases attempted to clarify and nuance most aspects of the SAFE protocol. We as a community would of course help to carry the burden whenever and however we can. His moderation duties have no doubt been a heavy enough encumbrance. What say ye @polpolrene my man?

It would be immensely helpful. :pray:

8 Likes

He is hardly a nobody. Read through the forum history for this guy and you will realise he has a lot of knowledge and I say this as a software developer. This is why I was concerned.

I am confident that David and the team have things in hand, but sometimes reassurances and explanations are needed in such situations.

Moreover, not everyone is a politician. I know a lot of technical guys who are far from the best communicators and have little enthusiasm for playing mental games. The nature of their contributions may be clumsy, but rarely malicious in my experience.

10 Likes

Some contract devs are experts in their fields, which is why they choose to contract. They are confident that their skills are sufficient to shun the safety of a permanent job. Moreover, this particular contractor was vocal and technical on this forum in the past.

This isn’t to say his words are gospel - he admitted above that all his concerns may have already been addresses. However, he isn’t some nobody and if he was, we wouldn’t have taken his thoughts nearly as seriously.

There is a lot of good work going in to maintaining data consistency (e.g. Data chains), which looks to be addressing these concerns. Hopefully, we will see the fruits of these soon.

5 Likes

Maybe he was actually gentleman enough to wait a year instead of laying it all out immediately (a year ago). Actually, on that note if he did have concerns a year ago and shared them, maybe it would’ve gotten the devs thinking about how to solve them sooner. (Although, the delay/worry it would’ve caused might’ve been bad instead of good?) Anyway maybe he was just apprehensive about talking about it until now; I don’t know! Just some thoughts. Either way it’s all “would’ve has-been”-s now (not sure what that word is, but I’m going with it), just something to look at occasionally to see if there’s something missing.

Apparently there’s been some discussion of this on the Metz Dowd email list. No idea what that is, and the tech aspect of this is out of my wheelhouse, but I was discussing the matter with someone today and they felt the issue was unresolved (even though I sent him to this thread) and suggested someone from MAID weigh in on that forum. Fwiw …

What issue though, is there a specific flaw or aspect of security that is identified that is not answered (beyond what if the unfeasible was still possible (it is), like you could create satoshi’s private key at random)? If so we should provide an answer or point to the appropriate paper etc. I will certainly try to answer any such issues as that is important, I just have not seen any that are relevant, perhaps it will mean pointing out why each point is not relevant, but surely there must be a limit to how many times we do otherwise we do risk stagnating launch. It’s easy if there is an unanswered point and we can answer that, if it’s based on something we do and not something somebody thinks we do (as that is too large a scope)?

20 Likes

Results are the only things that will change minds at this stage.

If we’re close to proving points then better to prove them than talk about them imo.

6 Likes

Really? Apparently? Facts or FUD? Post some facts please. When you start with “apparently” it means you dont know. Why not do your homework?

ap·par·ent·ly
əˈperən(t)lē/
adverb

used by speakers or writers to avoid committing themselves to the truth of what they are saying.
“foreign ministers met but apparently failed to make progress”

2 Likes

In a perfect world we would expect results to work. But our world is not perfect. Our world includes people who dont want it to work. People that will profit if it doesnt work. Influential people who will say its doesnt work, even if it does work.

Very little in the crypto space is about technology these days. Not unlike the mid 1990’s when just having a website got you attention form VC’s.

Today is about greed and everything you read must be read using the “GREED FILTER”.

2 Likes

Fanboy just seems like a dismissive, umbrella term. Of course we’re fans (only speaking about me and whoever it applies to), because we love the potential of what this could be. I personally feel that it will go online and end up being a huge success. We can’t stay in the dark ages of information suppression and surveillance forever can we? I’m not saying Safenet will end that but it surely can be a huge leap out of it. I think there’s a difference between cold investors, and investors who share a connection with the project, on whatever levels those may be. I’ve also learned patience in the crypto world.

What would concern me more is if Maidsafe pushed the project out too fast, just to get it out there, only to have it run into a breaking issue and get DAO’d or something. Thinking about it, it’s kinda strange how DAO was just thrown into the wild with a $200mil target on its head, while Safenet has so much more potential and the devs are being more careful, with not nearly as much support. I guess when it’s live people will (myself included) just end up regretting not putting more money into it sooner. :stuck_out_tongue: For me, I’m more excited about what this could turn into than the money I could get from it, but that would also obviously be great.

6 Likes

Ha! I love it. Getting DAO’ed, nice One :wink:

1 Like

I for one can’t wait to upload my entire site to the Safe Network.

4 Likes

I can’t wait for everyone on the planet to have free access to all information.

Think of the progress that will be made once humanity is unleashed

4 Likes

Edit: correct typos and grammar

Have you seen something closer to an actual algorithm or description? There are some critical parts missing. How do the other nodes verify that there was no collusion when generating the ID?

We are talking about different things. In my prior posts “partition” is referring to the possibility that multiple SAFE networks could exist simultaneously. For instance, imagine if a data center went offline entirely. The SAFE nodes inside the data center will think that the remainder of the world lost connection, and continue to operate. The rest of the world will do the same. Its not possible to know whether the other machines went offline because they lost power, or because of faulty network between them. This is rare, but adding an adversary increases the complications.

This does not help with partition tolerance. Each side of the partition could have a different owner, so which is correct? Ideally the algorithm discourages people from intentionally creating partitions in order to change ownership.

I strongly dislike the current group design that never tries to achieve consensus with other members of the group. Without this, even legitimate nodes can have different versions of history if there are two writers. An adversary is going to see this as a potential way to “flip” ownership of a resource back to themselves after some time period. For example, an adversary could create two messages for changing ownership of a single resource where each message changes ownership to a different key. The adversary would send both messages roughly at the same time, and continue this pattern until the quorum in the group is lowered (ideally at min quorum value). The nodes that are not in the quorum will have a different history than the ones in the quorum. The adversary could then sign over the resource to some victim, which would pass the “read” quorum. After the victim thinks the transaction is complete, the adversary could DDoS a couple of machines in the quorum after the exchange. If the network tries to repair the lost quorum due to the machines being inaccessible, it has to decide between two choices that are equally valid now that “quorum” has been lost. Increasing the size of the group does not improve resiliency in any predictable way.

If you or no one else on the team have not thought of this before, really think about that problem and how it would have to be solved. I am fairly confident it will be difficult in your design for the reasons already stated. This is closely related to the partition problem, because even legitimate nodes are unaware of the different states of the resource.

I have been avoiding this because it is impossible for me to prove this to anyone. But for those interested -

I have never owned nor speculated on any crypto-currency. I have no immediate plans for changing that. This post has led to someone contacting me about freelance work, which was not expected or intended, and I have not decided what to do about that.

Revenge is more difficult because I think your subconscious is always going to affect things. I feel no animosity towards anyone at Maidsafe, and have conflicting feelings about whether posting this was ever the correct decision. Frustration is probably the most accurate word here.

I would encourage everyone to learn more about this problem area, and to read the code themselves. If more people become confident about their knowledge of the codebase, comparable systems, research papers, etc, then they can answer in the place of David. Even the questions I direct at David in this post should realistically be responded by others if possible.

There was unlikely to ever be a “good” time for this.

I think I am decent at communicating my ideas and thoughts, but its hard to self-judge. The difficult part is separating what I said against the people that agreed with me. Stating that I worked for Maidsafe made it easy to find that out (going to my website would’ve been slightly more difficult) and allowed them to spin the story as an authority figure speaking out against the project. If I wanted to sound completely authoritative, I would have emphasized my knowledge of distributing computed. I did the opposite.

I initially had some strange mini-bio in that first paragraph, but dropped because it seemed awkward and unnecessary. I do not even recall my thinking behind the “I worked for Maidsafe…” sentence because the focus was on the technical content. I do remember wanting to indicate that I was less certain in the area of distributed computing, primarily because its extremely difficult for me to say with 100% certainty that “no solution exists”. I am reasonable certain that the current design is going to be headache inducing for anyone focusing on the security.

Someone asked for opinions on Maidafe, and I responded. That is it. I would not call that a discussion. I have searched for all the places that post was discussed, and I think @polpolrene and @yvon.fortier might be the only people trying to engage in meaningful technical discussion as a result of it.

4 Likes

Definitely appreciate the thoughtful responses and time taken here to carefully reply. Seems like you don’t necessarily wish the project harm.

2 Likes

How could two nodes exist in the same address at all? This is a pretty basic step. Have you seen a way two nodes could exist in the same address. Have you ever seen a way this could happen in any version of the routing table code?
[edit @Seneca corrected me here, I had not read collusion, however with non persistent nodes it does not seem an issue, the points below seem to be where your trouble is. BTW it’s good you got some positive attention and a job potentially, good luck there chap.]

A partition does not have an owner? Data may do though and you need the cryptographic key to alter that data (and of course you need to be on the network to do so). Partitions are not an area we have focussed on but without shared private data and in current network I fail to see how this is an issue we should be distracted with at the moment. When looking at shared private data then of course it requires consideration (if consensus on change could happen with less than quorum agreement, which is very unlikely), so this is not on the critical to be looked at list now (as it’s also not in bitcoin).

Of course it is an area for much research for all decentralised and distributed networks. Lets focus on the now instead, it’s more productive.

This is about routing code, but is this what you think happens in the MaidSafe design? It never has been like that, quite the opposite. Perhaps this is where there is misunderstanding. Group consensus is the group coming to agreement (cryptographically signed) and it does so even during high churn. Can you elaborate here how group consensus works in your view of the design and implementation.

If you can outline how group consensus works and churn is handled then show which part you believe is incorrect it would be really helpful?

Separately then do the same for node joining (which is currently unrestricted but does force distribution).

These two points will help us all understand your issue here. It will also help the conversation to be based on fact rather than an apparent confusion.

17 Likes

Not collision, but collusion, like conspiracy.

2 Likes

Ah thanks @Seneca I missed that.

This is currently not possible. You would need to get your address the give it to somebody for them to “start”. When you start a node you cannot join a group as you are forced through the joining process. This is the case and has been for a very long time now.

In future archive nodes may have the ability to restart but will not get to quorum. In any case right now this is not possible and has not been for a long time. This was also the case whilst Lee was at MaidSafe, vaults were not persistent and a new vault meant a new key and a new address. Regardless of which key you create you will be re-located to another part of the network.

[Edit to then collude in the relocation process you need to be in the first joining group which means you got through group consensus etc. (atm we only consider the 2 closest nodes which is not correct it should be at least quorum) however it’s the last few points that seem to be the confusion so we should focus there I think. In terms of joining there is an RFC going through to make continual attempts restricted, which is a security issue that’s known and clear also with clear solutions]

13 Likes