Cosa dimostra un hash commitment, e le tre cose che non può dimostrare

Il trucco, in un paragrafo

Un hash crittografico trasforma qualsiasi input in un'impronta digitale a lunghezza fissa con due proprietà che qui contano: non si può risalire dall'impronta all'input, e non si possono trovare due input con la stessa impronta. Quindi se qualcuno ti mostra oggi l'impronta di un segreto e domani il segreto, puoi calcolare l'hash del segreto e verificare che corrisponda. Se corrisponde, il segreto che ti ha mostrato è quello che aveva ieri. Non avrebbe potuto scambiarlo nel frattempo, perché un segreto diverso avrebbe un'impronta diversa, e non avrebbe potuto scegliere il segreto per adattarlo all'impronta, perché ciò significherebbe invertire l'hash.

Questo è uno schema di commitment, ed è tutto il contenuto crittografico del "provably fair". Il banco genera un server seed, ne pubblica l'hash SHA-256, gioca round derivati dal seed, e rivela il seed quando la coppia viene ritirata. Tutto il resto è idraulica.

VERIFICATO DAL MOTORE_shared/seedApi.ts: getRandomKey restituisce {serverSeedHashed, clientSeed, nonce}; renewRandomKey restituisce una nuova coppia insieme a previousServerSeed e previousServerSeedHashed, la rivelazione. _shared/SeedPanel.tsx etichetta il campo "server seed (sha-256 commitment)". _shared/rng.ts: sha256Hex() calcola l'impronta e hmacSha256Utf8() l'hash per round, con il commento che il motore demo "GENERA i risultati con le stesse primitive che il verificatore usa per CONTROLLARLI — un'unica implementazione, così la demo non può mai divergere da ciò che il verificatore accetta".

Tre cose che dimostra

Cosa stabilisce il commitment, e come verificare ciascuna

Tutti e tre i controlli sono locali: richiedono il seed rivelato, il tuo client seed, il nonce e il codice di derivazione, e nulla dal banco al momento del controllo.

La terza affermazione è quella che fa il lavoro per un giocatore, e dipende dal fatto che la derivazione sia pubblica. Un hash del seed non ti dice nulla su come il seed sia diventato un tiro di dadi o una carta. Qui questa funzione viene distribuita nel client, lo stesso codice che la demo usa per generare i risultati e che il verificatore usa per controllarli, quindi un round ricalcolato è una vera ricomputazione piuttosto che una richiesta al server di confermare sé stesso.

VERIFICATO DAL MOTORE_shared/demoLocal.ts: uAt() deriva il numero per ogni round come u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)), descritto come corrispondente a RandomUtils.generateHash sul server; _shared/rng.ts trasforma i primi sette byte dell'HMAC in un numero uniforme in [0, 1) “corrispondente bit per bit all'arrotondamento Long→Double del server”. Il modulo di derivazione di ogni gioco mappa poi quel numero su un lancio, una carta o un moltiplicatore.

Il percorso di verifica esegue tutti e tre i passaggi su un round reale. Se non l'hai mai fatto, fallo una volta; il punto dello schema non è che controlli ogni round, ma che tu potresti controllarne qualsiasi, e la casa non può sapere in anticipo quale.

Tre cose che non può dimostrare

Non può dimostrare che il seed fosse casuale. Un commitment fissa un seed; non dice nulla su come sia stato scelto. Se la casa conosceva il tuo client seed quando ha generato il server seed, potrebbe in linea di principio generare seed finché non ne trova uno i cui primi round le piacciono, e impegnarsi su quello. L'hash risulterebbe perfettamente corretto. La difesa standard è l'ordinamento: il server seed viene impegnato per primo, e il client seed viene impostato successivamente, così che qualunque cosa la casa abbia impegnato, non sapeva con cosa sarebbe stata combinata.

Quell'ordinamento è dove il pannello di questo sito ha un limite che vale la pena dichiarare chiaramente. Impostare un client seed qui non lascia in vigore il server seed attuale; ruota la coppia, e il nuovo server seed viene generato dalla stessa richiesta che porta il tuo nuovo client seed. Dal lato client non è possibile dimostrare che il nuovo seed fosse fissato prima che la richiesta venisse letta. Se il server pre-generi il seed successivo, come fanno alcuni operatori pubblicando in anticipo il prossimo commitment, non è visibile nell'API del client, e non esiste un campo “hash del prossimo server seed” da controllare. Questo è stato segnalato al team del gioco, e la correzione è piccola: impegnare il prossimo server seed prima che venga accettato il client seed a cui sarà abbinato, e mostrare quel commitment nel pannello.

VERIFICATO DAL MOTORE_shared/seedApi.ts: setClientSeed(clientSeed) chiama renewRandomKey con il nuovo client seed e restituisce una coppia fresca a nonce 0; rotate() chiama lo stesso endpoint senza un seed. IHouseSeed contiene serverSeedHashed, clientSeed e nonce, più la coppia precedente in caso di rotazione; nel tipo non è presente alcun commitment per il seed successivo.

