Topic: The global decentralized secure electronic voting system is up and running - page 2. (Read 10533 times)

Ok, now I get it. The organization knows the key it gives to each voter and knows the 100 votes but not what voter has issued what vote.
In your example, if 60 vote to A and 40 to B, they don't know what each of these v1...v100 have voted as long as they don't vote all the same.

Next question.
How double voting is prevented?
v1 sends one vote for A and 2 votes for B. How the system knows that the second and third votes are invalid and don't belong to, say, v2 and v3?

It seems to be a really difficult thing for me to explain this to you - but as I'm still relatively new I'll do my best.

There are *less* keys (much less) than votes so that the votes *cannot* be mapped 1 to 1 (otherwise of course you would not have anonymity).

So lets say we have 1000 voters and we've decided to use 10 secret keys. Thus one secret key is shared by 100 voters.

In order for those voters to avoid sending their vote to another voter using the same secret key we label each group of 100 (which I termed a batch) with a simple # (i.e. batch 1..10 in this case as there are 10 secret keys). This batch label is *not* encrypted so that a voter makes sure they will pass on their vote to someone that belongs to a different batch.

Are you with me so far?

I still don't see the point. Can you answer my questions below?

I don't really understand what you mean by batch here. A set of keys for each voter?
How do you map the n / x keys to the n voters?

I would be VERY HAPPY if there was a system for decentralized voting. I would mail the Gerald Celente's "direct democracy" and spanish's "Democracia real ya" (real democracy now) crew and all, but I still see it NOT_FEASIBLE.
I expect a surprise on this technical issue nontheless, but sorry, your proposal doesn't seem to meet the constraints.

I will read Ben's proposal when he learns how to write less than, say, ten lines. I have an hypothesis but not the time to make it become a proper theory: "It is impossible to go offtopic on a thread started by BenRayfield, even if your talk about the wheather or the sex of snails". He has covered it. Hi Ben, in case you read the threads you start.

There are not x voters and n keys - there are n voters and n / x keys. So there are less keys than voters. See?

Ok, so there's n keys and x voters.
How do you map the n keys to the x voters?
I think this shuffling algorithm runs on the organizers server so they will know the mappings between k(i) -> v(j). The key i belongs to the voter j.

Yes, this is the part I need to understand first. I don't really understand what you mean by batch here. A set of keys for each voter?
I don't see the point if the organizers know who owns each key.

I never wrote that you have n secret keys for n voters - I wrote that you have n / x secret keys so that your vote could only be identified as being "one of n / x". I used the term batch to describe n / x and a public batch # would also be assigned to each user. This # is visible to all other users so that you make sure you pick a user *not* from the same batch to send your vote to.

There is no 1 to 1 mapping - can you understand it yet?
 
(if you get this part then I can re-explain the rest again - if you don't get this part then I don't see the point in further discussion)


Cheers,

Ian.

Say we want to elect the major of my town.
We have a pool of voters V = {v1, v2, ... v100000}
The organization generates a set of keys K = {k1, k2, ... k100000} and give them to the voters.
The organization knows the mapping between V and K so it knows what every participant has voted.
The dummy votes and the relays just may hide the IP addresses of the voters, but that could have just be made suing Tor or i2p. It doesn't makes sense because the organizers know the voeters NIF.
If you want the organization to not know what every participant has voted, they cannot know the mapping between V and K.
If you can do that, I would suggest that instead of keys for a symmetric encryption algorithm, the organizers distributed privates keys of an asymmetric one and published all the valid public keys. That way voters could sign their vote and everybody could verify the results.
But...
Where does "secret shuffling" algorithm run? How does it work so that the owner of that computer can't know the resulting mapping?

The workflow shows that they see every vote *but* they do not know which vote comes from which voter as the votes were secretly shuffled between the voters before being sent to their voting destination. So it *is* anonymous.


Cheers,

Ian.

Maybe I misunderstood something in your workflow, but can't the organizers know what everybody voted for?

Maybe you're right in your claim that achieving what I want is impossible, but is the aim of the pdf a linked and (Ben correct me if I'm wrong) what this thread claims to have achieved.

