Skip to content
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

Open
kettle11 opened this issue Feb 20, 2023 · 3 comments
Open

Harden Tangle to Malicious Peers #11

kettle11 opened this issue Feb 20, 2023 · 3 comments

Comments

@kettle11
Copy link
Owner

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.

@DiogoNeves
Copy link

Would you consider a simple majority consensus logic based on something light (e.g. some hash)?

@DiogoNeves
Copy link

DiogoNeves commented Feb 27, 2023

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)?

@kettle11
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants