Server-Seed und Client-Seed: Wie der Crash-Spiel-Zufall wirklich funktioniert

Server-Seed und Client-Seed sind die kryptografischen Bausteine, die Crash-Spiele beweisbar fair machen. In den meisten Artikeln liest du die Marketing-Version ("das Casino wählt einen Seed, du wählst einen Seed, beide kombinieren zum Ergebnis") und damit hat sich's. Diese Ebene stimmt zwar, bringt dir aber praktisch nichts. Erst wenn du die Mechanik bis aufs Bit verstehst, kannst du wirklich verifizieren und damit auch fundiert vertrauen. In diesem Artikel gehen wir die Seeds im Detail durch: wie sie erzeugt werden, woher sie kommen, wie sie kombinieren, wann sie freigegeben werden und was du machst, wenn das Reveal ausbleibt.

Warum dieser Detailgrad lohnt: Die kryptografische Garantie hängt an konkreten Eigenschaften der Seeds (Unabhängigkeit, Unvorhersehbarkeit, Festlegungszeitpunkt). Wer die Mechanik kennt, trennt Vertrauen von Glauben. Glauben heißt "das Casino rechnet schon ehrlich". Vertrauen heißt "ich kann die Mathematik selbst nachrechnen, weil ich verstehe, wie die Eingaben zusammenkommen". Letzteres trägt, ersteres braucht Hoffnung.

Server-Seed: was er ist und wie er entsteht

Der Server-Seed ist eine lange zufällige hexadezimale Zeichenkette, die der Server vom Casino direkt vor jeder Runde erzeugt. Die Länge richtet sich nach der genutzten Hashfunktion:

• Bei SHA-256-Schemata (SmartSoft, BGaming, Turbo Games, Upgaming, InOut Games, 1win Gaming, Pragmatic Play, Evolution, die meisten Anbieter): 64 Hex-Zeichen entspricht 256 Bit.
• Bei SHA-512-Schemata (Spribe / Aviator, Aviatrix, Pilot): 128 Hex-Zeichen entspricht 512 Bit.

Wie genau der Seed entsteht, unterscheidet sich je nach Anbieter, folgt aber kryptografischer Standardpraxis:

1. Der Casino-Server zapft Entropie aus einer Quelle auf Betriebssystemebene an (Linux /dev/urandom, Windows BCryptGenRandom oder etwas Vergleichbares).
2. Diese Entropie füttert einen kryptografischen Zufallszahlengenerator (CSPRNG), der Bits ausspuckt, die sich von echtem Zufall nicht unterscheiden lassen.
3. Die CSPRNG-Ausgabe wird als hexadezimale Zeichenkette in der nötigen Länge formatiert.
4. Das Ergebnis landet privat auf dem Casino-Server und wird nach Rundennummer indexiert.

Drei Eigenschaften sind für dein Vertrauen entscheidend:

• Unvorhersehbarkeit. Den Seed kannst du von außen nicht vorhersagen. Die CSPRNG-Ausgabe ist rechentechnisch von echtem Zufall ununterscheidbar. Selbst wenn du alle bisherigen Seeds kennst, lässt sich der nächste nicht ableiten.
• Privatheit bis zum Reveal. Der Seed bleibt auf dem Server, bis die Runde vorbei ist. Vor Wettannahmeschluss bekommst du nur den SHA-Hash zu sehen.
• Festlegung per Hash. Wenn der Hash vor der Runde veröffentlicht wird, bindet das das Casino. Jeder später freigegebene Seed muss zu genau diesem Wert hashen, sonst ist die Abweichung öffentlicher Beweis für Betrug.