Well achieving what you want may not actually be possible but saying that the votes are not anonymous in my approach is just completely wrong - if you want to seriously criticise something please take the time to give the proof (I bothered to take the time to give you a workflow after you said I couldn't).


Cheers,

Ian.

As said, this is not a decentralized voting system. Why use a block chain at all? Just a server run by the organizers that makes the encrypted votes public so that the voters can validate the valid votes. And then trust the organizers and the third party. Also, there's no anonymity, because the organizers (and the third party) know what each voter has voted.

The system I want has the following properties:
1) Everyone can count the votes.
2) No one can know what other participants have voted.

The organizers are definitely not the only ones counting as each and every party also verfies that each and every vote is valid and in fact after the poll is completed the secret keys themselves could be released (if not to the public then at least to a 3rd party) so that they can confirm the vote payloads that were all correctly decrypted.

For the organizers to trash the votes and make the results up would require all the parties to agree to it. If you have a political system that corrupted already then I don't think you'd even be having a vote in the first place (it would be called martial law).


Cheers,

Ian.

Absolutely. I think it's important to be able to audit the final tallies. After all, the POTUS in 2000 would have been different.

If they're the only ones counting the votes, they definitely can cheat the system.
They receive all the votes, throw 'em to trash and say "the result is A 20 votes, B 10 votes".

For the system to be decentralized, every participant should be able to verify the counting.
Please, read the pdf I linked. I think you're underestimating the problem at hand.

For sure the approach I am suggesting does require "organizers" as this is necessary in order to keep the batch keys secret (to prevent people knowing about each others vote).

The votes themselves (but not their owners) are actually transparent though as each vote had to have been correctly cast in order for a "receipt" to be issued for it (that what the secret batch keys are for). Effectively its a zero sum game.

The tally is itself visible to everyone and the "balance" of BTC (or lets just call it VTC) should show that the election was fairly run (each voter got x VTC and it was spent on legit votes as shown by the issuing of receipts).

The organizers cannot cheat the system as otherwise anyone could detect the missing votes (as being missing money).


Cheers,

Ian.

So nobody but the organizers (or software that they run) know all the keys and can sum the votes, right?
If that's the case, your solution is not decentralized.

I don't quite follow what you mean - the ballots themselves are not individually signed as then it would not be a blind ballot. The ballots are, however, encrypted by a "batch" key (which is not known to the voters) so that they cannot be altered without it being discovered by the organizers/parties (this is why it would be necessary to only pass on ballots to voters from a different batch to your own).

The transactions form the proof that ballots were passed between voters and eventually were delivered to their intended parties.

Where are the signatures?

The following is a possible workflow for my approach.

Consider three voters (A,B and C) each belonging to a different "batch" with both A and B having exactly two votes (one real and one dummy) and C only having one (being a member of the final batch of "party members" that don't need anonymous votes):

A (A1 A2)
B (B1 B2)
C (C)

Now consider the following:

A sends A1 to B (accepted as A is in the first batch)
A sends A2 to B (accepted as A is in the first batch)
B relays A1 to C (accepted as A1 came from the first batch)
B delivers A2 and then sends B1 to C
C delivers A1 (as B has delivered one vote) and then sends C1 to B
B delivers C1 (as C has delivered one vote) and then sends B2 to A
C delivers B1 (as B has delivered two votes)
A delivers B2 (as B has delivered two votes)

So finally the votes were delivered as such:

A (B2)
B (A2 C)
C (A1 B1)

But if B had instead delivered A1 and relayed A2 then the result would be:
A (B2)
B (A1 C)
C (A2 B1)

Also if B had instead sent B2 to C and B1 to A then the result would be:
A (B1)
B (A1 C)
C (A2 B2)

And of course if B stuck to the original relaying of A1 then the result would be:
A (B1)
B (A2 C)
C (A1 B2)

So from this we can tell that A delivered a vote from B (but we don't know whether it was the real vote or a dummy) and we can tell that B delivered a vote from C (who being in the final batch doesn't need anonymity). We can also tell that B delivered a vote from A (but not which one) and that C delivered a vote from both A and B (but not which ones).


Cheers,

Ian.

Actually it is not so much that you can decrypt a vote (as the voters should not know the batch key) but there is the small percentage of possibility that you can match the encrypted ballot against one that had been sent to you by another user from the same batch.

Perhaps the easiest rule to avoid this occurring is that you must always relay to someone from a newer batch (although that would introduce a problem in working out how to process the ballots from the last batch).


Cheers,

Ian.