stonecoldpat / anonymousvoting

Anonymous voting on Ethereum without a tally authority. Protocol from this paper http://homepages.cs.ncl.ac.uk/feng.hao/files/OpenVote_IET.pdf
341 stars 92 forks source link

Is it possible to avoid to restart the protocol if someone doesn't vote in round 2 ? #10

Closed descampsk closed 7 years ago

descampsk commented 7 years ago

In the paper "Anonymous voting by two-round public discussion", they discuss about the limitation when some voters refuse to send data in the second round.

They say that in this case, we have to restart the protocol.

Is there a solution to avoid having to start the process again and still manage to compute the tally?

In a real election, there will be some voters who will register but won't vote in the second round ? This case seems to me inevitable. If there is no solution to this problem, then it seems that this protocol can't be applied in real life :(.

stonecoldpat commented 7 years ago

Hey,

Yes, it is inevitable that this protocol requires 100% voter participation. It is worth mentioning that this is the consequence of a fully decentralised election protocol - which is the most extreme version of an election (i.e. voters don't trust anyone!).

In terms of being applied for real life - the protocol is suitable for small groups of people (i.e. 10-20) who mutually distrust each other. One idea noted in the paper was that each voter can leave a deposit which is returned upon voting - to provide an incentive to actually participate. Now, if we weaken the assumptions in the protocol a bit (i.e. make it less extreme) - it is feasible to add a central server that is responsible for computing the ballots.

Each voter is anonymously given one ballot (i.e. if this is in a real board-room the voter can pick an ethereum account and voting key out of a hat. I imagine a blind-signature approach could probably be used - the point is to obfuscate the voter's identity and their voting key - but ensure each voter is given one ballot). Next, each voter can cast their vote, and after the election is finished, the central server can publish (and spoil) the remaining ballots. This would still provide a publicly verifiable election (i.e. no counting staff - anybody can count the votes) - although it would not allow the system to identify that Paddy has cast his vote.

The above approach is similar to what DRE-i is doing: https://eprint.iacr.org/2016/670.pdf

DRE- relies on the same cryptography as the Open Vote Network but in a centralised environment. For example, voters visit the polling station and are given a random password to login (or what we have done in practice is to pick out of a hat). The voter can login to the website and cast their vote. I remember that Newcastle University have a working prototype of DRE-i without using a blockchain at the moment - but the blockchain is useful in terms of acting as a public bulletin board (like in OV-net).

So if it were me - I would probably offer both options. The decentralised option where a voter doesn't have to trust anyone but themselves, and the centralised option where there is a little bit more trust, but allows the protocol to handle voters aborting.

In fact - this is useful to read - it shows how OV-net emerged and eventually resulted in DRE-i.
http://homepages.cs.ncl.ac.uk/feng.hao/files/Chapter13.pdf

descampsk commented 7 years ago

Thank you for this complete response !

I will look and read this two papers to understand in details the DRE-i system.