Topic: The global decentralized secure electronic voting system is up and running (Read 10533 times)

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

Can anyone make the counting or only the organization?

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.

I get it. All the votes are public and with a UUID that only the voter (and the voter that committed your vote) knows. So let's summarize your method.

1) The organizers send 1 voteCoin to each voter. This prevents double-voting.

2) Every voter, with his own voteCoin submits the vote of another voter.

3) The votes are public for all people to see and calculate results. This prevents fraud.

But you have to explain me the step 2 again. I thought the votes were encrypted with a key that only the organizers knew.

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?

Yes, yes. You can verify that all the votes have been correctly delivered.
What I want is each voter to be able to verify the counting.
The organizers can still receive all the votes, ignore them and report the result they want, can't they?

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.

Yes, that would work but that completely removes the possibility of voters validating the results (and not only the organizers). You don't think that's important but I do.

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.

Merged mining allows miners to use the same hashing power for mining various chains simultaneously . It's a good way to increase the difficulty of an alternative chain.

http://dot-bit.org/Merged_Mining

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.

Well, that would be a problem Maybe some places without software patents can use it. As far as I know, there's no software patents in europe yet, but I'm not a lawyer, don't take my word on this.


Merged mining to the rescue?

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.

I don't know, it may work.

Here's a recent thesis on decentralized voting. I haven't read it yet (is long), but looks really interesting.

http://uwspace.uwaterloo.ca/handle/10012/5992

Should we start a bounty?

To submit a vote you must send your tx (and ballot payload) to a member of the following batch (with the tx having the correct amount).

No member of the following batch will send your ballot unless they can see that you have already previously submitted another's ballot (which has to be from a previous batch as each batch cannot submit ballots that originate from their fellow batch members). This is verified by checking that the user has got a receipt from the organizers (the receipt being for a valid ballot that didn't belong to your batch).

Once you have a receipt no-one from your own (or any other) batch should attempt to send you another ballot (so you can't get any more money) and no-one will deliver your ballot until your balance is only the amount of the receipt (perhaps the timing might be handled according to block #'s). The organizers will not accept a second ballot being submitted from any one user so I think this should do it.

I haven't really gone through in great detail how to be 100% sure you can't possibly "sneak something past the cracks" but I think if one or more confirmations are applied to determine the current "state" of a voter then such cheating should not be possible (at least not without significant collusion amongst voters who after all won't know who each other are).

Not sure. If I send my vote multiple times what prevents other users to submit my vote more than once?

This thread is making my brain implode. I'm trying to understand the workflow.


Decentralized voting is like the DNA to Bitcoin's RNA. Bitcoin will be the engine, (insert name for Decentralized Voting) will be the helm.

But you won't be sending your own vote.

Your vote is sent on to a user from the next batch whose own votes are encrypted differently to those of your block and so who cannot work out who your vote is actually for (the ballot itself is the payload here not the money). To avoid a member of the next batch being able to easily work out what is what I think that each voter would actually randomly pick (from a group of say 100) a real or dummy vote for each party plus one that looks like a vote for a party (randomly placed within) that is actually some sort of UUID generated by each voter so that they will be able to check that their vote was indeed submitted (this would be included in the *receipt* which is of course sent to another user).

The approach for shuffling is a fairly simple one - eventually we want each member of each block to send another persons ballot. But as we randomly choose which members of the following batch to send the ballots to it is obvious that numerous members will be sent more than one ballot. Therefore when you receive multiple ballots you randomly send one as a vote and forward the other ballots to other members of your same batch (who you can tell have not already got ballots as their balance will just be the initial voting balance).

Still with me?

Sorry for taking so long to understand you.


I have to send my address to the organizers for them to send me the voting coins, they know my address when I submit my vote.
It seems to me that this destroys anonymity.

Okay - good to get past that hurdle.

Your next question is where the actual blockchain comes in. Although the votes themselves are a payload - they are contained (or referenced) by a transaction (we now have the block chain to stop a double spend as it does in Bitcoin). You only have x amount of money to spend (which you are given by the organizers).

I envisage that for this type of system all coin would (if belonging to an alt chain) be pre-mined and the exact amount of coin available to the voters therefore being fixed (other ways might be to only allow vanity prefixed coins mined before a certain block to be able to be used for voting if not using a vote specific block chain).

If you are fine with this then we can review the workflow idea I put forward to make the process itself work.