The global decentralized secure electronic voting system is up and running

[Red Emerald]

http://www.youtube.com/watch?v=9Ww8rI0BG9k

I wish I could do this!!

[1713433881]

1713433881

[1713433881]

1713433881

[1713433881]

1713433881

[jtimon]

Does this use something like this?

http://en.wikipedia.org/wiki/Homomorphic_encryption

That claim in the Wikipedia article was cited:

Ron Rivest (2002-10-29). "Lecture Notes 15: Voting, Homomorphic Encryption"

I also think that a parallel chain and merged mining will probably be a better answer.

I don't see how you prevent double voting (you say web of trust but I think that can be cheated).
You need a centralized id system, but anyway this is cool.

I still don't see how you map the id key to the voting key anonymously.

But maybe you've explained it all in your long post. You should summarize it.

[CIYAM]

The following approach (as far as I can tell) should work and requires little more than a modified Bitcoin client to achieve:

- each "vote" contains an encrypted message (that only the party and the organisers can unlock) then only if this message has the right value is it considered an actual vote (this permits voters to send one or more dummy votes along with their real vote)

- to be eligible to vote you must first have sent someone else's vote to the nominated party (this is verified by having the party send a receipt to the final sender) certain specific voters (party members) would be sent their receipts in advance in order to create initial eligible voters (not really an issue to know that party members will vote for their own party)

- if a vote is received from an eligible voter then randomly decide whether to deliver it or relay it (if the voter is not yet eligable then just relay it)

- to vote send your actual vote and at least one dummy vote to several other voters who are not yet eligible

- once you have voted you need to wait (and continue to relay other votes) until your receipt confirms 6 times


Cheers,

Ian.

[cbeast]

