I tried to summarize my thoughts on using Bitcoin for anonymous & verifiable voting systems on the Bitcoin StackExchange. I could repost it here but for now I'll just link to it:
http://bitcoin.stackexchange.com/a/2874/512I'm happy to discuss/clarify it further here. In summary, I suggest that voters register for an election with their real name and an encryption of a Bitcoin address they create for the purposes of voting. Voting is done by sending a transaction from this account to the account set-up by the candidate (the money can be returned). Since any unregistered voter can also send money the the account, you need a way to exclude all votes that were not sent from an address that was registered (and you can't see these addresses because they are encrypted). In short, you can throw some fancy crypto at the problem and only keep properly registered votes without ever decrypting the Bitcoin accounts.
I also wanted to respond to your comments on CommitCoin (I am one of the co-authors of it). Voting is just one application of CommitCoin and so we devoted the paper to discussing how "carbon-dating" commitments works in general and then how to do carbon-dating with Bitcoin.
In the voting example, the heavy lifting is done by the voting scheme Scantegrity. The technical details of Scantegrity are in the cited work. CommitCoin is just providing one simple service for Scantegrity: showing that certain commitments (to election date) made before an election are actually made before the election. We do describe specifically how these are inserted into the block chain in the appendix of the full version of the paper.
Our CommitCoin paper does rely on an understanding of Scantegrity to understand the voting example and wasn't written to be a stand-alone description of doing an entire voting protocol. Bitcoin factors in in only a small way.
Scantegrity with CommitCoin (and without) is a secret ballot voting system.
Finally, to comment on your suggested solution to step 3 of your voting scheme. It is similar to an anonymity service called Crowds. This type of system can be made to work but it will take some modifications:
- Votes must be encrypted under a key. If it is symmetric key, the voter and receiver must agree on a key. It is better to use public key encryption where I know how many hops my vote will go through before being decrypted.
- Voters are anonymous to a passive adversary. However if the adversary is one of the voters (or corrupts one), they will know how the voter who gave them the real vote will have voted.
- The above can be accounted for my having votes go through a number of voters before being sent to the actual candidate. This is the principle behind onion routing (Tor). However, the encrypted vote must change at every voter so you can't trace it through. This can be accomplished by layering a level of encryption on your vote for each hop, where each hop takes a level off. Alternatively, with public key encryption that is "homomorphic", you can simply rerandomize the encryption of the vote.
- The scheme has no integrity. Any voter can replace a vote they receive with a vote they generate. If even if there is a mechanism to detect the modification by the voter, the voter can't really prove what they did (without also being able to prove how they voted). If disputes cannot be proven, then anyone can spuriously dispute that their vote was modified to cast doubt on an election outcome they do not favor.
- As the number of voters grows, the number of dummy votes needs to grow to hide the origin of the votes. A better architecture is to use dedicated parties to filter the votes through. This is called a mix network. Mix networks can be constructed where the mixers can cryptographically prove they did not modify votes. Verifiable mix networks are the basis of many cryptographic voting systems.
http://en.wikipedia.org/wiki/Mix_network