Untraceable voting for registered users [closed]

Question

I want make to a untraceable voting system that would allow registered users to vote on some sensitive issue in a way, that would make it impossible to track votes back to users in a case of database compromise (including being "compromised" by overly curious DB admin).

Detailed setup:

1. Every user is registered, there's no completely anonymous voting.
2. Sockpuppets, fake accounts, and the like are out-of-scope of this question - this is responsibility of registration system.
3. Every registred user can only cast one vote (which may be anything: simple yes/no or weight or whatever).
4. User must be able to change/delete his vote until voting is closed.
5. It is not necessary to let user view its own vote, though it can be done in same way that deleting/changing is done.
6. Even if somebody have access to user auth database and voting database, they must not be able to track each vote back to user (in a sense that it must not be easier that bruteforce or otherwise hack entire user account's access).
7. All parts of system except communications are open, so there can't be hidden keys. MitM attack is out-of-scope of question, but attacker have full access to sources, auth and voting database.
8. Users are lazy. They will not want any other voting-specific key or password. System must not require user to provide or keep locally anything except the usual login/password/key whatever they already use to login.
9. Tampering of votes and any security issues except program<->DB communication and untraceability are much wider issue and so are out-of-scope of this question too.

I have some solutions in mind which I post as my own answer after grace period.

Answer 1

Assuming the DB Admin has no access to the application code that will have the voting system, and assuming that the DB Admin viewing the votes is not an issue (just linking a vote to a person)

In your table where you store the user votes, create an extra column that will contain a salted hash of some info from the user that cast the vote (name, username, e-mail, b-day, combination of those). This is the important thing, the DB Admin should not know how the user unique value that is stored in the DB, is first generated and then encrypted.

Just assume that the user token that you came up with (name, email) is a password, and you want to store in the DB without people knowing what the actual password is. More info can be found here Best way to store password in database

So with your per user hashing/salting algorithm, each time a user wants to cast/edit or delete their vote, you can first generate the hash, then try to find a record with that hash value in the voting table, and act on it accordingly. ( insert if it doesn't exist, update if it does, and delete if the user wanted that)

Once the voting process is closed, you can even discard the hashed values for the answers for that voting process, so that there is no way ever to link the votes to users