[fc-discuss] Financial Cryptography Update: A Small Experiment with Voting - Mana v. Medici

[iang@iang.org]

 Financial Cryptography Update: A Small Experiment with Voting - Mana v. Medici 

                            August 11, 2005


------------------------------------------------------------------------

https://www.financialcryptography.com/mt/archives/000530.html



------------------------------------------------------------------------

Voting is a particularly controversial application (or feature) for FC
because of the difficulty in both setting the requirements, and the
'political requirement' of ensuring a non-interfered vote for each
person.  I've just got back from an alpine retreat where I participated
in a small experiment to test votes with tokens.  The retreat was
specifically purposed to do the early work to build a voting
application, so it was fun to actually try out some voting.

Following on from our pressed flower production technique, we 'pressed
& laminated' about 100 beatles, or symbols looking like beatles.  These
were paired in plus and minus form, and created in sets of similar
symbols, with 5 colours for different purposes.  Each person got a set
of 10, being 5 subsets of two complementary pairs each.

The essence of the complicated plus and minus tokens was to try out
delegated voting.  Each user could delegate their plus token to another
user, presumably on the basis that this other user would know more and
was respected on this issue.  But they could always cast their minus to
override the plus, if they changed their minds.  More, it is a sad fact
of voting life that unless you are in Australia, where political voting
is compulsory, most people don't bother to turn up anyway.

To simulate this, we set up 4 questions (allocating 4 colours) to be
held at 4 different places - a deliberate conflict.  One of the
questions was the serious issue of naming the overall project and we'd
been instructed to test that;  the others were not so essential.  Then
we pinned up 21 envelopes for all the voters and encouraged people to
put their plus tokens in the named envelope of their delegatee.

When voting time came, chaos ensued.  Many things went wrong, but out
of all that we did indeed get a vote on the critical issue (not that
this was considered binding in any way).  Here's the stats:

Number of direct voters:  4
Number of delegated votes:  3
Therefore, total votes cast:  7
Winning project name:  Mana, with 3 votes.

So, delegated voting increased the participation by 75%, taking total
participation to 33% (7 of 21 participants).  That's significant -
that's a huge improvement over the alternate and indicates that
delegated voting may really be useful or even needed.  But, another
statistic indicates there is a lot more that we could have done:

Number of delegated votes, not cast:  9

That is, in the chaos of the game, many more people delegated their
votes, but the tokens didn't make it to the ballot.  The reasons for
this are many:	one is just the chaos of understanding the rules and
the way they changed on the fly!  Another is that many delegatees
simply didn't participate at all, and in particular the opinion leaders
who collected fat envelopes forgot they were supposed to vote, and just
watched the madness around them (in increasing frustration!).

Canny FCers will recognise another flaw in the design - having placed
the tokens into envelopes, the delegators then had to become delegatees
and collect from their envelopes.  And, if they were not to then attend
that meeting (there were 4 conflicting meetings, recall) then the
delegatees would become delegators again and re-delegate.  Thus forcing
the cycle to start again, ad infinitum.

Most people only went to the pinboard once.  So the formal delegation
system simply failed on efficiency grounds, and it is lucky that some
smart political types did some direct swaps and trades on their
delegated votes.

How then to do this with physical tokens is an open question.  If one
wants infinite delegation, I can't see how to do it efficiently.  With
a computer system, things become more plausible, but even then how do
we model a delegated vote in software?

Is it a token?	Not quite, as the delegate vote can be overridden and
thus we need a token that can be yanked back.  Or overridden or
redirected.  So it could be considered to be an accounting entry - like
nymous account money - but even then, the records of a payment from
alice to bob need to be reversable.

One final result.   Because I was omnipresent (running the meeting that
took the important vote) I was able to divine which were the delegated
votes.	And, in this case, if the delegated votes had been stripped
out, and only direct voting handled, the result of the election
decision woudl have changed:  the winning name would have been Medici,
which was what I voted for.

Which I count as fairly compelling evidence that whatever the
difficulties in implementing delegated voting, it's a worthwhile goal
for the future.

-- 
Powered by Movable Type
Version 2.64
http://www.movabletype.org/