Sybil Attack Protection

[domschiener]

Currently the system handles votes through an IP-based system, meaning 1 IP == 1 Vote. If you have already voted on a poll you will be automatically redirected to /voted and won't be able to vote again.

The issue I have with this current implementation is that it doesn't solve the sybil attack problem, since the barrier to cheat the system is still too low for an attacker. Proxies, VPN's, etc. make it super easy to change ones IP, and thus being able to vote again and influence the out come of a poll.

I think that the only true solution to this is a decentralized identity system that solves the sybil attack problem by design, but currently there is no such system in existence (or even in development). So what do you guys think, what is a better solution to the current IP-based restriction system?

[domschiener]

I will actually work on OAuth integration so that users can view, manage and vote polls through their Twitter, Facebook and Linkedin profiles.

[Neozaru]

To me, this is the biggest question when it comes to real usage of this kind of system.

For fun :

• No specific protection. Everyone in the world can vote. It will require gas. Multiple vote from one individual will require more gas from this individual.

Non-critical :

• Users need to register before being able to vote. The registration could occur in multiple ways :
  • Emails : Accessible to everyone, but it is easy to get multiple mails.
  • Facebook : It is harder (or costly) to make fake Facebook accounts. I personaly don't like the idea of being registered to a centralized data-mining system, but would be fine for a PoC.
  • Phone number : More viable than the two first options, but it still needs a lot of legit voter to absorbs multi-votes. Plus, not everyone has a phone number.

Critical :

• Official identity information.

I guess both Non-Critical or Critical require some kind of "public whitelist", and this raises new issues :

1. We have to be able to count only votes of member included in the whitelist.
2. The whitelist needs to be public.
3. Vote choices should remain anonymous - or at least pseudonymous (public key not associated with identity).

So I imagine that the third party could generate a public/private key pair for each voter, and publish all public keys as the whitelist. Then each client would have to sign the transaction with private key. (plus the regular etherum signing process which would remain fully on client side).
But checking the signature in the contract... would cost a lot of gas/money.
If we decide to store the whitelist in a contract, it is even worst.

Any thoughts ?