In another thread one of the authors of Commitcoin mentioned about Scantegrity so will find some time to read up on this in the next couple of weeks.

I got the idea from his comments that such systems are already (have already?) been constructed so probably no need for any bounty as I suspect the software will be out there soon (although I don't know if it will be open source).

If Scantegrity it is not open source then you might run into some IP issues copying his approach. Assuming my technique is not the same (and I assume that it is not from the comments I read) then certainly it could be used.

Although this is an interesting intellectual excecise I do wonder whether Bitcoin itself is an appropriate vehicle as the # of tx's hitting the blockchain would rather dramatically increase if elections involoving multi-millions of votes were to be conducted in this manner. At the same time an alt chain might easily be 51% attacked (presumably by the government running the election) so that also is a problem.

Am not really up on the subtle details of merged mining but I think that the issue of dealing with millions of tx's per day is something that Bitcoin will have to be able to handle well if it is ever to go up against any of the big payment processors.

Yes I guess that merged mining could be a part of the solution.

BTW was thinking a bit more about the encryption of ballots (and the prevention of voter collusion) and was wondering if a private key were to be made public then perhaps it could be used to encrypt each and every vote (coupled with the pubkey of the party or organizer).

As everyone would be using the same "published" private key you would get anonymity but (unless my understanding is incorrect) only the party/organizer would be able to decrypt the ballots.

On the contrary in a previous post I mentioned that each user would put a unique key (a UUID for example) in their encrypted ballot which would then be included in the "receipt" tx (as payload). In this way each user can verify that their own vote was correctly delivered to their party of choice (by another user).

Also with the receipt tx's the tally is available for all to check. And as mentioned way back the BTC (or VTC) balances should be a zero sum to prove that all votes were correctly processed.

I think this is really very close to what you are wanting to achieve with perhaps only the shuffling approach needing a little more attention for complete satisfaction.

If they did that you don't think all the users would report that they didn't find their votes?

Once again each voter places a UUID in their ballot which needs to be put in the receipt tx payload. You scan all the receipt tx's (as you won't know who delivered your vote) until you find your UUID.

If you don't find your UUID or if that vote is not what you voted for you scream FRAUD.

Still think the organizers can just make up the results?

Okay - nearly there.

1) The UUID would be encrypted along with the rest of the ballot so the user submitting your vote cannot see it. This number will only be known to the organizer/parties and to yourself (with the organizer/parties not having any way to trace that number to the voter as it is only used by the voter to later find their vote - in fact after verifying your vote receipt you can destroy that UUID so no-one can determine who you voted for later on).

2) Yes the votes are encrypted so that only the organizer/parties (which would be all parties not just the one you are voting for) know initially who you voted for. It is the receipt tx that then contains the same vote in plain text along with the UUID.

So the votes do end up being public and unencrypted and each voter can verify their own vote (you just can't verfiy other users vote unless they want to tell you there UUID). Also the total BTC/VTC of receipts should equal the total BTC/VTC that was sent out to registered voters who voted (am not really considering non-voters as I think an automatic dummy vote could accomplish that).

The point of the ballot (and UUID) encryption is to prevent the users colluding with each other to try and cheat the system. The workflow I showed earlier basically says that you don't qualify to have your own vote submitted until you have submitted a vote for someone else. The idea being that it is in your interest to help out with making the ballots anonymous.

As I've stated before for every registered voter there is a tx for them to spend (their vote) and every receipt (which holds the vote in plain text) is a tx of the same amount (their vote again - but cannot be linked to the initial one except by the UUID known to the user).

Anyone can count them - just not while they are encrypted (if you don't encrypt them then users, organizers or parties could collude to screw the whole thing up).

Encrypting the ballots is not a problem though because if the organizers/parties cheat then either the balances will not zero sum (which all other parties will also know) and/or the UUIDs will not match (which each user can verify their own vote was correctly processed).