Mines-Fairness

​

Was wann festgelegt wird

1. Sie legt den Beitrag des Betreibers per Commit fest. Das Backend erzeugt einen zufälligen 32-Byte-server_seed, und die Transaktion speichert dessen SHA-256-Hash – den Commit. Der Seed selbst bleibt bis zum Spielende verborgen.
2. Sie erfasst Entropie aus der Chain. Das Programm liest den neuesten Slot-Hash aus Solanas SlotHashes-Sysvar und speichert ihn im Spiel.
3. Sie friert die Konditionen ein. Hausvorteil, Auszahlungsobergrenze und Rückerstattungs-Timeout werden als Snapshot in deinem Spiel gespeichert; nichts kann ein Spielfeld neu bepreisen, auf dem du bereits spielst.

​

Wie wird das Mines-Spielfeld abgeleitet?

Eingaben
  server_seed  32 Bytes   Seed des Betreibers, bei Spielstart als sha256(server_seed) festgelegt
  slothash     32 Bytes   neuester Solana-Slot-Hash, wenn die Start-Transaktion ausgeführt wird
  user         32 Bytes   die Adresse deines On-Chain-Nutzerkontos
  nonce        8 Bytes    dein Mines-Spielzähler, Little-Endian
  mines_count  1..24      die Anzahl der Minen, die du gewählt hast

Zufallsstrom: SHA-256-Blöcke, je 4 Bytes auf einmal verbraucht
  block(k)   = sha256( server_seed ‖ slothash ‖ user ‖ nonce ‖ "mines" ‖ k )
               // "mines" = 5 ASCII-Bytes; k = Blockzähler 0, 1, 2, … als 8 Bytes Little-Endian
  next_u32() = die nächsten ungelesenen 4 Bytes des aktuellen Blocks, Big-Endian;
               ist ein Block aufgebraucht, weiter mit block(k+1)

unverzerrte Ziehung in 0..bound (Rejection Sampling, keine Modulo-Verzerrung)
  draw(bound):
    zone = 4294967295 − (4294967295 mod bound)
    wiederhole v = next_u32() bis v < zone
    gib v mod bound zurück

Spielfeld: partieller Fisher–Yates-Shuffle
  tiles = [0, 1, …, 24]
  mine_mask = 0
  for i in 0..mines_count:
      j = i + draw(25 − i)
      tausche tiles[i] und tiles[j]
      mine_mask = mine_mask OR (1 << tiles[i])

• Die Reihenfolge der Hash-Eingaben ist exakt: Seed, Slot-Hash, Adresse des Nutzerkontos, Nonce (8 Bytes Little-Endian), der ASCII-Tag "mines", dann der Blockzähler (8 Bytes Little-Endian, beginnend bei 0).
• Jeder 4-Byte-Abschnitt wird Big-Endian gelesen. Ein Block liefert höchstens 8 Ziehungen; bei Bedarf wird der Strom mit dem nächsten Zählerwert nachgefüllt.
• Die Rejection-Sampling-Schleife macht jede Ziehung exakt gleichverteilt: Am Shuffle gibt es keine Verzerrung, über die man streiten könnte.

​

Welche Auszahlungsformel setzt das Programm durch?

                                           k−1
Multiplikator = (1 − Hausvorteil) × product ( (25 − i) / (25 − M − i) )
                                           i=0

M = Anzahl der Minen, k = Anzahl der aufgedeckten sicheren Felder

​

Was das Programm bei der Abrechnung durchsetzt

• sha256(server_seed) muss dem bei Spielstart gespeicherten Commit entsprechen; mit einem anderen Seed lässt sich das Spiel nicht abrechnen.
• Das Spielfeld wird mit der obigen Formel von Grund auf neu abgeleitet. Ein als aufgedeckt gemeldetes Feld, das tatsächlich eine Mine ist, wird abgelehnt; ein gemeldetes Minenfeld, das keine Mine ist, wird abgelehnt; ein Minenfeld, das zugleich als aufgedeckt gemeldet wurde, wird abgelehnt.
• Der Multiplikator wird on-chain aus dem per Snapshot eingefrorenen Hausvorteil und deiner tatsächlichen Anzahl aufgedeckter Felder berechnet, sodass die Auszahlung nicht falsch gemeldet werden kann.
• Das Abrechnungs-Event veröffentlicht dauerhaft den Seed, den Slot-Hash, die vollständige Minenmaske, deine aufgedeckten Felder und das Ergebnis.

