That was bugging me. I was thinking about this a day or two not sure. I was calculating 28 / 4 = 7 and 32 / 4 = 8. Why we really need 28 / 32 to reach consensus. It will not be better to have 8 / 8 = 100% to reach that? And the performance would be better. The hackers then need to control almost 100% of the network to be able to control it. If one do not agree just kick him and select a new node to confirm until 8/8 is reached.
What do you think?
One hacker could cause 7/8, then the network wouldn’t behave.
vs 5 hackers to cause 27/32… And they would have to be 5 hackers in the same node and they don’t get to pick the node…
They can’t choose the group they are in. I don’t see the 5 hackers stuff if they are kicked right away how it can be problematic.
It’s more group and maybe more stable (Let’s think about it).
If you need 8/8 and you only get 7/8 how does the transaction happen?
A vault could be wrong for vicious reasons.
If 7/8 happen it kick out the one that do not follow the rule. We are in CPU world here, CPU follow the same rule unless there is a hacker or bad behavior. The group find another one to join the consensus and repeat the same command and it’s repeated until 8/8 aprove.
Perhaps add an option to switch to different cluster in case if those 5 hackers consistently attacking, and denying service to the cluster.
What if there is a double spend and you have 5/8 and 3/8 on each transaction?
Double spend is not possible no matter what with the design and 5/8 is the same has 20/32.
Right, but that is why it isn’t a problem.
Sometimes the answer is yes, sometimes the answer is no. But 28/32 allows for transactions to be processed that should be processed and denied if they should be denied.
If you say “Unanimous” is the rule, then fire the dissenter and hire a yes man, you are breaking the system, not making it better…
Ok, so if we have 28/32, the system will accept to keep 4 of them later? I don’t think so. The safe network will kick them out of the network.
If I understand it correctly, if you are consistently against consensus, you get downgraded. (Less responsiblity)
But there are legitimate reasons why there would not be consensus (Double spend attempt for example) Thus being outside consensus is not always a legitimate reason for a penalty.
28/32 allows for the network to continue working even if you have viscous actors. Requiring unanimous allows One viscous actor to veto the 7 good actors.
Your understanding is out of mine. Like I said double spending is not possible and no one will try it because they know that is not possible.
I understand too that you get downgraded (only if timeout is reached), but I think it should be kick out immediately for false anwser. No downgrade, just zero.
The network will continue to work even if one do not follow the rule. The group will find another one until they find a 8/8 aproval.
People will try anything and everything. Never assume “They won’t try it”
It is quite possible that things will not always happen in order. If one node is on a smartphone in Nigeria, it may not be exactly in Sync with everything else every time… We are sending signals over a vast network of different speeds and different CPU capacities etc. Network connections might be up and down, but only from certain points to certain other points. None of the vaults can trust that what they know is necessarily right… It is just what they think is right. The guy in Nigeria might have the transaction before the rest of the network does… The fact that he is different doesn’t make him wrong, Just right before anyone else knows he is right…
Kicking out dissent and hiring yes men is less security not more. That isn’t consensus – That is an echo chamber.
You don’t know how DHT work don’t you? There is only one point of address. Only one section that control that coin or that chunk. When I said it’s not possible to double spending is because there is only one point that control that coin, that chunk or everything else.
The way the network work is that everything is already synced.
For your last statement I don’t really understand. But if I receave a false data from X people that try to **** me I’ll definetely kick him out.
I am pretty sure understand DHT.
If I send two requests at the same time from two different networks, Those are always going to be routed to the 32 nodes closest to the coin for approval.
I don’t think that means that they all receive the request at the same time or in the same order. Networks have latency.
So, unless 28 of 32 hear one request first, they will both be rejected. But those who dissent are not necessarily wrong. They are right to be wrong. The fact that they are out of sync is because they are out of sync. And that is a legit answer.
In informatique it can have timeout, but it can’t have wrong answer. The consensus will wait for the answer but if the one that are far that receive the request and return a good answer, everything is fine.
I don’t know what you are trying to say here, but I begin to have hard time to answer to you.
Hopefully someone more “Crypto” can chime in.
I think 28/32 has a very legit reason… Mainly that One hacker node will not have veto power. I do not think you can “death penalty” nodes for being wrong, because the purpose of trying to find consensus is trying to find consensus, not trying to manufacture consensus. If you fire the dissenter and replace him with a “yes man”, you are manufacturing consensus.
In the white papers and descriptions I have read about maidsafe, I have seen the term “demoted” not “kicked out” But I have not read the code, so we can leave that question to the folks who know it.
I completely agree with you. But having a false answer is just not make sense to me. That’s because the one on the other side don’t run the proper software.
About your yes no man is difficult to understand. It’s like we have to keep the no man all the times. I just don’t get it.
At the end it’s not the choice of one node, it’s the choice of all other nodes that agree so the bad node will not be kicked be one node but all the nodes that agree.
EDIT: I don’t speak about how it work currently. It’s a suggestion and nothing about paper or any other document is relative to this.
It boils down (others said it before me) to
The attack vectors is as important as the reduce ability to reach consensus and to detect incorrect consensus.
The first attack I thought of when you require 100% consensus is one of a botnet, or even large groups which decide they want to disrupt the SAFE network. The mobilise large number of PCs to get themselves as part of a large number of groups, then deliberately disagree. Then the network is unable to work efficiently. If done with enough and often enough then the network may begin to have noticeable issues. remember that one PC can have multiple nodes, so a few hundred PCs can cause a lot of groups to be disrupted.
When the network is of a large size the following is reasonable to happen
When you have 28/32 consensus this does not happen because it is extremely difficult for any large group to get 5 nodes in any one group let alone in enough to be noticeable. Even 10,000 or 100,000 nodes controlled will see it difficult to disrupt even 1 node in a decent sized network
But when you only need one node in a group to disrupt it then huge problems and the attackers can simply get more groups controlled simply because of the number of nodes and only needing one node per group. 100 nodes can disrupt 100 groups, 10,000 will disrupt 10,000 nodes and so on
I agree with @neo that a %100 consensus would open the door to DOS attacks.
But I have 2 questions:
I don’t know enough of statistics to be able to answer to this one:
Is a 7/8 consensus as secure as a 28/32 consensus?
And then we can find the following definitions in routing/src/types.rs:
pub static GROUP_SIZE: usize = 8;
pub static QUORUM_SIZE: usize = 6;
This 6/8 consensus doesn’t seem secure at all to me.
Are these values in the code correct?