Looks nice - one suggestion that comes to mind would be to perhaps create thumbnails for use in the lists as it can take quite a while for the images to appear on a slow internet connection otherwise.


Cheers,

Ian.

Hmm... I think most people would have more chance of being able to set up a secure Linux box than to read C++.

It seems there are numerous projects involving mobile phones, deterministic wallets, two step authentication and the like that this does not seem at all to me to be such an incredibly serious problem that needs to be solved in the protocol right now.

That being said of course I support progress that will improve Bitcoin - I just hope level heads will prevail.

Awesome - thanks a lot!

This is a great idea - would it be possible to also support an option for a plain text minimal output?

e.g. http://bitping.net/exchange_rates.php?rates=AUDBTC&format=rate_only

that would output

5.23623852

(handy for use with curl)


Cheers,

Ian.

The following is a possible workflow for my approach.

Consider three voters (A,B and C) each belonging to a different "batch" with both A and B having exactly two votes (one real and one dummy) and C only having one (being a member of the final batch of "party members" that don't need anonymous votes):

A (A1 A2)
B (B1 B2)
C (C)

Now consider the following:

A sends A1 to B (accepted as A is in the first batch)
A sends A2 to B (accepted as A is in the first batch)
B relays A1 to C (accepted as A1 came from the first batch)
B delivers A2 and then sends B1 to C
C delivers A1 (as B has delivered one vote) and then sends C1 to B
B delivers C1 (as C has delivered one vote) and then sends B2 to A
C delivers B1 (as B has delivered two votes)
A delivers B2 (as B has delivered two votes)

So finally the votes were delivered as such:

A (B2)
B (A2 C)
C (A1 B1)

But if B had instead delivered A1 and relayed A2 then the result would be:
A (B2)
B (A1 C)
C (A2 B1)

Also if B had instead sent B2 to C and B1 to A then the result would be:
A (B1)
B (A1 C)
C (A2 B2)

And of course if B stuck to the original relaying of A1 then the result would be:
A (B1)
B (A2 C)
C (A1 B2)

So from this we can tell that A delivered a vote from B (but we don't know whether it was the real vote or a dummy) and we can tell that B delivered a vote from C (who being in the final batch doesn't need anonymity). We can also tell that B delivered a vote from A (but not which one) and that C delivered a vote from both A and B (but not which ones).


Cheers,

Ian.

Actually it is not so much that you can decrypt a vote (as the voters should not know the batch key) but there is the small percentage of possibility that you can match the encrypted ballot against one that had been sent to you by another user from the same batch.

Perhaps the easiest rule to avoid this occurring is that you must always relay to someone from a newer batch (although that would introduce a problem in working out how to process the ballots from the last batch).


Cheers,

Ian.

You may be correct but I think I can explain the two points you have raised.

First point is that the organization doesn't decide who commits the vote - that is effectively a random decision. The organization doesn't need (nor would you want them to know) that it was A's vote but only that a valid vote was received by the party.


The ballot would be encrypted with a secret batch key (known only to each party and to the organizers with there being perhaps 1 of a possible fairly low percentage of the total number of registered voters) so there is is only a fairly low percentage of chance (the percentage chosen) that you can decrypt a vote, however, if you make sure that the user you first send your vote to does not belong to your own batch (by having a non-encrypted batch # that all can see) then subsequent users might be able to decrypt the vote but they now would not know whose vote it was (as your identity has disappeared during the relay).

To prevent tampering the rule would be that a vote submitted to a party that belongs to the same batch # as the user sending it would be relayed back to its sender (I guess this might be a slight flaw in that the small percentage of chance you have of receiving a ballot from another user from the same batch could give you an opportunity to change that vote).


Each ballot (whether the initial one sent to the user, one relayed between users or the final one delivered as a vote) would be public key encrypted to the destination user and the actual vote is encrypted with the batch key so no nothing is public apart the fact the tx's were sent between users.


The receipts provide the final way that anyone can count the votes. The role of the organizer is to simply verify that the parties have only created receipts for valid votes (by checking each vote with the secret batch key).

I am not sure whether or not I have nailed it yet but hopefully these points will convince you that my approach is not completely flawed.


Cheers,

Ian.

The receipt is a payment (value not being important here) made by the "party" to the "casting" voter (although that vote won't be their own). It doesn't actually need to contain anything - it just used by the party and organizers to verify the delivery of a valid vote.

This ensures that that you have cast a valid vote (that is in fact another voters vote). Until you've cast a valid vote you cannot have your own vote cast (thus the need to seed the system with a few non-anonymous votes presumably by party members).


Cheers,

Ian.

The anonymity in my approach is created by the fact that you don't actually cast your own vote - you cast a vote from someone else. When you receive another voters vote you also randomly decide whether to cast it or forward it (although in forwarding you might swap the contents for you own vote).


Actually as each vote requires a receipt anyone can count all the votes (they just can't tell who voted for who).


Cheers,

Ian.

If you check the method that I described you'll see that it makes it impossible for anyone to know who voted for who.


Cheers,

Ian.

Well maybe there is a flaw in what I have proposed but in my system you need no paper and can be audited 100% from the blockchain.

The anonymity is achieved by the fact that you never cast your own vote and that also you vote more than once (where other votes are "dummy" votes).


Cheers,

Ian.

The following approach (as far as I can tell) should work and requires little more than a modified Bitcoin client to achieve:

- each "vote" contains an encrypted message (that only the party and the organisers can unlock) then only if this message has the right value is it considered an actual vote (this permits voters to send one or more dummy votes along with their real vote)

- to be eligible to vote you must first have sent someone else's vote to the nominated party (this is verified by having the party send a receipt to the final sender) certain specific voters (party members) would be sent their receipts in advance in order to create initial eligible voters (not really an issue to know that party members will vote for their own party)

- if a vote is received from an eligible voter then randomly decide whether to deliver it or relay it (if the voter is not yet eligable then just relay it)

- to vote send your actual vote and at least one dummy vote to several other voters who are not yet eligible

- once you have voted you need to wait (and continue to relay other votes) until your receipt confirms 6 times


Cheers,

Ian.

Okay - have had an idea about how to do this step (which I guess it perhaps quite similar to what bitcoin anonymizers do).

Lets say we have three voters (voter_1, voter_2 and voter_3). Each voter will send at least two votes - one of them is a real vote (from a privately issued address) and the other is a dummy vote (from another privately issued address). The order of sending these votes will be randomly chosen.

Later voters will likely have received votes before they are going to cast their own so to mix things up these voters randomly decide when sending votes out to either send their own (real or dummy) vote or forward the others.

The following is an illustration of what might occur:

voter_1 ==> sends encrypted vote (xxx) to voter_2
voter_1 ==> sends encrypted dummy vote to voter_3
voter_2 ==> sends encrypted dummy vote to voter_1
voter_2 ==> sends encrypted vote (yyy) to voter_3
voter_2 ==> sends encrypted vote (xxx) to voter_3
voter_3 ==> sends encrypted vote (yyy) to voter_1
voter_3 ==> sends encrypted vote (zzz) to voter_1
voter_3 ==> sends encrypted vote (xxx) to xxx
voter_3 ==> sends encrypted dummy vote to dummy
voter_1 ==> sends encrypted dummy vote to voter_3
voter_1 ==> sends encrypted vote (zzz) to voter_2
voter_1 ==> sends encrypted vote (yyy) to yyy
voter_2 ==> sends encrypted vote (zzz) to zzz
voter_3 ==> sends encrypted dummy vote to dummy

So finally votes for xxx, yyy and zzz arrive but knowing who actually sent them (hopefully unless I've screwed up) should be impossible.

Correct?


Cheers,

Ian.

Ouch - if we are really looking at exponential growth of the block chain then I think the importance of multi-sig txs will rather pale in comparison by the end of the year.


Cheers,

Ian.

The paper only discusses an "open ballot" style of voting (i.e. everyone can see who everyone voted for).


Cheers,

Ian.

Yup - I did look at the article - absolutely zero detail about what they have actually done (technically).


Well foreign countries have not managed to manipulate Bitcoin yet, however, there hasn't been a fair paper ballot in many African countries and some Asian countries ever.


Cheers,

Ian.

Whether Bitcoin or an alternative block chain are actually used is not so much what I'm thinking about but instead whether the Nakamoto block chain combined with perhaps some other (maybe not yet invented?) technology can achieve free and fair voting.

Of course one does not want the government to know what your vote was - but unless we just want rule of the richest it is vital that both they and other 3rd parties can be certain that each voter had (or had the opportunity) to cast exactly one vote.


Cheers,

Ian.

I have read a few recent posts about using Bitcoin for some very different things such as for election vote tallying (with little or nothing in the way of any detail about how this can really work) and am not sure whether or not Bitcoin provides answers to the most challenging problems in this area.

To my mind most importantly one needs to ensure that each individual that is eligible to vote can vote, that no individual can vote more than once and that no authority can be (at least realistically) able to trace an individual's voting choice.

To my thinking this could be perhaps addressed in the following manner:

1) All eligible voters are sent an identifiable voting form (could be in the form of a small BTC payment made by the government that must be spent within a certain time frame).

2) An encrypted voting choice needs to be created by the individual (perhaps a newly generated BTC address created by your favorite party which would somehow need to be signed for the next step to work).

3) Encrypted voting choices to be anonymously exchanged by voters (with signature checks of these voting choices to ensure their validity).

4) Voting forms with the anonymous voter's voting choice are then returned to government (in the form of a BTC repayment).

I'm not sure if BTC is going to be a solution (and step 3 has perhaps little to do with it at all) but I think this kind of approach could lead to something quite important in the future.

Perhaps others can point out on any obvious faults and/or any better solutions to this idea?


Cheers,

Ian.

Thanks - guess I should have mentioned something about that in the first place.


Understand - and no real offense taken (the code review comment did get to me a bit having being a professional software engineer for over 20 years).

Documentation for this system is of course essential and something I will be working very hard on in the next few months (its mostly just a bunch of text notes which I have decided are not yet presentable).


Cheers,

Ian.