Comment le crash de BC.Game est vérifié : chaîne de hash, sel et formule
Le crash de BC.Game est un des rares jeux où chaque partie est fixée avant que quiconque mise, et BC.Game publie assez d'information pour que vous puissiez le vérifier. Ce guide passe en revue ce que dit la documentation de BC.Game elle-même : la chaîne de hash, le sel, la formule qui transforme un hash en multiplicateur, et comment vérifier des parties vous-même avec notre vérification de chaîne de hash et le propre vérificateur de BC.Game.
Ce que BC.Game publie sur le crash
BC.Game explique l'équité du crash dans son centre d'aide, dans l'article « Crash: ensuring fair play », et sur sa page provably fair. Il renvoie aussi à un script de vérification hébergé sur GitHub sous le compte bc-game-project, et a annoncé un changement à l'algorithme du crash dans un message publié sur Bitcointalk en 2020. Tout ce qui suit vient de ces pages. Quand elles divergent ou laissent un trou, nous le disons.
La chaîne de hash
Selon le centre d'aide de BC.Game, la plateforme a généré 10 millions de hash au total avant le lancement du jeu. Chaque hash est le SHA-256 de celui créé avant lui, ce qui forme une chaîne.
La chaîne est utilisée à l'envers :
- BC.Game crée la chaîne à partir d'une valeur de départ secrète en la hachant encore et encore avec SHA-256.
- Le dernier hash créé sert à la première partie, celui d'avant à la deuxième, et ainsi de suite.
- À la fin d'une partie, son hash est affiché dans l'historique du jeu.
- Hacher une fois le hash de cette partie donne le hash de la partie précédente.
Comme SHA-256 ne fonctionne que dans un sens, personne ne peut déduire le hash de la prochaine partie à partir de l'actuelle. Mais n'importe qui peut remonter la chaîne et confirmer que le hash de chaque partie mène à celui de la partie précédente. Si chaque maillon tient, les parties viennent d'une chaîne qui existait avant les mises, et BC.Game n'a pas pu changer un résultat après avoir vu les mises.
Le sel
Une chaîne de hash seule a une faiblesse : c'est le casino qui la génère, donc en théorie il pourrait créer plusieurs chaînes et garder la plus avantageuse. Un sel règle ce problème en ajoutant une valeur que personne ne connaissait quand la chaîne a été créée.
La page de vérification de BC.Game sur GitHub indique que le crash a été modifié pour utiliser un hash salé à la demande des joueurs, à partir de la mise numéro 2 561 902, et renvoie à l'annonce de BC.Game sur Bitcointalk de juin 2020. Dans ce message, BC.Game explique que chaque hash de partie est combiné par HMAC-SHA256 avec un sel : le hash d'un bloc Bitcoin choisi d'avance, le bloc 635 380, qui n'avait pas encore été miné au moment de l'annonce. C'est pour ça que le vérificateur sur GitHub a un champ séparé pour le sel.
L'article du centre d'aide ne mentionne pas le sel. Son exemple applique la formule directement au hash de la partie. Nous n'avons pas pu confirmer, à partir des pages d'aide actuelles de BC.Game, si le sel a changé depuis 2020; utilisez donc le sel indiqué dans le propre vérificateur ou le panneau d'équité de BC.Game quand vous vérifiez un multiplicateur.
Du hash au multiplicateur
Le centre d'aide de BC.Game donne la conversion étape par étape :
- Prenez les 13 premiers caractères hexadécimaux du hash. Ça fait 52 bits.
- Divisez ce nombre par 2^52 pour obtenir un nombre X entre 0 et 1.
- Calculez 99 divisé par (1 moins X). Le 99 au lieu de 100 correspond à l'avantage de la maison de 1 %.
- Si le résultat est inférieur à 100, ramenez-le à 100.
- Arrondissez vers le bas et divisez par 100. Vous obtenez le multiplicateur de crash.
Avec la version salée annoncée sur Bitcointalk, les 13 caractères sont tirés du HMAC-SHA256 du hash de la partie avec le sel, et non du hash de la partie lui-même. Le calcul qui suit est le même.
Le centre d'aide donne un exemple : un hash qui commence par 6b5124897c3c4 donne un X d'environ 0,4192, puis 99 divisé par 0,5808 donne environ 170,46, arrondi vers le bas à 170, ce qui fait un crash à 1,70x.
Ce que la formule veut dire pour vos chances
Comme X est réparti uniformément entre 0 et 1, la formule donne des probabilités claires :
- Crash instantané à 1,00x. Ça arrive quand X est sous 0,01, donc dans environ 1 % des parties.
- Atteindre un multiplicateur M. La probabilité qu'une partie atteigne M ou plus est d'environ 99 % divisé par M.
| Encaisser à | Probabilité que la partie y arrive |
|---|---|
| 1,5x | environ 66 % |
| 2x | environ 49,5 % |
| 3x | environ 33 % |
| 10x | environ 9,9 % |
| 100x | environ 0,99 % |
Peu importe la cible choisie, le rendement attendu est d'environ 99 % de ce que vous misez. Aucun réglage d'encaissement automatique ne change ça. Les parties passées n'aident pas non plus : chaque hash est en pratique aléatoire, donc une série de crashs bas ne dit rien sur la prochaine partie. Notre guide sur les crash predictors explique pourquoi les applis qui prétendent prédire la prochaine partie ne peuvent pas fonctionner.
Vérifier des parties avec notre vérification de chaîne de hash
Cette étape confirme que les parties viennent d'une seule chaîne engagée d'avance :
- Dans le crash de BC.Game, ouvrez l'historique des parties et copiez les hash de deux parties consécutives ou plus.
- Ouvrez notre vérification de chaîne de hash.
- Collez les hash un par ligne, dans le même ordre que l'historique. Du plus récent au plus ancien ou l'inverse, les deux fonctionnent, tant qu'aucune partie n'est sautée.
- Lancez la vérification. Hacher une fois le hash d'une partie plus récente doit donner le hash de la partie d'avant.
Si chaque maillon concorde, ces parties étaient fixées avant le jeu. Si un maillon ne concorde pas, assurez-vous d'abord d'avoir copié les parties dans l'ordre, sans en oublier. Une vraie rupture entre des parties consécutives serait une constatation grave.
Vérifier le multiplicateur avec le vérificateur de BC.Game
Notre vérification de chaîne prouve que les parties sont liées. Pour confirmer le multiplicateur d'une partie donnée, utilisez le propre script de vérification de BC.Game :
- Collez le hash de la partie.
- Entrez le sel.
- Indiquez le nombre de parties à calculer à partir de ce hash.
- Comparez chaque valeur de crash avec les multiplicateurs de l'historique de BC.Game.
Si les valeurs de crash correspondent à l'historique et que les maillons de la chaîne tiennent, la partie était à la fois fixée d'avance et calculée avec la formule publiée.
Ce que ça prouve et ne prouve pas
- Ça prouve que le résultat était fixé avant les mises. Ni BC.Game ni un joueur ne pouvait changer une partie après son début.
- Ça n'élimine pas l'avantage de la maison. Environ 1 % de tout ce qui est misé revient à la maison à la longue.
- Ça couvre seulement le crash. Les autres originaux de BC.Game, comme le dice, utilisent plutôt un server seed, un client seed et un nonce; vérifiez-les dans notre vérificateur en choisissant BC.Game.
- Ça ne dit rien sur les retraits. Voyez notre audit de BC.Game pour la licence et notre test de retrait.
Sources
Conditions clés
- Jeu crash
- Jeu par manches avec un multiplicateur qui monte à partir de 1x jusqu'au crash; vous ne gagnez que si vous encaissez avant.
- Provably fair
- Une méthode cryptographique qui vous permet de confirmer qu'un résultat de jeu a été fixé avant votre pari et n'a pas été modifié ensuite.
- SHA-256
- Un hash cryptographique qui transforme n'importe quelle entrée en un condensé fixe de 256 bits; les casinos l'utilisent pour s'engager sur les seeds serveur.
- HMAC
- Une fonction de hachage qui utilise une clé secrète; les jeux provably fair appliquent HMAC-SHA256 à la seed serveur, à la seed client et au nonce.
- Avantage de la maison
- Le pourcentage moyen de chaque mise qu'un jeu est conçu pour conserver au profit du casino.
- Target multiplier
- The multiplier a player chooses in limbo or auto cash-out crash; the bet wins if the result reaches it.