Create deterministic but unpredictable ordering #4
Conversation
The previous algorithm relied entirely on trusting the Election Administrator. Nothing prevented a hypothetical corrupt one from running the script multiple times until the desired outcome was produced. This correction allows for verifiability while still maintaining unpredictability a priori. Specifically, it is a pretty safe assumption that no voter can cause a specific collection of candidates to tie for last place; nor even can a small collusion of voters since they do not know how other voters outside the conspirators will vote. It is also necessary to allow selection of more than one winner in an N-way tie, so that capability is added. E.g. in a contest with 11 winners, three candidates may tie for 10/11/12th place. We need to select 2 winners among them, not just one.
|
Samples of usage. Notice the result chosen is consistent but not dependent on order given in command line. 515-tmp % ./break-ties.py -c 'David Mertz' -c 'Guido van Rossum' -c 'Ian Cordasco'
['Guido van Rossum']
516-tmp % ./break-ties.py -c 'Guido van Rossum' -c 'Ian Cordasco' -c 'David Mertz'
['Guido van Rossum']
517-tmp % ./break-ties.py -c 'David Mertz' -c 'Ian Cordasco' -c 'Guido van Rossum'
['Guido van Rossum']If a choice of more than one is needed: 523-tmp % ./break-ties.py -c 'David Mertz' -c 'Ian Cordasco' -c 'Guido van Rossum' -n 2
['Guido van Rossum', 'Ian Cordasco']
524-tmp % ./break-ties.py -c 'David Mertz' -c 'Guido van Rossum' -c 'Ian Cordasco' -n 2
['Guido van Rossum', 'Ian Cordasco'] |
|
The behavior introduced in #1 is specifically not what is desirable here. What we want is reproducibility, and "true randomness" is antithetical to the purpose of the tool. Albeit, without using a seed |
|
Terry Reedy makes a comment on the mailing list, to which I replied privately: Adding external information (e.g. stock closing price) would be fine, but it's overkill. There is plenty of unpredictability in exactly which candidates might tie for last place; enough that tactical voting is highly implausible. Simply using the candidate names as a seed is completely adequate. Yes... this has the result that before the election even starts, we know who would win if the tie happens to be exactly between 'Massimo DiPierro' and 'Terry Jan Reedy'. But you really aren't going to know that. The tie between "David Mertz" and "Terry Jan Reedy" might go differently (again, knowable in advance under my patch). But so what?! To cheat you'd need to know both that you (or your preferred candidate) would come in exactly tied for 11th place AND whom you'd tie with. The tie could also be among more than 2 candidates, which you'd have to know a priori. In concept, you could decide whether to call yourself "Terry Jan Reedy" or "Terry J Reedy" to affect this (but only if you submitted your name after the spelling of everyone else's was fixed).... and if you're trying to win at that margin, you'd do a lot better editing your candidate statement than playing with those cryptographic margins. A couple votes won by actual campaigning would make you come in 10th place and the issue would be moot. |
The previous algorithm relied entirely on trusting the Election Administrator. Nothing prevented a hypothetical corrupt one from running the script multiple times until the desired outcome was produced. This correction allows for verifiability while still maintaining unpredictability a priori. Specifically, it is a pretty safe assumption that no voter can cause a specific collection of candidates to tie for last place; nor even can a small collusion of voters do so since they do not know how other voters outside the conspirators will vote. If a majority wanted to "conspire" they could also simply elect the candidate(s) they wanted.
It is also necessary to allow selection of more than one winner in an N-way tie, so that capability is added. E.g. in a contest with 11 winners, three candidates may tie for 10/11/12th place. We need to select 2 winners among them, not just one.