@dirvine Let’s say a routing node r sends a message to a close group. How can the group ensures the message indeed originated from r rather than an attacker a, forging a message to look like it is coming from r? I am assuming here that in some cases no member of the close group is directly connected to the sender.
Single node → client → uses digital signature, we retrieve the claimed identity packet, and extract the public key to confirm the message is signed by the client who it claims to be. (We may be a client manager, i.e. in the closest groups to that id).
Single node → routing_node → Again signature, but we already have public key (or we would not have connected) we are also connected to this node if we are a manager of the node (so NodeManager personal type). If the signed node is not in our routing table then it’s not a node from the network perspective.
From group → we get all the group messages (accumulate) and send a find_group message, this is routed (using loose parallelism) to the target group. This returns all group member’s of the claimed group and we confirm they are the same as the claimed group. We also confirm the digital signatures (find_group returns all public keys of group). In this case we are also the group around the address of the element (data or functor) and we know that So the non deterministically connected group is confirmed via the sentinel.
I should add for Get requests we don’t care.
Are there any mechanism to rank down malicious nodes that might not be relaying messages correctly?
Yes the sentinel will down-rank (remove nodes) from the network that do not obey the account transfers. Account transfers are a great measure of a nodes capabilities on the network and shows it at least managed the accounts properly. For storage nodes then this is even easier as they must give up data when asked and also manage to pass Data Integrity Checks. These rules will extend during testnet3/beta and prob beyond. They must be simple though.
For reference later as we progress this language