Diskussions-Thread
Situation
Aktuell kommt etwas Unmut bezüglich hoher Jackpots und intransparenter Chancen auf Klammseiten auf (z.B. hier). Letztlich sind "Slots nur Software", die einfach konfiguriert bzw. angepasst werden kann. Während Echtgeld-Casinoseiten in der Regel von unabhängigen Institutionen geprüft werden, bleibt den Usern auf Klamm nichts anderes übrig, als zu hoffen, dass die Seiten und Gewinnchangen tatsächlich fair sind und Jackpots jederzeit fallen können.
Lösung
Um das Problem der Intransparanz zu adressieren, gibt es verschiedene Möglichkeiten die evtl. teilweise schon umgesetzt werden und mehr oder weniger Transparenz schaffen (bitte um Input bzgl. Seiten die bestimmte Maßnahmen verfolgen).
- Ausgiebige Statistik: Statistiken bzgl. Ausschüttungsquote, gefallener Jackpots etc
- Quellcode veröffentlichen: Offenlegung des Quelltexts
Verwendung von Einweg-Funktionen die auf clientseitiger Eingabe für die Zufallsgenerierung basieren
Die für User vermutlich fairste Lösung. Das Prinzip ist in der Bitcoin Welt schon weit verbreitet, und kann z.B. hier nachgelesen werden.
Man kann sich das Ganze so vorstellen:
Es gibt eine Funktion mit 2 Parametern die die Zufallszahlen generiert, z.B.:
GeneriereZufallszahl(UserZahl, ServerGeheimzahl) => Zufallszahl
Für identische Eingaben wird eine identische Ausgabe erzeugt. Wird also die Funktion wie folgt aufgerufen:
GeneriereZufallszahl(1023, 42)
und gibt bspw. für 1023 und 42 die Zahl 1093 zurück, muss sie, wenn sie ein paar Stunden später wieder aufgerufen wird:
GeneriereZufallszahl(1023, 42)
wieder 1093 zurückgeben. Siehe auch Determinismus
Der Parameter bzw. die Eingabe UserZahl wird von dem Client bzw. dem User mit jedem Spiel festgelegt und übermittelt (das kann der Flash-Slot automatisch, aber auch der User händisch machen). Die Serverzahl wird in regelmäßigen Abständen (z.B. alle 24h) neugeneriert, und wird nachdem sie (z.B. nach 24h) durch eine neue Serverzahl ersetzt wurde, veröffentlicht.
Die Funktion GeneriereZufallszahl ist öffentlich und für die User nachvollziehbar, z.B. md5($userZahl.$serverZahl);
Außerdem ist es eine Einweg-Funktion, das heisst, man kann zwar die Zufallszahl auf Grundlage der Eingabe(User- und Serverzahl) berechnen, man kann aber nicht von der Zufallszahl auf die Eingabe rückschließen bzw. Eingabewerte finden die eine bestimmte Zufallszahl generieren.
Beispiel:
Wüsste ich als User, dass die Zufallszahl 10.000 den Jackpot gewinnt, und wüsste ich was die Serverzahl ist, sagen wir "42" (was ich NICHT weiss), würde ich versuchen wollen, meine UserZahl so zu wählen, dass die Zufallszahl 10.000 ergibt, also:
GeneriereZufallszahl(X, 42)=10000 <= Also versuche ich nach X aufzulösen, das geht bei einer Einweg-Funktion aber nicht. (Für den interessierten Leser: Ausnahme: Kollisionsangriff)
...zurück zum Prinzip. Nach dem nun die Serverzahl veröffentlicht wurde kann der User alle Zufallszahlen und alle Spiele nachprüfen die er in dem Zeitraum, in dem die Serverzahl gültig war, gemacht hat. Denn, er weiss welche Userzahlen er an den Server übermittelt hat, und was das Ergebnis war.
Ich hoffe die Logik ist einigermaßen klar geworden. Was haltet ihr generell von dem Konzept?