- You have
Expiration for both
query_message, but no timestamp at the message, how to handle this
"expiration" : 600?
Timestamp will be added by the node. Because there is one instance of the message on a single node, the node will use current time as a timestamp.
- In case a bad player, what will happen if his/her node broadcasting
query_message to the network at 1M Msgs/s for example?
push_message in case of bad player affecting only player’s mode. There messages are not broadcasted, they will stay local on the node that player control. The ‘public’ node can be affected, but eventually we want every wallet run it’s own node. That is why I think it is acceptable.
query_message does broadcasting, so attacker can do DDOS with that. We need to be able to ban such nodes effectively. The request will come from the peers, so it can be banned. It is expected that first ban will happen for largest depth, it it is not, it is mean that that node is a bad player, so it will be banned by the next level. The problem is how to recognize if that message is originate from the same source. I will think about that. Currently I am thinking of using output with some significant amount (like 10 MWC) as a collateral (that output will not be private any more). Outputs are limited resources, so for ddos attacker will need many of them and it is impossible to achieve.
Actually, if everything cacheable, we can just ban the node that making too many requests. I think we can keep it simple. My point that we don’t even need to know the source of the request. We can ban the peer if we are getting too many income requests from it. Bigger deepness, less request frequency will be allowed. Look like even this simple model will work.
- What’s the system capacity and cost for example in case of 10k nodes + 10k wallets(users)? i.e. the estimated total messages in one second, in case of a typical querying in every 5 seconds for each wallet.
We are talking about
query_message, because it is broadcasted. (push_message is fine, it is local). Let’s say the deepness for the call is 10. In this case the all 10k nodes probably will be reachable.
The are 2 use cases: swaps and traceability.
For swaps keys are will be very similar (the same keys combinations for every coin), so the nodes will build a cache pretty quickly. The first call will be broadcasted for all nodes, but the next ones will hit the cash.
For traceability - the same. There is no keys variation, the data request will be cached.
We will start having issues when there will be too many use cases. With such approach, every use case add load to the network. But I think it is fine.
Also please note, request has response size limit, that is why cache size will be limited to some relatively small amount. There is no need to store the data from whole network.
About the traceability. Thank you for your inputs, really helps. Looks like “Traceability with Multikernel” is a winner. Decoy has too many downside and potential to degrade the network (if decoy outputs are never spent, that will kill the network scalability). Traceability with Multikernel using MW natural feature and doesn’t add much complexity. I don’t see why we should do something extra.