Provably fair Mines : vérifier un résultat

Choisir le bon protocole

Cet exemple concerne le processus Mines documenté par Stake. Ce n’est ni un tutoriel SPRIBE ni une méthode universelle pour tous les Mines.

Stake documente graines serveur et client, nonce identifiant la manche et curseur de génération des octets. Le hash serveur est connu avant de jouer ; la graine apparaît après rotation. Reproduire le résultat exige la graine originale, pas seulement son hash. Implémentation Stake.

Sauvegarder les données au bon moment

Pour une véritable vérification, conservez hash serveur préalable, graine client, nonce, mines et résultat. Après révélation, hachez la graine serveur et comparez avec l’engagement initial. Reproduisez ensuite le résultat avec le protocole de cette version.

Un hash copié seulement après le résultat ne démontre pas, seul, l’engagement pris avant le jeu.

Un exemple synthétique à une mine

Les données suivantes ont été inventées pour expliquer le calcul. Elles ne proviennent ni d’un compte, ni d’une manche jouée, ni d’un audit du service Stake réel.

Le hachage SHA-256 du texte de la graine serveur donne :

afbc5f0cca7198f1b14ca26cf9b6dfcca1f827be1bae43e4f60ab0ca47bee56c

Pour le premier bloc, utilisez HMAC-SHA256 avec la graine serveur comme clé et editorial-example-client:0:0 comme message. Le condensat est :

e52daa798ed2dc8b0f6d7c7beda965baf40fe5435032dba18df23ba17d09c5ed

Les quatre premiers octets sont 229, 45, 170 et 121. La conversion Stake les combine ainsi :

229/256 + 45/256² + 170/256³ + 121/256⁴ = 0,8952280564699322

Cela produit le premier nombre flottant. Conversion octets-vers-flottant de Stake.

Multipliez-le par les 25 positions initiales et prenez la partie entière : floor(0,8952280564699322 × 25) = 22. Avec un index commençant à zéro, de gauche à droite puis de haut en bas, la position 22 correspond à la ligne 5, colonne 3. C’est la mine de cet exemple synthétique. Conversion des événements Mines de Stake.

Des implémentations Python et Node indépendantes ont produit les mêmes hash, condensat, flottant et position. Une seule mine limite l’exemple au premier événement ; plusieurs mines exigent aussi la procédure documentée évitant les doublons.

Comparer au terrain enregistré

Une vraie vérification comparerait la position générée au résultat sauvegardé pour les mêmes graines, nonce et réglages. En cas d’écart, vérifiez d’abord données, encodage, index et version du protocole. Deux captures aux réglages différents ne suffisent pas.

Cet exemple synthétique ne dispose d’aucune manche réelle à comparer. Il démontre un calcul, pas un paiement casino vérifié.

Vérifier n’est pas prédire

Le calcul utilise la graine serveur. La seule graine client et le hash préalable ne fournissent pas cette donnée. Reproduire un résultat après révélation est donc différent d’identifier une case cachée avant la fin de manche.

Mines est-il truqué, fiable ou sûr ?

Ce sont des questions distinctes. Une vérification Mines provably fair peut comparer un résultat à un engagement et une procédure. Elle ne prouve pas, seule, l’absence de biais, le respect des retraits ou l’éligibilité du compte dans une région.

Identifiez le protocole exact et sauvegardez les données requises. Une correspondance de graines concerne ce résultat, pas tous les opérateurs utilisant le nom Mines. Un badge ou une capture inexpliquée ne suffit pas à qualifier un casino de légitime ou frauduleux.

Le répertoire des casinos distingue opérateurs et régions ; le guide d’évaluation des prédicteurs explique la différence entre vérifier un résultat révélé et prédire un résultat caché.