ETH’s success is not just technical, they have a very open-minded, outward and cooperative and conversational development team, which is what are lacking in maidsafe. I invested both in maidsafe and Etheruem ICO back in 2014 and I think we do have a lot to learn from Ethereum in terms of execution, community engagement, ecosystem building and leadership. Maidsafe had a lead time of 9 years when it ICOed, but ETH is now 70x larger in terms of valuation with a live network and robust ecosystem.
With equal complexity(if not less) , maidsafe are still struggling to prove its non-vaporwareness. It’s really disappointing to see maidsafe dev team still so disengaged from the wider community and that’s part of reason of the stagnation and I do think David bears major responsibility for that.
Besides Ben, you also had the contractor Lee (vtnerd), who had some remarks, discussed in this thread. With 229 posts in the thread, it seems to me it is safe to say his questions and remarks weren’t ignored.
You may or may not be aware but we also were part of a crypto security / economy mailing list Vitalik and others set up to discuss deeper parts of consensus etc. Hours and days were spent there as well. Is there a specific question you feel was asked and not answered, if so perhaps I can help. If it’s group security then there are a few things we do such as node age, data chains, routing table recovery (for collapse). In design we look at other similar protocols for decentralised networks, like paxos, tangeroa (signed), PBFT, async PBFT and more. There is not much research in terms of papers but it’s for sure getting better. Nodes getting bribed is hard as they change ID’s and groups as they do, restart of a node means new name and less age etc. If X fail all at once, then we consider mass loss and how the network handles that (it’s via group merges) to shrink number of groups to match existing population. So loosing X from a group will force a merge to a larger group etc.
With any system though there is always a break point, this is where the consensus just gets way out of sync with requests and churn etc. These questions are continually asked in code and answered, so far. There is no one answer to “how does the network decide” or “how does it repair” that we know of that’s simple enough to put in a short description. Then the question needs to be how can it restart on mass failure, this is where data chains kicks in to validate previously stored data.
In terms of breakages etc. we see DHT’s combating this all the time, bittorrent DHT and others and now IPFS is charging ahead there, albeit focusing more on interoperability where we focus more on the security and data availability side. Both are rather complimentary in research terms and possibly in real terms, but we will see over time. We have not had enough chance to confirm how complimentary they are physically,
I have written a few blog posts, rfc’s, papers and patents all describing parts of the system, the community and maidsafe team can multiply that by factors. The reason there are so many of these is the size of the research area and the desire to launch but with a system that is understandable and based as much as possibly in simple rules.
You know you are replying to a 2 year old post do you??
Here you are…[quote=“Kingslanding, post:18, topic:3542”]
When an ex-employee questioned this project last year, all questions raised were also ignored and dodged.
[/quote]
Yes, it is not a crypto project as such. Just one little portion of it involves a new crypto coin. Like saying your car is a financial product because you need money to pay for fixing/fuel.
I think that crypto is a special case of the problem MaidSafe is solving, which is storing mutable files. Token ownership is just a special case of file access. You can either replace the content of the file (as with safecoin) or append to it (as with ever-growing histories).
Also I would say that Vitalik’s criticism here isn’t of the Maidsafe consensus algorithm, but rather of the section size in Kademlia. He wonders whether such a small number of computers can be enough to prevent double-spending when money is on the line. A few things need to be pointed out:
The amount of value in transactions that can be reversed by double-spending is proportional to how many sections you can compromise. However, this by itself is not enough as a virus or sybil attack can cause a serious problem, that can lie in wait for a year and then destroy the network.
The actual math shows that the probability approaches zero fairly quickly even with a small number of computers provided that only a small proportion is compromised
The consensus algorithm matters a lot.
At the Intercoin project we developed innovations to be resilient to 33% malicious nodes, which you might want to take a look at over here. What’s interesting is that our consensus mechanism also got criticized by Ripple’s chief cryptographer on our forums, but he admitted at least that it actually works and did not point out any security problems with it. So it might be useful for MaidSAFE to adopt some of those ideas!
By the way if anyone wants to chime in about any of these topics, you’re always welcome to pop over on our forum. We just started it recently and welcome any sort of discussion (pros and cons) and criticism same as I’ve been doing here.
