The global decentralized secure electronic voting system is up and running

[CIYAM]

For sure the approach I am suggesting does require "organizers" as this is necessary in order to keep the batch keys secret (to prevent people knowing about each others vote).

The votes themselves (but not their owners) are actually transparent though as each vote had to have been correctly cast in order for a "receipt" to be issued for it (that what the secret batch keys are for). Effectively its a zero sum game.

The tally is itself visible to everyone and the "balance" of BTC (or lets just call it VTC) should show that the election was fairly run (each voter got x VTC and it was spent on legit votes as shown by the issuing of receipts).

The organizers cannot cheat the system as otherwise anyone could detect the missing votes (as being missing money).


Cheers,

Ian.

[1714047757]

1714047757

[1714047757]

1714047757

[1714047757]

1714047757

[1714047757]

1714047757

[jtimon]

The organizers cannot cheat the system as otherwise anyone could detect the missing votes (as being missing money).

If they're the only ones counting the votes, they definitely can cheat the system.
They receive all the votes, throw 'em to trash and say "the result is A 20 votes, B 10 votes".

For the system to be decentralized, every participant should be able to verify the counting.
Please, read the pdf I linked. I think you're underestimating the problem at hand.

[cbeast]

For the system to be decentralized, every participant should be able to verify the counting.

Absolutely. I think it's important to be able to audit the final tallies. After all, the POTUS in 2000 would have been different.

[CIYAM]

If they're the only ones counting the votes, they definitely can cheat the system.
They receive all the votes, throw 'em to trash and say "the result is A 20 votes, B 10 votes".

For the system to be decentralized, every participant should be able to verify the counting.
Please, read the pdf I linked. I think you're underestimating the problem at hand.

The organizers are definitely not the only ones counting as each and every party also verfies that each and every vote is valid and in fact after the poll is completed the secret keys themselves could be released (if not to the public then at least to a 3rd party) so that they can confirm the vote payloads that were all correctly decrypted.

For the organizers to trash the votes and make the results up would require all the parties to agree to it. If you have a political system that corrupted already then I don't think you'd even be having a vote in the first place (it would be called martial law).


Cheers,

Ian.

[jtimon]

The organizers are definitely not the only ones counting as each and every party also verfies that each and every vote is valid and in fact after the poll is completed the secret keys themselves could be released (if not to the public then at least to a 3rd party) so that they can confirm the vote payloads that were all correctly decrypted.

As said, this is not a decentralized voting system. Why use a block chain at all? Just a server run by the organizers that makes the encrypted votes public so that the voters can validate the valid votes. And then trust the organizers and the third party. Also, there's no anonymity, because the organizers (and the third party) know what each voter has voted.

The system I want has the following properties:
1) Everyone can count the votes.
2) No one can know what other participants have voted.

[CIYAM]

Well achieving what you want may not actually be possible but saying that the votes are not anonymous in my approach is just completely wrong - if you want to seriously criticise something please take the time to give the proof (I bothered to take the time to give you a workflow after you said I couldn't).


Cheers,

Ian.

[jtimon]

Well achieving what you want may not actually be possible but saying that the votes are not anonymous in my approach is just completely wrong - if you want to seriously criticise something please take the time to give the proof (I bothered to take the time to give you a workflow after you said I couldn't).

Maybe I misunderstood something in your workflow, but can't the organizers know what everybody voted for?

Maybe you're right in your claim that achieving what I want is impossible, but is the aim of the pdf a linked and (Ben correct me if I'm wrong) what this thread claims to have achieved.

[CIYAM]

Maybe I misunderstood something in your workflow, but can't the organizers know what everybody voted for?

The workflow shows that they see every vote *but* they do not know which vote comes from which voter as the votes were secretly shuffled between the voters before being sent to their voting destination. So it *is* anonymous.


Cheers,

Ian.

[jtimon]

Maybe I misunderstood something in your workflow, but can't the organizers know what everybody voted for?

The workflow shows that they see every vote *but* they do not know which vote comes from which voter as the votes were secretly shuffled between the voters before being sent to their voting destination. So it *is* anonymous.

Say we want to elect the major of my town.
We have a pool of voters V = {v1, v2, ... v100000}
The organization generates a set of keys K = {k1, k2, ... k100000} and give them to the voters.
The organization knows the mapping between V and K so it knows what every participant has voted.
The dummy votes and the relays just may hide the IP addresses of the voters, but that could have just be made suing Tor or i2p. It doesn't makes sense because the organizers know the voeters NIF.
If you want the organization to not know what every participant has voted, they cannot know the mapping between V and K.
If you can do that, I would suggest that instead of keys for a symmetric encryption algorithm, the organizers distributed privates keys of an asymmetric one and published all the valid public keys. That way voters could sign their vote and everybody could verify the results.
But...
Where does "secret shuffling" algorithm run? How does it work so that the owner of that computer can't know the resulting mapping?

[CIYAM]

I never wrote that you have n secret keys for n voters - I wrote that you have n / x secret keys so that your vote could only be identified as being "one of n / x". I used the term batch to describe n / x and a public batch # would also be assigned to each user. This # is visible to all other users so that you make sure you pick a user *not* from the same batch to send your vote to.

There is no 1 to 1 mapping - can you understand it yet?
 
(if you get this part then I can re-explain the rest again - if you don't get this part then I don't see the point in further discussion)


Cheers,

Ian.

[jtimon]

I never wrote that you have n secret keys for n voters - I wrote that you have n / x secret keys so that your vote could only be identified as being "one of n / x". I used the term batch to describe n / x and a public batch # would also be assigned to each user. This # is visible to all other users so that you make sure you pick a user *not* from the same batch to send your vote to.

Ok, so there's n keys and x voters.
How do you map the n keys to the x voters?
I think this shuffling algorithm runs on the organizers server so they will know the mappings between k(i) -> v(j). The key i belongs to the voter j.

Yes, this is the part I need to understand first. I don't really understand what you mean by batch here. A set of keys for each voter?
I don't see the point if the organizers know who owns each key.

[CIYAM]

There are not x voters and n keys - there are n voters and n / x keys. So there are less keys than voters. See?

[jtimon]

There are not x voters and n keys - there are n voters and n / x keys. So there are less keys than voters. See?

I still don't see the point. Can you answer my questions below?

I don't really understand what you mean by batch here. A set of keys for each voter?
How do you map the n / x keys to the n voters?

I would be VERY HAPPY if there was a system for decentralized voting. I would mail the Gerald Celente's "direct democracy" and spanish's "Democracia real ya" (real democracy now) crew and all, but I still see it NOT_FEASIBLE.
I expect a surprise on this technical issue nontheless, but sorry, your proposal doesn't seem to meet the constraints.

I will read Ben's proposal when he learns how to write less than, say, ten lines. I have an hypothesis but not the time to make it become a proper theory: "It is impossible to go offtopic on a thread started by BenRayfield, even if your talk about the wheather or the sex of snails". He has covered it. Hi Ben, in case you read the threads you start.

[CIYAM]

It seems to be a really difficult thing for me to explain this to you - but as I'm still relatively new I'll do my best.

There are *less* keys (much less) than votes so that the votes *cannot* be mapped 1 to 1 (otherwise of course you would not have anonymity).

So lets say we have 1000 voters and we've decided to use 10 secret keys. Thus one secret key is shared by 100 voters.

In order for those voters to avoid sending their vote to another voter using the same secret key we label each group of 100 (which I termed a batch) with a simple # (i.e. batch 1..10 in this case as there are 10 secret keys). This batch label is *not* encrypted so that a voter makes sure they will pass on their vote to someone that belongs to a different batch.

Are you with me so far?

[jtimon]

Ok, now I get it. The organization knows the key it gives to each voter and knows the 100 votes but not what voter has issued what vote.
In your example, if 60 vote to A and 40 to B, they don't know what each of these v1...v100 have voted as long as they don't vote all the same.

Next question.
How double voting is prevented?
v1 sends one vote for A and 2 votes for B. How the system knows that the second and third votes are invalid and don't belong to, say, v2 and v3?

[CIYAM]

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.

[jtimon]

Okay - good to get past that hurdle.

Sorry for taking so long to understand you.

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

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.

[CIYAM]

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?

[cbeast]

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

I will read Ben's proposal when he learns how to write less than, say, ten lines. I have an hypothesis but not the time to make it become a proper theory: "It is impossible to go offtopic on a thread started by BenRayfield, even if your talk about the wheather or the sex of snails". He has covered it. Hi Ben, in case you read the threads you start.

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

[jtimon]

Still with me?

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