Fino ad allora, la versione pratica della difesa è quella che lo schema già fornisce in ogni altro aspetto: la rivelazione. Una casa che macinasse seed contro il tuo client seed dovrebbe comunque rivelare ogni seed alla rotazione, e ogni round sotto di esso può essere ricalcolato. Ciò che il limite significa è che una striscia sospetta nei primi round dopo un cambio di seed non può essere esclusa dal solo hash; può essere solo esaminata, round per round, dopo la rivelazione.

Non può dimostrare che il gioco sia equo nell'altro senso. “Provably fair” significa che la casualità era onesta, non che le probabilità siano pari. Un gioco di dadi può essere perfettamente verificabile e restituire comunque il 99% per design; il margine vive nella tabella dei pagamenti, che è un numero pubblicato e una promessa separata. L'etica del margine della casa riguarda proprio quella promessa. Il commitment tace su di essa.

Non dimostra nulla sui round che nessuno controlla. Lo schema è un deterrente, non una garanzia. Un round che non ricalcoli mai è un round che hai preso per fede, esattamente come faresti ovunque altro; ciò che cambia è che la fiducia è opzionale, e la casa non può sapere quando la eserciterai. È un grande miglioramento rispetto a una macchina mescolatrice di cui non puoi vedere l'interno, e un miglioramento più piccolo di quanto la parola “prova” suggerisca.

L'hash è una ricevuta per la casualità. Non è un certificato per il gioco.la frase da ricordare

Cosa dimostrerebbe di più

• Un prossimo seed pre-impegnato. Pubblicare l'hash del prossimo server seed prima che qualsiasi client seed possa esservi abbinato chiude il divario di ordinamento sopra descritto. È l'unico cambiamento che permetterebbe al pannello di dimostrare che il seed era fissato prima che il tuo input fosse conosciuto.
• Una fonte pubblica di casualità. Mescolare un beacon che nessuno controlla, come la rete drand, elimina del tutto la questione di chi abbia scelto il seed; dentro drand descrive come funziona e cosa costa.
• Una derivazione pubblicata, mantenuta pubblica. Già il caso qui, e la parte più facilmente persa quando un client viene riscritto. Il verificatore è onesto solo quanto il codice che esegue.

Nessuno di questi cambiamenti modifica cosa sia un hash. Cambiano di cosa l'hash è un'impronta digitale, e quando. Lo schema è abbastanza semplice che anche i suoi limiti sono semplici, e un giocatore che conosce le tre cose che dimostra è in una posizione migliore di uno a cui è stato detto che dimostra tutto.

FAQ

Cos'è un commitment hash in un casinò provably fair?

L'impronta digitale SHA-256 del server seed segreto della casa, mostrata prima del gioco e verificata rispetto al seed quando viene rivelato. Dimostra che il seed era fissato prima delle tue scommesse e che il seed rivelato è quello a cui ci si è impegnati.

Un hash corrispondente dimostra che il gioco era equo?

Dimostra che la casualità non è stata alterata dopo il commitment e, con una derivazione pubblicata, che ogni risultato deriva dalla coppia di seed. Non dimostra che il seed sia stato scelto casualmente, e non dice nulla sul margine della casa, che è un numero pubblicato separato.

Il banco può scegliere un server seed che lo favorisca?

Solo se conosce il client seed a cui il server seed verrà abbinato nel momento in cui lo sceglie. La difesa consiste nel committare il server seed prima che il client seed venga impostato. Su questo sito, un cambio di client seed ruota la coppia nella stessa richiesta, quindi questo ordine non può essere confermato dal lato client; l'articolo descrive il limite e la soluzione che è stata proposta.

Come posso verificare un round da solo?

Ruota il seed per rivelare il server seed ritirato, calcolane l'hash per confermare che corrisponda al commitment che ti è stato mostrato, poi ricalcola l'HMAC-SHA256 del server seed sul tuo client seed, il nonce e il cursore, e passa il risultato attraverso la derivazione pubblicata del gioco. Il pannello dei seed esegue il ricalcolo direttamente nel tuo browser.

Perché il codice di derivazione è importante?

Perché l'hash fissa solo il seed. Trasformare il seed in un tiro o in una carta è una funzione, e a meno che questa funzione non sia pubblica, un hash corrispondente non ti dice nulla su se il risultato fosse quello implicato dal seed. Qui il client distribuisce la stessa derivazione che la demo utilizza per generare i risultati.

Il provably fair è meglio di un audit RNG concesso in licenza?

Rispondono a domande diverse. Un audit certifica il comportamento statistico di un generatore su molte estrazioni; un commitment ti permette di verificare uno specifico round a posteriori. Nessuno dei due sostituisce l'altro, e nessuno dei due cambia il vantaggio del banco.

FONTI E RIFERIMENTI

• Wikipedia — Commitment scheme: hiding e binding, e commitment basati su hash
• Wikipedia — HMAC: hashing con chiave e il suo utilizzo come funzione pseudorandom
• Codice sorgente del motore Betkyo: _shared/seedApi.ts (commit, reveal e rotazione), _shared/rng.ts (sha256Hex, hmacSha256Utf8, il valore uniforme a 7 byte), _shared/demoLocal.ts (derivazione uAt), _shared/SeedPanel.tsx

I GIOCHI IN QUESTO ARTICOLODice — regole e gioco gratuito →Limbo — regole e gioco gratuito →