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

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.

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.


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


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.


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.

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.

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.

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


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

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


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


Cheers,

Ian.

@CIYAM Pty. Ltd.

Sorry, I don't see an equivalent of cbeast's step 2 in your proposal.
Also...
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?

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.

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.

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

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.

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.

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.

Does this use something like this?

http://en.wikipedia.org/wiki/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.

I wish I could do this!!

But by all means, try!  I'm happy to pocket the extra transaction fees.

I don't think this works.  0.0000001 BTC is meaningless, effectively every transaction costs at least 0.005 these days.  This is a lot more expensive than you think, and the implementation will be so convoluted I doubt it will catch on.

You have a giant gaping hole: either you let people directly vote with BTC (10btc is 10x the voting power of 1BTC), or you censor a huge number of people by guessing which addresses are connected with each other.  It is better to start from scratch.

PS: Seeing as how you claim to be able to move things with your mind, there should be much better uses of your time than this.
http://www.youtube.com/watch?v=9Ww8rI0BG9k

Why didn't you use your own blockchain instead of spamming bitcoins blockchain?

It is build on top of Bitcoin.
Paper: http://people.scs.carleton.ca/~clark/papers/2012_fc.pdf
Discussion: https://bitcointalk.org/index.php?topic=59956.0;all

That's already in the code.