@anthro brings up a number of good points. I generally try to ask how such issues will be overcome, instead of stating that they are flaws in the design and that the fundamental concepts must be scrapped, but that is just me. We should discuss the questions, whether or not his apparent lack of social graces are intentional.
In my conversations with the Maidsafe team, it has been clear that these issues have been well considered. There is no public code yet released for ranking or consensus chains, so there are not currently definitive answers to these questions. I personally have faith that these issues will be solved by the team. This is based on the innovative and elegant solutions that exist in the current code base as well as the well reasoned arguments provided by the team. The combined concepts of encrypted deduplication and security through immutability are beautiful, IMHO. While there are issues to be solved, I don’t see any intractable problems with the design.
As others have said, this project is very different from Bitcoin. Bitcoin is surprising in it’s elegance and simplicity. The blockchain can be explained in nine pages. I can read the whitepaper and come out with some level of confidence that it is a viable solution. I don’t think you will catch anyone saying that safecoin is simple or easy to understand. There is true innovation and genius in the maidsafe design, but it personally took me a month to get my head around it.
Here is my cocktail party explanation of the concept of consensus:
Every coin has a record stored on the network with a coin ID and an owner.
Within the network, there are a set of nodes randomly chosen to act as the manager of a given coin. A group is currently 4 nodes.
When nodes enter or exit the network, churn events are generated. These churn events will periodically change which nodes make up the management group for any given coin.
There are a set of rules that define how a coin record can be changed (for instance, the current owner must sign a request to transfer ownership).
The management group is responsible for maintaining the current state of the coin and for validating any change requests. 3 of the 4 members of the group must sign off on any change for it to be valid. Similarly, when you request the current state of the coin, you must get an answer from 3 of the 4 managers for the response to be valid.
Now, 3 out of 4 nodes is not secure enough for a currency, so this is where the chain comes in. Each of the 4 manager nodes has a manager group of its own. All actions and responses of the coin manager group are monitored by the node managers. In the same way as with coins, any action must be signed off on by 3 out of the 4 members of the manager’s management group for it to be valid. This management of manager nodes concept can be continued to chain as many management groups as is required together. In this way, the designers can choose how many nodes must be included in any decision to reach consensus. This is in contrast to a blockchain based system where every node in the network must validate every transaction ever recorded in the chain.
This description naturally brings up a number of questions, a couple of them being:
How are nodes randomly chosen to form a group.
How is communication to/from/between groups and members done.
How does one verify which nodes are required for consensus on a given coin, and how do you verify all the nodes agree.
What level of security does each level of group chaining provide.
etc.
These are discussed elsewhere (mostly on the google group). I will touch on the Sybil attack though. The below is my understanding of the plans. Again, there is not yet any code to back any of these statements:
There is no absolute defence against Sybil attacks. Bitcoin doesn’t provide one either, the 51% attack is a Sybil attack. The goal is to make the attack so expensive to perform that it is not feasible. The size of the network is the main determinator on how expensive a Sybil attack becomes; the larger the network, the less likely of a successful attack.
The first line of defense is the fact that a node is expensive to run. A node must provide an amount of storage space and it must respond to requests in a timely manner. The number of coins a node may be responsible for is directly related to the resources it provides to the network. If an attacking node does not participate productively in the network, it will be pushed to the outskirts of the network, increasingly ignored by the other nodes.
The next line of defense is the ranking system. In order to increase and maintain rank, a node must continue to expend increasing amounts of storage space and bandwidth. There is also a natural limit to the speed at which a node may acquire the higher ranks. A malicious node may need to spend weeks working as a productive member of the network before it has a high enough reputation to participate in the attack. The exact parameters have not been set, but consensus groups will likely be made up of nodes with varying rank, which will drastically increase the complexity require to successfully implement an attack.
Finally, it is not possible for an attacker to flood the network with a large number of fake nodes, all of them validating the rank of each other.
First off, the rank of a node is maintained through consensus (in the same manner as coin consensus). Synthesized fake rank then becomes a chicken and egg problem. The attacker can only set his nodes’ rank once he gains enough rank to be responsible for managing rank.
The best an attacker could do is create a self contained evil network, parallel to the real one. When the network is first initialized, this is protected against through centralization, but the centralization requirement fades over time. Let us consider a mature network that is several years old and has hundreds of thousands of nodes.
Nodes join the network and discover other nodes within the network based on known nodes it has communicated with in the past.
A mature network forms a graph of inter-related nodes (much like the reputation graph in a community of people). This effectively limits the evil network to a MITM type attack, which would be very challenging to perform due to the nature of the routing layer (I can go into more detail on this if you need).