August 11, 2005
A Small Experiment with Voting - Mana v. Medici
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, called Beetle In A Box. 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 squashed 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 would 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.
I am highly suspicious of any system that requires voting to make a decision. In very few cases have I seen that voting cannot be simplified out of the decisionmaking process with substantial benefit to all involved.
Many think that voting is the way to minimize the number of dis-satisfied people. But very few actual voting systems come anywhere close to actually achieving that goal.
From an FC point of view, voting is a more difficult problem than payment, which also indicates that it is a costy endeavor and one has to think twice before going forward with a voting.
Moreover, the more pepole vote, the less sense it makes, given the large transaction costs (the more complicated the system is, the more voters you lose).
Think about it this way: one places a certain value on one outcome versus the other (in the binary case, which is trivial to generalize). Then one calculates the probability that his/her vote will decide the outcome (decays roughly with the square root of the number of voters). The product of these two is the (expected) benefit from voting. If the (transaction) cost of voting exceeds this value (as is almost always the case in political votes), it is irrational to vote, which is why rational people (like myself :-)) abstain from voting in places where it is not compulsory. One consequence of this is that if the preferences are strongly correlated with the rationality, it is the choice preferred by irrational people that is going to win the vote (which still does NOT make it rational to vote; think about it).
Voting is only rational when the stake is large and the number of voters small.
Also, voting is very sensitive to all nuances in the rules. Take, for example, the latest general elections in Hungary: the barrier for a party to enter the parliament is 5%. Given the same votes, the current opposition would be in power if this paramenter would have been either 4% or 6%. So go figure.
Weighed voting is another nightmare. For a long time, Luxemburg had exactly zero say in the European Comission. Here's a small example:
Alice and Bob have 4 votes, Claire has 2 and Daniel has only 1. In this setting, the binary issues are determined by the majority of Alice, Bob and Claire, while Daniel's vote doesn't affect the outcome.
Most voting systems are riddled with flaws of this kind, and even those that are not do a very poor job at decision-making.
I guess, my comment can be summed up like this:
Designing a good voting system is much more difficult than designing a good payment system (which is difficult enough), and very probably not worth the effort. Tossing a coin is a preferable alternative in a surprisingly large number of cases.
Electronic voting is perhaps the hardest discipline of financial cryptography. It's a very good way to teach and learn it, but there are very few justified applications. I don't know of any.
I agree with most of that. There are a couple of caveats here. Firstly, the group has decided to do voting, or been chartered to do voting, and that's that. Many of the things that you point out came out in the design discussions and they remain barriers to cross.
One of the things that was apparent was that delegated voting is much harder, and takes us into territory where computing is needed. I suggested they do direct voting in the first instance, and leave delegated voting for another day. Given the efficiency argument though it is going to be essential for a real application.
Surprisingly, they also went for non-anonymous voting, which I think is only used where accountability is important.
As to whether you can economise it out in all cases, I think this is hopeful. Many structures have mandated voting requirements, and those will stay for a long time. For this reason, I'll be adding voting to Ricardo and XML-X at some stage, but at least in that environment the side issues such as authentication are solved, and the only question is what the best voting mechanism is. My view there is gradually migrating to "all of them" and some sort of smart contracts voting.
Posted by: Iang at August 19, 2005 02:43 AM