Zum Inhalt springen.
Sympa Menü

ag-liquid-democracy - [AG Liquid Democracy] Weg aus dem Nachvollziebar-Geheim-Dilemma?

ag-liquid-democracy AT lists.piratenpartei.de

Betreff: Liquid Democracy in der Piratenpartei

Listenarchiv

[AG Liquid Democracy] Weg aus dem Nachvollziebar-Geheim-Dilemma?


Chronologisch Thread 
  • From: Jacob Kanev <j_kanev AT arcor.de>
  • To: ag-liquid-democracy AT lists.piratenpartei.de
  • Subject: [AG Liquid Democracy] Weg aus dem Nachvollziebar-Geheim-Dilemma?
  • Date: Fri, 04 Oct 2013 15:11:33 +0200
  • List-archive: <https://service.piratenpartei.de/pipermail/ag-liquid-democracy>
  • List-id: Liquid Democracy in der Piratenpartei <ag-liquid-democracy.lists.piratenpartei.de>

 

Liebe Leute,

 

soweit ich sehen kann, sind online-Wahlen entweder nachvollziebar, oder geheim, aber beides geht nicht (korrigiert mich bitte, wenn ich mich irre). Da wir aber gerne beides hätten, haben wir ein Problem. Mir ist möglicherweise eine Wahlmethode eingefallen, die sowohl nachvollziehbar als auch geheim ist. Leider ist die Methode etwas exotisch und wahrscheinlich schwer vermittelbar. Eventuell könnte man aber einen Teilgedanken aufgreifen und in ein zukünftiges Tool einbauen, oder aber die Methode so verändern, daß sie benutzbar wird. Grundgedanke ist folgender:

 

Jeder Wähler entscheidet sich nicht für ein glattes Ja/Nein, sondern für eine Verteilung. Das Gesamtergebnis der Wahl wird berechnet, indem über alle abgegebenen Verteilungen summiert und dann das Ergebnis normiert wird. Allerdings werden bei der Stimmabgabe nicht die einzelnen Verteilungen übermittelt, sondern ein stochastisches Sample pro Wähler aus seiner Verteilung (Monte-Carlo-Algorithmus). Damit bleibt die Wahl komplett nachvollziehbar aber trotzdem komplett geheim. Der Hauptnachteil ist allerdings (und der ist gravierend), daß die Wahl ungenau, und nur bei hoher Beteiligung aussagekräftig wird. Konkret würde eine Wahl so ablaufen:

 

Eine Frage soll online abgestimmt werden. Es gibt Antwortmöglichkeiten A oder B. Die Wählende überlegt sich eine Verteilung, z.B. stimmt sie zu 70% mit A, zu 30% mit B überein. Ein lokaler Client wird gestartet und die Verteilung 70%A,30%B eingegeben. Im Client läuft dann ein Zufallsgenerator, der aus dieser Verteilung zufällig EIN Sample zieht, z.B. "B". Der Wähler sieht die Wahl "B" bevor sie an den zentralen Pool übermittelt und protokolliert wird. Die Verteilung wird *nicht* übermittelt, und möglicherweise nicht einmal lokal gespeichert. Angenommen alle 100 Wahlbeteiligten entscheiden sich zu 70% für A und zu 30% für B, dann sind am Ende *ziemlich* genau 70% der Stimmen im Topf für A und 30% für B. "Ziemlich" bedeutet, daß es einen Fehler im Wahlergebnis gibt. Diese Abweichung des Gesamtergebnisses von 70/30 beträgt dann schätzungsweise (Erwartungswert) <Fehler> = sqrt( Anteil A * Anteil B / #Wähler ), also in unserem Fall sqrt(70% * 30% / 100) = 4.6%. Der Fehler wird mit steigender Zahl an Wählern geringer und ist bei 1000 Wählern schon vernachlässigbar. Das funktioniert natürlich genauso, wenn jede Wählerin einen andere Verteilung angibt.

 

 

Vorteile:

 

1. Die Wahl ist nachvollziehbar: Stimmen werden offen abgegeben und können nachvollziehbar protokolliert werden. Jeder Wähler weiß, welche Stimme er abgegeben hat. Jeder Wähler kann das Ergebnis überprüfen.

 

2. Die Wahl ist geheim: Anhand der abgegebenen Stimme ist nicht ersichtlich, welche Verteilung der Wähler eingegeben hat. Alles was man sehen kann ist, daß wenn "B" abgegeben wird, nicht 100%A,0%B gewählt wurde. Aber selbst 95%A,5%B sind noch möglich. Trotzdem ist das Endergebnis sehr nahe an dem Ergebnis, daß man hätte, wenn man Verteilungen direkt addieren würde.

 

3. Delegationen verändern die Geheimhaltung: Wenn eine Wählerin aufgrund von Delegationen mehrere n Stimmen auf sich vereint, wird sie n-mal abstimmen, d.h. es wird n-mal ein Sample aus der gleichen Verteilung gezogen. Das bedeutet, daß sich mit steigenden n die angegebene Verteilung immer besser aus den abgegebenen Stimmen rekonstruieren läßt. Vereint der Wähler z.B. 100 Stimmen auf sich, kann man seine eigentliche Wahl mit ca. 5%er Genauigkeit abschätzen. D.h. aus mehr Verantwortung resultiert mehr Transparenz.

 

4. Die Wahl ist nicht manipulierbar: Siehe 1, zusätzlich können natürlich alle Komponenten (Client eingeschlossen) OpenSource sein. Der Wähler kann sich vor jeder Stimmabgabe von der richtigen Kalibrierung das Zufallsgenerators überzeugen - der Client kann etwa die Verteilung zur Überprüfung grafisch samplen und die Wählerin wählt zufällig ein Sample aus (z.B. auch graphisch).

 

 

Nachteile:

 

1. Die Wahl wird ungenau. Das Gesamtergebnis kann vom Wählerwillen abweichen. Die zu erwartende Abweichung ist bekannt und kann berechnet werden (siehe oben), das Ganze ist binomial- und die Abweichung Gauß-verteilt. Allgemein sind Wahlen mit geringer Beteiligung wenig aussagekräftig. Genaue Abstimmungen, bei denen eine knappe Mehrheit entscheiden könnte, sind nicht möglich.

 

2. Das Verfahren wird nur schwer zu vermitteln sein - streng genommen ist der Wähler nicht mehr für seine eigentlich abgegebene Stimme verantwortlich. Man könnte den Vorwurf machen, die Piraten entscheiden mit dem Zufallsgenerator. (Andererseits wird uns das ja eh schon vorgeworfen, oder?)

 

 

Könnte man das in irgendeiner Form einsetzen? Oder abwandeln und dann einsetzen? Oder Teile davon? Oder ist die Sache zu abwegig? Was meint Ihr?

 

Viele Grüße, Jacob.

 

--

____________________________

Boomtime, 58th of Bureaucracy, 3179.

jacob kanev

twitter: @j_kanev

jabber: jkanev AT jabber.ccc.de

 




Archiv bereitgestellt durch MHonArc 2.6.19.

Seitenanfang