The global decentralized secure electronic voting system is up and running

[CIYAM]

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

[1714559369]

1714559369

[1714559369]

1714559369

[1714559369]

1714559369

[jtimon]

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?

[CIYAM]

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?

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.

[jtimon]

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?

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.

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.

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.

Merged mining to the rescue?

[CIYAM]

Merged mining to the rescue?

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.

[jtimon]

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.

Merged mining to the rescue?

Am not really up on the subtle details of merged mining...

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

[CIYAM]

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.

[jtimon]

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.

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.

[CIYAM]

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.

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.

[jtimon]

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?

[CIYAM]

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?

[jtimon]

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.

[CIYAM]

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.

[jtimon]

Can anyone make the counting or only the organization?

[CIYAM]

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