Here is my understanding of how this will work.
1. Print a ballot with a unique (on every ballot) address for each candidate. This means every candidate has many addresses.
2. Randomly hand out ballots to registered voters in each district. This makes it anonymous.
3. Send the minimum bitcoin to each address you vote for. (I'm not going to worry about buying votes, there are many ways to handle that.)
4. Count the number of addresses that receive value for each candidate, not the value amount.
5. The voting can be done from home. Paper ballots can be used to audit the election in each community.

[CIYAM]

Well maybe there is a flaw in what I have proposed but in my system you need no paper and can be audited 100% from the blockchain.

The anonymity is achieved by the fact that you never cast your own vote and that also you vote more than once (where other votes are "dummy" votes).


Cheers,

Ian.

[jtimon]

Here is my understanding of how this will work.
1. Print a ballot with a unique (on every ballot) address for each candidate. This means every candidate has many addresses.
2. Randomly hand out ballots to registered voters in each district. This makes it anonymous.
3. Send the minimum bitcoin to each address you vote for. (I'm not going to worry about buying votes, there are many ways to handle that.)
4. Count the number of addresses that receive value for each candidate, not the value amount.
5. The voting can be done from home. Paper ballots can be used to audit the election in each community.

But the party registering the voting addresses (associating addresses to registered voters) can know exactly what each voter voted.
Am I missing something?

[CIYAM]

If you check the method that I described you'll see that it makes it impossible for anyone to know who voted for who.


Cheers,

Ian.

[cbeast]

Here is my understanding of how this will work.
1. Print a ballot with a unique (on every ballot) address for each candidate. This means every candidate has many addresses.
2. Randomly hand out ballots to registered voters in each district. This makes it anonymous.
3. Send the minimum bitcoin to each address you vote for. (I'm not going to worry about buying votes, there are many ways to handle that.)
4. Count the number of addresses that receive value for each candidate, not the value amount.
5. The voting can be done from home. Paper ballots can be used to audit the election in each community.

But the party registering the voting addresses (associating addresses to registered voters) can know exactly what each voter voted.
Am I missing something?

Step two would randomize the ballots so the ballot with the adresses would not be assigned to a particular voter, but to any one of the registered voters in a district. The only way to track who voted for whom is to track the bitcoin adresses to IPs like any other bitcoin transaction.


[edit] Paper ballots are very important. Ask any American stuck with voting on a Diebold system.

[jtimon]

@CIYAM Pty. Ltd.

Sorry, I don't see an equivalent of cbeast's step 2 in your proposal.
Also...

- each "vote" contains an encrypted message (that only the party and the organisers can unlock) then only if this message has the right value is it considered an actual vote (this permits voters to send one or more dummy votes along with their real vote)

Then only the organizers can decrypt the votes and sum them, right?
Where's the decentralization then?

@cbeast

Can you explain the step 2 in more detail?
How can you give an address to each registered voter in the district without knowing what address your gave to each voter?
Also, how can you generate addresses without knowing the private key?

[CIYAM]

@CIYAM Pty. Ltd.

Sorry, I don't see an equivalent of cbeast's step 2 in your proposal.
Also...

The anonymity in my approach is created by the fact that you don't actually cast your own vote - you cast a vote from someone else. When you receive another voters vote you also randomly decide whether to cast it or forward it (although in forwarding you might swap the contents for you own vote).

- each "vote" contains an encrypted message (that only the party and the organisers can unlock) then only if this message has the right value is it considered an actual vote (this permits voters to send one or more dummy votes along with their real vote)

Then only the organizers can decrypt the votes and sum them, right?
Where's the decentralization then?

Actually as each vote requires a receipt anyone can count all the votes (they just can't tell who voted for who).


Cheers,

Ian.

[jtimon]

@CIYAM Pty. Ltd.

Sorry, I don't see an equivalent of cbeast's step 2 in your proposal.
Also...

The anonymity in my approach is created by the fact that you don't actually cast your own vote - you cast a vote from someone else. When you receive another voters vote you also randomly decide whether to cast it or forward it (although in forwarding you might swap the contents for you own vote).

How is it decided who sends who's vote?
How do you ensure that my vote is not  sent by two participants?

- each "vote" contains an encrypted message (that only the party and the organisers can unlock) then only if this message has the right value is it considered an actual vote (this permits voters to send one or more dummy votes along with their real vote)

Then only the organizers can decrypt the votes and sum them, right?
Where's the decentralization then?

Actually as each vote requires a receipt anyone can count all the votes (they just can't tell who voted for who).

What's the receipt here and what does it contains?

[CIYAM]

What's the receipt here and what does it contains?

The receipt is a payment (value not being important here) made by the "party" to the "casting" voter (although that vote won't be their own). It doesn't actually need to contain anything - it just used by the party and organizers to verify the delivery of a valid vote.

This ensures that that you have cast a valid vote (that is in fact another voters vote). Until you've cast a valid vote you cannot have your own vote cast (thus the need to seed the system with a few non-anonymous votes presumably by party members).


Cheers,

Ian.

[jtimon]

With all respect, I think your system is not defined with enough detail. If you describe the process sequentially with enough detail you will see it's flawed.

Two candidates A and B
1) User c with addC commits A's vote for A.
  How the organization decides that is c (and not another voter) the one who has to commit that vote?
  How the organization knows addC belongs to c?
2) Now user c can vote. He sends his vote to d (who will know his vote, by the way) for d to commit it.
  How c knows that he has to send his vote to d and not, for example e?
  How does the system warranties that d doesn't change c's vote before committing it?

If the sequencing between voters is public and the votes themselves are public, everything is public.
If the votes aren't public and the organizers must sum the votes, the system is not decentralized.
If the votes are public but the sequencing between voters isn't, how does it works?

Everybody must be able to sum the votes independently for the system to be decentralized.
The mapping between the persons and the voting addresses must be blinded somehow for the system to be anonymous.

I recommend you to read the document I linked above.

[CIYAM]

With all respect, I think your system is not defined with enough detail. If you describe the process sequentially with enough detail you will see it's flawed.

Two candidates A and B
1) User c with addC commits A's vote for A.
  How the organization decides that is c (and not another voter) the one who has to commit that vote?
  How the organization knows addC belongs to c?

You may be correct but I think I can explain the two points you have raised.

First point is that the organization doesn't decide who commits the vote - that is effectively a random decision. The organization doesn't need (nor would you want them to know) that it was A's vote but only that a valid vote was received by the party.

2) Now user c can vote. He sends his vote to d (who will know his vote, by the way) for d to commit it.
  How c knows that he has to send his vote to d and not, for example e?
  How does the system warranties that d doesn't change c's vote before committing it?

The ballot would be encrypted with a secret batch key (known only to each party and to the organizers with there being perhaps 1 of a possible fairly low percentage of the total number of registered voters) so there is is only a fairly low percentage of chance (the percentage chosen) that you can decrypt a vote, however, if you make sure that the user you first send your vote to does not belong to your own batch (by having a non-encrypted batch # that all can see) then subsequent users might be able to decrypt the vote but they now would not know whose vote it was (as your identity has disappeared during the relay).

To prevent tampering the rule would be that a vote submitted to a party that belongs to the same batch # as the user sending it would be relayed back to its sender (I guess this might be a slight flaw in that the small percentage of chance you have of receiving a ballot from another user from the same batch could give you an opportunity to change that vote).

If the sequencing between voters is public and the votes themselves are public, everything is public.

Each ballot (whether the initial one sent to the user, one relayed between users or the final one delivered as a vote) would be public key encrypted to the destination user and the actual vote is encrypted with the batch key so no nothing is public apart the fact the tx's were sent between users.

If the votes aren't public and the organizers must sum the votes, the system is not decentralized.

The receipts provide the final way that anyone can count the votes. The role of the organizer is to simply verify that the parties have only created receipts for valid votes (by checking each vote with the secret batch key).

I am not sure whether or not I have nailed it yet but hopefully these points will convince you that my approach is not completely flawed.


Cheers,

Ian.

[cbeast]

@CIYAM Pty. Ltd.

Sorry, I don't see an equivalent of cbeast's step 2 in your proposal.
Also...

- each "vote" contains an encrypted message (that only the party and the organisers can unlock) then only if this message has the right value is it considered an actual vote (this permits voters to send one or more dummy votes along with their real vote)

Then only the organizers can decrypt the votes and sum them, right?
Where's the decentralization then?

@cbeast

Can you explain the step 2 in more detail?
How can you give an address to each registered voter in the district without knowing what address your gave to each voter?
Also, how can you generate addresses without knowing the private key?

Simple. It's exactly the same way a merchant creates a unique address for every purchase. Every ballot is like a menu with all unique addresses for every candidate. The private key issue is a problem that could be addressed by separating powers and having the public keys assigned to candidates by an independent third party. After the election, the holder of the private keys can move the voting funds back to the local communities coffers or some other public trust.

[CIYAM]

The ballot would be encrypted with a secret batch key (known only to each party and to the organizers with there being perhaps 1 of a possible fairly low percentage of the total number of registered voters) so there is is only a fairly low percentage of chance (the percentage chosen) that you can decrypt a vote.

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.

[CIYAM]

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.

[jtimon]

Where are the signatures?

[CIYAM]

Where are the signatures?

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.

[jtimon]

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

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.