Hacker News new | ask | show | jobs
by honoredb 2382 days ago
This is a nice explanation and a cool solution. I amused myself a bit ago by trying to come up with a solution for these two constraints without reading about the crypto work, and ended up with something different. In my scheme, a voter casts a vote for a candidate and gets a receipt with the UUID of the vote, which is simply mapped to the candidate so that they can verify it online later. However, the voter can also cast any number of additional ballots, which are constrained by the system to be pairs of votes and anti-votes, each for the same candidate, and get receipts for each. For example, I support Harker, but I've been paid to vote for Dracula. I go into the voting booth and cast my vote for Harker, getting Receipt 1. Then I press an extra button to cast a fake vote for Dracula, and get Receipts 2 and 3, with 3 being a special negative ballot. I can show Receipt 2 to my briber, who can verify that it corresponds to a vote for Dracula. But secretly, I can use Receipt 1 to check that my vote for Harker was counted correctly, and Receipt 3 to see that a negative vote was also cast for Dracula, cancelling out my bribed vote.

You need to allow each voter to cast multiple fake votes, otherwise the briber/coercer could simply demand receipts for a fake vote in addition to the real ones. Could get a bit unwieldy. But the big advantage is that there's no extra complexity for the average voter, since they don't need to cast any fake votes.

6 comments

The machine could give the same UUID to different voters:

- Voter 1 votes for Harker

- Voter 2 votes for Harker, gets the same UUID. The machine casts a vote for Dracula instead

It could also cast any number of fake/counter votes without the voter knowing.

You make the ID be a hash of a UUID and the voter’s name.
That allows proving who cast which vote. Instead, you could generate the ID when the vote is cast using a coin flip protocol.

Some effort would be needed to create an actual proof that the coin flip protocol doesn’t allow the voter to generate any sort of proof that they participated in the coin flips. I think the usual schemes do have this property (at least, they do if the parties don’t collide), but I haven’t seen this specifically proven.

This sounds like the method from the Rivest, 2006 paper: https://rcoh.me/posts/verifiable-voting-primer/#fn:triple
There couldn't be any limit on the number of votes/receipt for each person. If you could get a maximum of N receipts, then you could be paid to deliver all N receipts so they can be sure you haven't snuck in any additional votes.
Maybe require that additional votes be different? Then they wouldn't be able to tell which was legit.
That doesn't work with proportional representation though.
How so? The number of votes cast for each candidates is unchanged after you add the numbers up.
You're right, I misread.
How would an observer validate that only eligable voters voted?
The easy way would be to pick out a limited subset of votes and require voters to produce the receipts for them. It's not ideal since this makes the system more complicated for voters and voters are forced to use fake ballots if you want plausible deniability, but it works.

Then again, this is also a problem with existing methods isn't it?

> The easy way would be to pick out a limited subset of votes and require voters to produce the receipts for them. It's not ideal since this makes the system more complicated for voters and voters are forced to use fake ballots if you want plausible deniability, but it works.

What happens when some of the voters fail to produce the receipts? This seems inevitable even assuming good faith, but especially if it could be used to cast doubt on the legitimacy of the winning candidate (and it wouldn't even require voting against one's real preferences, given the existence of 'fake votes' in this system). Just deleting the unverified votes won't achieve much, if only a small subset are being tested.

That's pretty clever.