Warum erzeugt das Casino den Server-Seed selbst und nicht eine dritte Partei? Praktische Gründe (serverseitig geht's schnell und ist operativ einfach) plus die kryptografische Schutzwirkung des Commit-Reveal-Schemas. Die Erzeugung muss nicht "trustless" sein, weil das Commit-plus-Reveal-Verfahren sie nach der Runde verifizierbar macht, egal wer den Seed erzeugt hat.

Client-Seed: wie Spieler Entropie beisteuern

Der Client-Seed ist die spielerseitige Hälfte der Entropie. Wer ihn beisteuert und wie, hängt vom Anbieter ab. Der Zweck bleibt aber gleich: das Casino soll keinen Server-Seed wählen können, der ein bestimmtes Ergebnis produziert. Das geht nur, wenn Eingaben einfließen, die das Casino nicht kontrolliert.

Spribe (Aviator und Spribe-Titel): drei Client-Seeds. Bei Rundenstart zieht der Casino-Server Client-Seeds von den ersten drei Spielern, die in der konkreten Runde wetten. Jeder Seed ist eine Hex-Zeichenkette (typisch 32 Zeichen), clientseitig vom Browser des Spielers beim Verbindungsaufbau erzeugt, mit Browser-Entropiequellen wie window.crypto.getRandomValues in modernen Browsern. Die drei Seeds entstehen unabhängig voneinander bei drei unabhängigen Spielern, die einander nicht kennen und sich nicht absprechen können (sie werden zufällig aus den ersten Wettenden der Runde gegriffen).

SmartSoft (JetX und SmartSoft-Crash-Titel): ein Client-Seed. Du als wettender Spieler steuerst einen Client-Seed bei. Der Seed leitet sich typischerweise aus einer casinoseitig gehashten Konto-ID ab oder ist eine zufällig erzeugte Zeichenkette, die du in den Kontoeinstellungen ändern kannst. Das Ein-Seed-Schema entspricht der Bustabit-Spezifikation von 2014 und ist Branchenstandard.

1win Gaming (Lucky Jet, Rocket X, Rocket Queen): vier Client-Seeds. Dein eigener Seed plus drei von zufälligen anderen Live-Teilnehmern der Runde. Kryptografisch ähnlich zu Spribes Drei-Seed-Schema, aber mit einer zusätzlichen unabhängigen Eingabe. Strukturell noch strenger gegen Manipulation. Ein erfolgreicher Angriff bräuchte die gleichzeitige Kompromittierung der Seeds von vier unabhängigen zufälligen Spielern.

BGaming (Aviamasters, Space XY und so weiter): ein Client-Seed plus optional Bitcoin-Block-Hash. Standard SHA-256 mit einem Client-Seed bei den meisten BGaming-Titeln. Bei ausgewählten Titeln zieht das Spiel den jüngsten Bitcoin-Block-Hash als zusätzliche Entropiequelle dazu. Der Bitcoin-Block-Hash ist öffentlich nachprüfbar, mit Zeitstempel zum Rundenstart versehen und nicht manipulierbar, ohne das gesamte Bitcoin-Netzwerk zu kompromittieren. Mathematisch eine kleine Verbesserung gegenüber Standard-Ein-Seed, aber als Vertrauenssignal für krypto-affine Spieler nicht zu unterschätzen.

Warum Spribe drei Client-Seeds nutzt

Die Drei-Client-Seed-Innovation ist es, was Aviators Provably-Fair-Schema strukturell strenger macht als die übliche Genre-Linie. Das Argument:

Bei einem Client-Seed (SmartSoft, BGaming, die meisten Anbieter) hat der seedbeisteuernde Spieler theoretischen, kryptografisch begrenzten Einfluss aufs Ergebnis. Das Casino muss sich auf den Server-Seed festlegen, bevor es den Client-Seed kennt. Aber ein Spieler, der seinen eigenen Seed im Voraus vorhersagen kann und den Festlegungszeitpunkt kennt, könnte theoretisch die Eingabekombination beeinflussen. Die Schranke dieses Angriffs ist bei SHA-256 mit ordentlichem CSPRNG mathematisch sehr klein, aber die strukturelle Angriffsfläche existiert.

Bei drei unabhängigen Client-Seeds (Spribe) bräuchte der Angriff die gleichzeitige Kompromittierung der Seeds von drei unabhängigen zufälligen Spielern. Die ersten drei Wettenden jeder Runde lassen sich nicht im Voraus vorhersagen (es ist einfach, wer als Erstes wettet). Selbst das Casino weiß bei Rundenbeginn nicht, welche drei Spieler beisteuern. Drei unabhängige zufällige Spieler zu kompromittieren ist in jeder Größenordnung praktisch unmöglich.

Das Vier-Client-Seed-Schema (1win Gaming) erweitert diese Logik um eine zusätzliche unabhängige Eingabe. Marginale Verbesserung gegenüber drei Seeds, der strukturelle Vorteil ist ähnlich.

Praktisch: SHA-256 mit einem Client-Seed ist 2026 mathematisch verteidigbar (kein bekannter Angriff klappt in praktischer Zeit). SHA-512 mit drei Seeds ist um Größenordnungen strukturell strenger. Die Wahl ist konservativ vs. Standard, nicht sicher vs. unsicher. Spribe hat sich für die konservative Stufe entschieden, die meisten anderen für die Branchenstandard-Stufe. Beide sind ehrlich. Das Vertrauensnarrativ zählt für die Spielerwahrnehmung mehr als der mathematische Unterschied.

Wie Seeds kombinieren: Verkettung plus Hash

Die Seeds und die Nonce werden zu einer einzigen Zeichenkette verkettet. Diese Kette wird gehasht, der Digest bestimmt den Crash-Multiplikator. Mechanisch sieht das so aus:

Spribe (Aviator) Eingabekombination:

hash_input = server_seed + "|" + client_seed_1 + "|" + client_seed_2 + "|" + client_seed_3 + "|" + nonce
digest = SHA-512(hash_input)

Welches genaue Trennzeichen verwendet wird, ist Implementierungssache (manche nutzen ":" oder "," oder gar keines). Das Prinzip bleibt gleich. Die Verkettung erzeugt eine pro Runde eindeutige Zeichenkette, der SHA-512-Hash spuckt einen 128-Zeichen-Hex-Digest aus, der für diese Eingabekombination einmalig ist.

SmartSoft (JetX) Eingabekombination:

hash_input = server_seed + "|" + client_seed + "|" + nonce
digest = SHA-256(hash_input)

Ein-Seed-Schemata haben dieselbe Struktur, einfach mit einem Client-Seed weniger und SHA-256 statt SHA-512. Die Ausgabe ist ein 64-Zeichen-Hex-Digest.

Aus dem Digest extrahieren die Anbieter eine Bruchzahl h zwischen 0 und 1:

• Spribe: die ersten 13 Hex-Zeichen des SHA-512-Digests. Hex zu Ganzzahl umrechnen, durch 16^13 (den Maximalwert von 13 Hex-Zeichen) teilen. Heraus kommt h.
• SmartSoft: die ersten 8 Hex-Zeichen des SHA-256-Digests. Hex zu Ganzzahl umrechnen, durch 16^8 teilen. Heraus kommt h.
• Andere Anbieter: abweichende Hex-Schnittlängen, aber dasselbe Umrechnungsprinzip.

Die Bruchzahl h fließt in die Crash-Multiplikator-Formel: crash_point = (100 - hausvorteil) / (100 × (1 - h)). Auf zwei Nachkommastellen runden, fertig ist der Multiplikator, bei dem die Runde endet. Das Verfahren ist deterministisch, gleiche Eingaben liefern immer gleiche Ausgaben. Wenn du tiefer in den Algorithmus einsteigen willst, schau dir unseren Artikel zum Crash-Spiel-Algorithmus mit Code-Beispielen an.

Die Nonce: was sie macht

Die Nonce ist ein simpler Rundenzähler, der pro Runde unter demselben Server-Seed-Schlüssel um eins hochzählt. Ihr Zweck: jede Runde erzeugt einen eindeutigen Digest, selbst wenn Server-Seed und Client-Seeds zwischen Runden zufällig identisch wären.

Mechanisch: Zu Beginn eines Server-Seed-Schlüssels (typisch alle paar Stunden oder alle paar Tausend Runden rotiert) startet die Nonce bei 0 (oder 1, je nach Implementierung). Jede Runde erhöht sie um 1. Sobald das Casino den Server-Seed-Schlüssel rotiert, springt die Nonce unter dem neuen Schlüssel zurück auf 0.

Wozu das Ganze? Ohne Nonce würden zwei Runden mit identischen Server-Seed- und Client-Seed-Werten denselben Digest produzieren. In der Praxis kommt das kaum vor (Seeds sind zufällig), aber die Nonce schließt diese Möglichkeit komplett aus. Sie erlaubt Verifizierern auch eine Quersicht auf die Rundenfolge: Runde 5 unter Server-Seed-Schlüssel X muss Nonce 5 haben. Wenn die Operator-Oberfläche Runde 5 mit Nonce 7 zeigt, ist die Diskrepanz Beweis dafür, dass Runden übersprungen oder manipuliert wurden.

Das Reveal-Protokoll: wann Seeds rauskommen

Der Vertrauensmechanismus hängt komplett daran, dass das Reveal verlässlich passiert. So läuft das Protokoll:

1. Vor der Runde (etwa 5 bis 10 Sekunden vor Wettannahmeschluss): Server erzeugt den Server-Seed, berechnet seinen SHA-Hash und veröffentlicht den Hash in der Operator-Oberfläche. Du siehst den Hash, aber nicht den Seed.
2. Wetten geschlossen, Runde läuft: Client-Seeds werden von den ersten N Spielern gezogen (je nach Schema), die Verkettung plus Hash plus Digest-Extraktion plus Crash-Punkt-Berechnung passieren serverseitig, der Multiplikator steigt und stürzt nach der Formelausgabe.
3. Runde endet: Das Casino veröffentlicht den freigegebenen Server-Seed im Klartext in der Operator-Oberfläche. Der Seed ist jetzt öffentlich.
4. Verifizierung (nach dem Reveal): Du kannst den freigegebenen Seed durch SHA-256 oder SHA-512 (je nach Schema) jagen und prüfen, dass der Digest zum vor der Runde publizierten Hash aus Schritt 1 passt. Außerdem kannst du den ganzen Algorithmus mit freigegebenem Seed plus Client-Seeds plus Nonce neu durchrechnen, um zu bestätigen, dass der Crash-Multiplikator dem entspricht, was das Spiel angezeigt hat.

Das Reveal muss passieren, sonst ist die kryptografische Verpflichtung wertlos. Ohne Reveal hast du nur das Wort vom Casino, auf welchen Seed es sich festgelegt hat. Die Verpflichtung ist nicht überprüfbar. Tier-1-lizenzierte Operatoren (UKGC, MGA, Spelinspektionen, AGCO Ontario) legen immer offen, weil Behörden das Protokoll auditieren. Manche Curacao-Buden verstecken das Reveal hinter Support-Anfragen oder lassen es ganz weg. Das hebelt das Protokoll komplett aus.

Was tun, wenn Seeds nicht offengelegt werden

Du spielst eine Runde und der Operator rückt den freigegebenen Server-Seed danach nicht raus? Dann ist das Spiel nicht beweisbar fair, egal was das Marketing verspricht. Drei eskalierende Reaktionen:

1. Erste Beobachtung: Provably-Fair-Einstellungsfenster vom Operator öffnen, Rundenverlauf prüfen, nach dem freigegebenen Seed suchen. Manche Operatoren vergraben ihn 3 bis 4 Klicks tief. Findest du ihn wirklich nicht in der UI, kontaktiere den Support.
2. Support-Anfrage: Bitte den Support, dir den freigegebenen Server-Seed für die konkrete Runde zu schicken. Gib ihm 7 Tage Zeit. Seriöse Operatoren liefern. Unseriöse halten dich hin oder weigern sich.
3. Spielen einstellen: Legt der Operator Seeds nicht zuverlässig offen, fehlt die kryptografische Schutzwirkung. Das Spiel läuft technisch beweisbar fair beim Anbieter, aber der Operator-Mantel hält das Protokoll nicht ein. Wechsle den Operator. Such dir Tier-1-lizenzierte Casinos mit auditierten Reveal-Prozeduren.

Verstecktes Reveal ist eines der stärksten Signale für einen unzuverlässigen Operator. Das Casino hat nichts zu gewinnen, wenn es Seeds versteckt und seine Mathematik ehrlich ist. Es hat aber etwas zu gewinnen, wenn die Mathematik unehrlich ist. Behandle Reveal-Hürden als rote Flagge gegen den Operator. Den breiteren Vertrauensrahmen behandeln wir in unserem Artikel zur Manipulationsfrage bei Crash-Spielen mit dem Schichtenschutz aus Provably-Fair-Schema, Lizenz und Verifizierungs-Gewohnheit.

Werkzeug-Durchgang: deine Runde mit den Seeds verifizieren

So läuft eine Verifizierung mit Server-Seed- und Client-Seed-Eingaben konkret ab:

1. Aviator bei deinem Operator öffnen. Eine Runde spielen oder eine aus der Historie aufrufen.
2. Provably-Fair-Fenster öffnen: typisch über Einstellungen → Provably Fair Settings → Meine Wetten → Runde anklicken → Show me the math.
3. Die vier Werte kopieren: freigegebener Server-Seed, Client-Seed 1, Client-Seed 2, Client-Seed 3, Nonce.
4. Unseren Browser-Verifier in einem neuen Tab öffnen.
5. Schema wählen: SHA-512 plus 3 Seeds (Spribe / Aviator).
6. Die vier Werte in die entsprechenden Felder einfügen.
7. Auf Berechnen klicken. Der Verifier hasht die Eingaben via SHA-512, extrahiert die ersten 13 Hex-Zeichen, berechnet h, wendet die Crash-Formel an und zeigt dir den berechneten Crash-Punkt.
8. Die Verifier-Ausgabe mit dem im Spiel angezeigten Crash-Multiplikator vergleichen. Stimmt es überein, war die Runde ehrlich. Weicht es ab, eskalier zum Operator-Support und (falls ungelöst) zur Behörde.

Gesamtdauer: 60 Sekunden pro Runde. Die Mathematik ist identisch zu der, die der Server von Spribe rechnet. Nur der Ausführungsort ist anders (dein Browser statt Casino-Server). Gleiche Eingaben liefern gleiche Ausgaben. Genau das ist die Eigenschaft des Determinismus, angewandt auf seedbasierte Verifizierung.

Redaktionelles Fazit: Seeds sind das kryptografische Fundament des Crash-Vertrauens

Server-Seed und Client-Seed sind die elementaren Bausteine, die Provably-Fair-Crash-Spiele wirklich fair machen. Wenn du sie auf Mechanik-Ebene verstehst, kannst du den Vertrauensrahmen bewerten statt blind zu glauben. Spribes Drei-Client-Seed-Innovation ist strukturell echt bedeutsam. Die SmartSoft-Standardlinie aus einem Client-Seed ist mathematisch verteidigbar, aber strukturell weniger streng. Das 1win-Vier-Seed-Schema ist sogar strenger als Spribes drei. Alle vier Schemata (ein Seed, drei Seeds, vier Seeds, mit oder ohne Bitcoin-Entropie) sind glaubwürdig, keines ist gebrochen. Den Vertrauensunterschied macht der Operator-Mantel um die Seed-Mechanik, nicht der kryptografische Baustein selbst.

Erst das Reveal macht die Mathematik aussagekräftig. Operatoren, die Reveals verlässlich publizieren (Tier-1-Casinos mit UKGC plus MGA plus Spelinspektionen), machen Verifizierung möglich. Operatoren, die Reveals verstecken (manche Offshore-Curacao-Plattformen), hebeln das Protokoll aus, egal wie gut die Mathematik dahinter ist. Behandle Reveal-Hürden als das stärkste Operator-Vertrauenssignal, auf das du reagieren kannst. Kombiniere das kryptografische Verständnis mit Lizenz-Aufsicht und Verifizierungs-Gewohnheit (Stichprobe pro Sitzung). Der Schichten-Rahmen erzeugt tragfähiges Vertrauen, das keine einzelne Schicht allein liefert.

Den breiteren Provably-Fair-Durchgang behandelt unser Provably-Fair-Leitfaden auf Protokollebene. Den Algorithmus auf Code-Ebene führt Crash-Spiel-Algorithmus aus. Den operativen Verifizierungs-Durchgang deckt Crash-Spiel verifizieren Schritt für Schritt ab. Dieser Artikel über Seeds ist das Bit-Fundament, die anderen bauen darauf auf.