-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harden Tangle to Malicious Peers #11
Comments
Would you consider a simple majority consensus logic based on something light (e.g. some hash)? |
Potentially misunderstanding the suggestions here, but it could also seat quite well with the solution to #7 (Dirty Flags) and a simple majority based on the content hashes of the deltas (which may require comparing a list of hashes if multiple changes are being synced)? |
Yeah, hashing is likely the solution to detect and resync peers who have desynced. The issue I want to prevent is a malicious peer sending bogus messages (or omitting messages) to just one peer in an effort to sabotage them. Imagine an evil peer (we'll call peer E) is in a room with a bunch of others and they want to sabotage peer A. Peer E could send A a bunch of bogus messages causing peer A to continuously desync. Hash consensus could be used by peer A to detect that it's desynced (and likely something like that should exist anyways) but it will still give peer A a degraded experience, or at least give peer A increased latency. Is there a better way? Another issue is when joining a room how can a peer know it's being sent the correct data? Likely a peer should receive a hash of the room state from a few peers and the full room state from one peer and then verify the hash itself when it receives the room state. |
If a peer is malicious they should only be able to cause a bad experience for themselves. Tangle should be audited to find any potential ways a malicious peer could intentionally desync another peer. In scenarios with only one other peer this is likely impossible to do perfectly, but in rooms with 2+ peers it's should be possible to verify and reach consensus. In some cases a peer could be designated as a source of authority that all peers should defer to, like when running an authoritative server.
The text was updated successfully, but these errors were encountered: