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?

If you are using and older version of Windows with NTFS then I can send you an "ln" executable (or the source code for it in c++) that I whipped up years ago (just calls the API function to make a hard link - note that being a hard link the other logical drive must be on the same physical hard drive).


Cheers,

Ian.

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

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.

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.

Thanks very much for the links and explanation.

In another thread I refined the approach I outlined in this thread to solve a number of the problems you pointed out although in perhaps a quite different way.

In my approach I would group together a (large) number of voters into a "batch". The "ballots" would be sent as an encrypted payload to each voter in the batch where each ballot contained say 100 valid and 100 dummy encrypted vote keys for each candidate (with the batch member being able to know which are which by perhaps just the ordering of them). The idea behind this is that to create your actual ballot you randomly put together a vote (dummy or real) for each candidate and mix in a special vote that is actually something unique you can use later on to check your vote was actually delivered.

A completed ballot would be sent in an encrypted payload to a member of the following batch (without collusion it should not be possible for them to determine or change the vote without corrupting the content of the ballot). As the member of the following batch would be chosen randomly the idea would be that if you receive more than one vote you randomly choose to forward on all votes but one to another member of the same batch (this could be further worked out to make for better shuffling).

To qualify yourself as being able to have your vote delivered you must first have delivered a valid vote from the previous batch (apart from members of the first batch which could just be all dummy votes created by the system I guess). This would be determined by a "receipt" tx sent to the deliverer of the ballot that identifies who the vote was actually for and contains the unique data allowing the original voter to see that their vote was indeed delivered (and was not corrupted).

The final batch of voters would send their votes to the initial batch to complete the system. At the finish each voter will have a receipt tx containing a valid vote (for another voter). All votes can then be tallied publicly and each voter can verify that their own vote was correctly delivered.

I will check out the other information you mentioned - just putting this out as another possible approach.


Cheers,

Ian.

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

I do understand the value of system design and documentation - in fact when I release my software platform you might be rather surprised to see that in fact that what you look at and edit with is basically a design document (source code for apps is 100% generated from a sophisticated model that includes specifications that describe in an "intentional" manner all objects and functions of the software).

You might want to read up about what Charles Simonyi has been working on for at least the last 10 years to understand the kind of paradigm shift in software engineering I am talking about.


Cheers,

Ian.

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?

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.

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?

Yes - I learned this the hard way by embarrassing myself in front of a *guru* in my first full time programming position by making an assumption about what the code did from an out of date comment.

He was at least kind enough to set me straight - "Ian don't forget that the compiler can't understand the comments". From that day on I learned to "read code" and became a much better programmer because of it.


Cheers,

Ian.

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

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.

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.

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.

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.

I don't quite follow what you mean - the ballots themselves are not individually signed as then it would not be a blind ballot. The ballots are, however, encrypted by a "batch" key (which is not known to the voters) so that they cannot be altered without it being discovered by the organizers/parties (this is why it would be necessary to only pass on ballots to voters from a different batch to your own).

The transactions form the proof that ballots were passed between voters and eventually were delivered to their intended parties.