​

Was garantiert ist – und was nicht

• Das Spielfeld steht vor deinem ersten Zug fest – durch den Commit plus den gespeicherten Slot-Hash. Minen können sich mitten im Spiel nicht verschieben.
• Bei der Abrechnung kann der Betreiber über das Spielfeld nicht lügen: Ein falscher Seed, eine als sicher gemeldete Mine oder ein vorgetäuschter Minentreffer lassen die Transaktion scheitern.
• Die Konditionen, mit denen du gestartet bist (Hausvorteil, Auszahlungsobergrenze, Timeout), gelten bis zum Ende des Spiels.
• Dein Einsatz kann niemals gesperrt werden: Rechnet der Betreiber nie ab, kann nach dem Timeout des Spiels jeder den Abbruch auslösen, der dir deinen Einsatz zurückerstattet. Im Normalbetrieb kommt es nie so weit: Ein verlassenes Spielfeld wird vor dem Timeout zum aktuellen Multiplikator ausgecasht (siehe Mines), sodass du deine Gewinne behältst und nicht nur deinen Einsatz. Der für jeden aufrufbare Abbruch ist die darunterliegende Garantie für den Fall, dass der Betreiber nicht mehr da ist.

• Der Betreiber kennt das Spielfeld, während du spielst. Das ist strukturell bedingt und kein Fehler dieses speziellen Designs: Aufgedeckte Felder werden sofort off-chain ausgeliefert, und wer sie ausliefert, muss wissen, wo die Minen liegen. Kein Zufallsverfahren ändert daran etwas: Selbst ein per VRF erzeugtes Spielfeld wäre dem Betreiber in dem Moment bekannt, in dem er dein erstes Feld aufdeckt. Was der Commit garantiert: Dieses Wissen kann weder dazu genutzt werden, das Spielfeld zu verändern, noch das Ergebnis falsch zu melden.
• Zeitpunkt des Starts. Das Spielfeld hängt vom Slot-Hash ab, der beim Start deines Spiels erfasst wird, und die Start-Transaktion wird vom Backend eingereicht – dieselbe Timing-Überlegung wie bei den anderen Spielen. Ein Spielfeld im Voraus zu kennen hilft nur, wenn deine Züge vorhersehbar sind; wenn du variierst, wo du klickst, läuft eine timingbasierte Spielfeldauswahl ins Leere.
• Annullierungen. Der Betreiber kann ein laufendes Spiel abbrechen (grundsätzlich auch eines, das du gerade gewinnst). Ein Abbruch erstattet den vollen Einsatz zurück (einen Einbehalt gibt es nicht) und löst immer ein öffentliches Event aus, sodass jeder die Häufigkeit von Annullierungen on-chain nachprüfen kann.
• Jedes Spiel muss einen frischen Seed verwenden: Ein aufgedeckter Seed ist öffentlich, und seine Wiederverwendung würde das nächste Spielfeld öffentlich ableitbar machen. Das Programm lehnt eine direkt aufeinanderfolgende Wiederverwendung on-chain ab, und das Backend erzwingt globale Eindeutigkeit.

​

Wie überprüfst du ein Mines-Spiel?

1. Prüfe den Commit: sha256(server_seed) muss dem commit_hash entsprechen, der in der Start-Transaktion deines Spiels veröffentlicht wurde (Event MinesGameStarted) – das beweist, dass das Spielfeld vor deinem ersten Zug festgelegt war.
2. Leite die Minenmaske mit der obigen Formel neu ab und vergleiche sie mit dem mines_mask des Events.
3. Prüfe das Ergebnis anhand der Maske: Jedes Bit von revealed_mask muss ein sicheres Feld sein, und ein Minentreffer muss auf einer Mine liegen.
4. Prüfe den Multiplikator mit der Auszahlungsformel.