Provably fair, vérifié pas à pas

Ce que « provably fair » promet — et ce qu'il ne promet pas

Nous publions des mesures que le lecteur peut refaire — et « provably fair » est, sur le papier, la mesure la plus refaisable du jeu d'argent en ligne. Le terme désigne une construction cryptographique précise, pas un label de confiance. Elle promet exactement deux choses. Premièrement : le résultat de la manche est déterminé avant que les mises soient placées — l'opérateur s'y engage par avance, publiquement. Deuxièmement : après la manche, l'opérateur révèle les éléments qui permettent à n'importe qui de recalculer ce résultat et de constater qu'il correspond à l'engagement. Si les deux moitiés tiennent, modifier un résultat après avoir vu les mises devient impossible sans casser la fonction de hachage elle-même.

Ce que la construction ne promet pas est tout aussi précis, et c'est là que le discours commercial prend ses aises. Elle ne dit rien du taux de redistribution : une manche peut être parfaitement « prouvable » dans un jeu qui rend 90 % des mises comme dans un jeu qui en rend 99 %. Elle ne dit rien des manches dont les données ne sont pas publiées : la preuve couvre les manches vérifiables, une par une, pas l'historique entier par décret. Elle ne dit rien, enfin, de tout ce qui entoure le jeu : ni les paiements, ni la licence, ni la solvabilité de l'opérateur. « Provably fair » est une propriété d'un calcul, pas un certificat général — et la seule façon de savoir si la propriété tient est de refaire le calcul. C'est ce que fait cette page, sur une manche réelle, avec les chiffres en entier.

L'engagement avant la manche : le hash qui fige le résultat

Le problème à résoudre est simple à énoncer : comment un opérateur peut-il fixer un résultat à l'avance sans que les joueurs puissent le lire avant de miser — et sans pouvoir le changer après avoir vu les mises ? La réponse des jeux crash tient en une chaîne de hachages. Avant la première manche, l'opérateur part d'une valeur secrète et lui applique SHA-256 en boucle, des millions de fois : chaque maillon est le hachage du maillon précédent. Il publie alors le hash du dernier maillon — l'ancre, ou hash terminal — dans un lieu public daté. La chaîne se joue ensuite à rebours : le dernier maillon généré sert à la première manche, l'avant-dernier à la deuxième, et ainsi de suite. Le hash de chaque manche est donc connu de l'opérateur dès le départ — c'est lui qui a construit la chaîne — mais il est illisible pour les joueurs tant qu'il n'est pas révélé, parce que SHA-256 ne s'inverse pas : à partir d'un hash, on ne remonte pas au maillon suivant.

L'ancre publiée joue le rôle du sceau. Quand le hash d'une manche est révélé, chacun peut le hacher à son tour, encore et encore, et vérifier qu'on finit par tomber sur l'ancre publiée des mois ou des années plus tôt. Si l'opérateur avait remplacé un seul résultat en cours de route, le hash de cette manche ne mènerait plus à l'ancre : la chaîne serait rompue, et la rupture serait visible par tous. Reste une objection évidente : et si l'opérateur avait généré des milliers de chaînes et gardé la plus favorable ? C'est pour y répondre que le résultat ne dépend pas du seul hash de la manche. Avant la première manche, l'opérateur annonce un sel tiré d'un événement futur que personne ne peut prédire : le hash d'un bloc Bitcoin pas encore miné, désigné par son numéro. Une fois le bloc miné, son hash — public, inscrit dans la chaîne de blocs — est combiné au hash de chaque manche. Choisir sa chaîne à l'avance ne sert alors à rien : le sel, inconnu au moment du choix, rebat toutes les cartes.

Cette construction n'est pas théorique : c'est celle que bustabit a publiée en janvier 2015 dans son premier « événement d'amorçage » (seeding event) — une chaîne de 10 000 000 de hachages, ancre c1cfa8e2…, sel annoncé : le bloc Bitcoin 339 300. L'opérateur y explique lui-même la particularité des jeux crash : la manche a un seul résultat, partagé par tous les joueurs, donc nul besoin d'un nonce par pari comme dans les jeux de dés — la chaîne et le sel suffisent. La construction tourne encore aujourd'hui : le quatrième événement d'amorçage, en septembre 2025, l'a reconduite sur une chaîne de 100 000 000 de hachages avec un nouveau sel, le bloc 917 000. Les formules de conversion ont été révisées entre les versions ; le principe d'engagement — chaîne construite à l'avance, ancre publiée, sel imprévisible annoncé — n'a pas changé depuis 2015.

Les trois données à exiger avant de vérifier quoi que ce soit

Une vérification n'existe que si l'opérateur remet trois pièces précises. Si l'une manque, il n'y a pas de contrôle possible — il y a seulement une affirmation.

Les systèmes à graines par pari — fréquents sur les jeux de dés et certaines variantes de crash — emballent les mêmes trois pièces autrement : le hash de la graine serveur avant le pari, puis la graine serveur révélée, la graine client et le nonce après. L'emballage change, la logique est identique : un engagement chiffré avant, une révélation après, une formule publique pour passer de l'un à l'autre. Dans les deux familles, la question à poser à n'importe quel jeu qui se dit « provably fair » tient en une phrase : où sont le hash, le sel et l'algorithme ? La manche de la section suivante montre ce que ces trois pièces permettent quand elles sont toutes là.

La vérification, pas à pas : notre manche rejouée

La manche rejouée est la n° 1 135 198 de bustabit, jouée en mars 2015 sous le schéma du premier événement d'amorçage. Son point de crash publié par le jeu est 1,12x — une manche courte, perdante pour qui visait plus haut, et c'est très bien ainsi : une vérification qui ne fonctionnerait que sur les belles manches ne vaudrait rien. L'opérateur lui-même a marché cette vérification en public à l'époque, dans le fil du forum Bitcoin où le schéma avait été annoncé ; nous l'avons refaite de zéro, à partir des enregistrements primaires : l'événement d'amorçage de janvier 2015 pour l'ancre et le sel, le relevé publié des cinq manches consécutives n° 1 135 194 à 1 135 198 pour les hashs et les points publiés, et le registre public de la chaîne de blocs pour le hash du bloc 339 300.

Étape 1 — l'appartenance à la chaîne. Le hash de la manche est 0f81acc25a875c843f3ee3f9563bfa875be311d7585306e743120a4e68f51f0f. Dans le schéma de 2015, chaque maillon est le SHA-256 de la représentation hexadécimale du maillon précédent. On applique donc SHA-256 à ce hash : on obtient 1da773ad50c9f5ce2098713e90bfe667c467fb1e1b14d3623113336899cfff4c — exactement le hash de la manche précédente, la n° 1 135 197. Encore un tour : c0799484…, la n° 1 135 196. Et l'on continue. Au bout de exactement 1 135 198 itérations, on tombe sur c1cfa8e28fc38999eaa888487e443bad50a65e0b710f649affa6718cfbfada4d : le hash terminal publié en janvier 2015, avant que la manche n° 1 135 198 — et toutes celles qui la précèdent — soit jouée. La manche appartient à la chaîne engagée publiquement ; son hash n'a pas pu être fabriqué après coup, car fabriquer un hash qui atterrit sur l'ancre en un nombre exact d'itérations exigerait d'inverser SHA-256.

Étape 2 — le sel. L'événement d'amorçage avait annoncé le bloc Bitcoin 339 300, pas encore miné à l'époque. Son hash, inscrit depuis dans la chaîne de blocs et lisible dans tout explorateur, est 000000000000000007a9a31ff7f07463d91af6b5454241d5faf282e5e0fe1b3a. Nous l'avons relu dans le registre public (mempool.space) le 30 octobre 2026 : c'est bien la valeur annoncée comme sel. Ni l'opérateur ni personne ne connaissait cette valeur quand la chaîne a été construite.

Étape 3 — le recalcul du point de crash. L'algorithme publié combine les deux pièces par HMAC-SHA-256, la clé étant le hash de la manche et le message le sel : le résultat est 1cda7a31c271dd9e8b95798aedb9d6adfd83de975f5edd8315de7675b1cdc9ea. On prend les 13 premiers caractères hexadécimaux — les 52 premiers bits — soit h = 507 594 856 474 397, un tirage uniforme entre 0 et 2⁵². La formule publiée convertit ce tirage en point de crash : plancher de (100 × 2⁵² − h) / (2⁵² − h), divisé par 100. Le calcul donne 1,12. Étape 4 — la règle d'arrêt immédiat. Le schéma de 2015 prévoit qu'une manche dont le hash est divisible par 101 s'arrête à 0,00x : c'est la marge de la maison, prélevée en une manche sur 101 plutôt qu'en continu. Ici, le hash modulo 101 vaut 20 : la règle ne s'applique pas. Étape 5 — la comparaison. Point recalculé : 1,12x. Point publié par le jeu : 1,12x. Correspondance exacte.

Les quatre manches voisines passent le même chemin, et leurs étapes intermédiaires figurent dans le relevé téléchargeable : n° 1 135 197 → 8,66x, n° 1 135 196 → 1,67x, n° 1 135 195 → 3,89x, n° 1 135 194 → 6,34x — publiés et recalculés à l'identique, cinq sur cinq. Le vérificateur ci-dessous refait ces calculs dans votre navigateur, sur ces manches ou sur les valeurs que vous collez — y compris, dans son mode « schéma actuel », les manches récentes de bustabit, dont la chaîne se hache en binaire et dont le sel est le hash du bloc 917 000.

Ce que montre ce rejeu vaut pour n'importe quelle manche de n'importe quel jeu construit ainsi : la vérification ne demande ni compte, ni autorisation, ni outil fourni par l'opérateur — une fonction de hachage et une calculatrice suffisent. Depuis 2015, bustabit a changé deux fois de schéma (la chaîne actuelle se hache en binaire, le sel est le bloc 917 000, la formule de conversion est celle de son vérificateur open source) ; ce qui n'a pas changé, c'est la structure de la preuve : ancre publiée avant, sel imprévisible annoncé, recalcul possible après. C'est cette structure — pas la réputation de l'opérateur — qui rend la manche n° 1 135 198 vérifiable onze ans après.

Ce que la correspondance prouve — et ses limites

La correspondance de la manche n° 1 135 198 établit deux faits, et seulement deux. D'abord, le résultat recalculé est celui que la chaîne publiée en janvier 2015 contenait déjà : pour cette manche, le point de crash était fixé avant les mises, au sens fort — il était mathématiquement enfermé dans une suite de hachages publiée deux mois plus tôt. Ensuite, il n'a pas été retouché : toute modification après coup aurait rompu soit la chaîne (étape 1), soit le recalcul (étapes 3 à 5). C'est exactement la promesse du « provably fair », tenue sur cette manche — et c'est aussi la conséquence qui rend les prédicteurs impossibles : un résultat scellé avant la manche, dans une chaîne que personne ne peut lire à rebours, ne peut pas davantage être prédit que truqué, comme le montre notre page de test des prédicteurs de jeux crash.

Les limites sont du même ordre de précision. La correspondance ne dit rien de la distribution : qu'une manche vérifie ne prouve pas que l'ensemble des manches suit la loi annoncée. Établir cela demande l'historique complet et un test statistique — la probabilité qu'une manche atteigne au moins un multiplicateur m suit, dans le modèle standard des jeux crash, P(manche ≥ ×m) ≈ (1 − e)/m avec e la marge (sur notre modèle de simulation, e = 2 % — un chiffre de simulation, pas une mesure de cet opérateur) ; comparer une distribution observée à cette loi est un autre instrument que le recalcul d'une manche. La correspondance ne couvre pas non plus les manches dont l'opérateur ne publie pas les données : une manche sans hash publié est une manche sans preuve, quelle que soit la qualité des manches voisines. Elle ne dit rien, enfin, de ce qui se joue hors du calcul : dépôts, retraits, licence, support. Une vérification réussie répond à la question « ce résultat a-t-il été changé après les mises ? » — non. Elle ne répond à aucune autre.

Les fausses vérifications : les pages de contrôle qui ne contrôlent rien

Le succès du « provably fair » a produit son imitation : des pages qui en reproduisent le vocabulaire sans en fournir les pièces. Elles se reconnaissent à des signes structurels, lisibles sans aucune compétence technique. Premier signe : la page de « vérification » ne demande ni le hash de la manche ni le sel. Or ce sont les deux entrées du calcul — un contrôle qui ne prend aucune entrée ne contrôle rien ; il affiche. Test simple, à la portée de tous : collez un hash inventé, fait de caractères au hasard. Si la page conclut quand même « manche vérifiée », elle ne vérifie pas les hashs faux ; elle ne vérifie donc pas les vrais non plus. Deuxième signe : la graine n'est jamais révélée. Certaines interfaces montrent des hashs avant les manches — l'engagement — puis ne publient jamais la révélation qui permettrait de l'ouvrir : un engagement qu'on n'ouvre pas n'engage à rien. Troisième signe : le résultat du contrôle est une image, un badge ou une capture d'écran plutôt qu'un calcul refaisable. Une preuve qui ne peut pas être refaite hors du site de l'opérateur, avec des outils indépendants, n'est pas une preuve : c'est une illustration.

Le contraste utile est fourni par l'exemple même de cette page : pour la manche n° 1 135 198, chaque pièce est publique, datée et hébergée aussi hors du site de l'opérateur — l'événement d'amorçage sur un forum tiers, le sel dans la chaîne de blocs, le code du vérificateur dans un dépôt public que chacun peut lire et exécuter chez soi. Un opérateur qui veut être cru n'a pas besoin d'une page de contrôle convaincante ; il a besoin de publier trois données. Quand elles sont là, sa page de contrôle devient presque inutile — le nôtre ci-dessus, ou n'importe quel calculateur de hachage, fait le même travail. Quand elles n'y sont pas, aucune page, aussi soignée soit-elle, ne peut les remplacer.

Quand la vérification est impossible : les jeux qui ne publient rien

Reste le cas le plus fréquent du marché actuel : les jeux crash distribués par les grands agrégateurs et les plateformes généralistes — y compris les titres que nous couvrons au quotidien — ne publient, pour l'immense majorité d'entre eux, aucune des trois données. Pas de hash de manche accessible au joueur, pas de graine révélée, pas d'algorithme de conversion publié. Pour ces jeux, la réponse à la question de cette page est sèche : la vérification est impossible, par quiconque, et elle le restera tant que les données ne sont pas publiées. Ce n'est pas un verdict sur leurs résultats — rien ne permet de dire qu'ils sont faussés, et nous ne le disons pas. C'est un classement : ces jeux appartiennent à la catégorie « invérifiable », où la confiance repose entièrement sur la licence, la réputation et l'historique de paiement de l'opérateur — exactement la situation que le « provably fair » avait été inventé pour dépasser.

Le lecteur peut classer n'importe quel jeu en trois questions, qui sont celles de la section 3 : le jeu publie-t-il le hash de chaque manche ? Révèle-t-il la graine ou le sel après coup ? L'algorithme de conversion est-il public ? Trois oui : vérifiable — faites le contrôle, comme ici. Un non, quel qu'il soit : invérifiable — traitez alors les affirmations d'équité comme ce qu'elles sont, des arguments commerciaux, et dimensionnez votre exposition en conséquence. Entre les deux, il n'existe pas de catégorie intermédiaire où l'on pourrait « plutôt » faire confiance : une preuve cryptographique est binaire, elle se refait ou elle n'existe pas.

Méthode et données : tout refaire chez soi

Comment lire cette page : il s'agit d'une analyse indépendante, publiée à titre d'information. Elle ne recommande ni d'utiliser ni d'éviter aucun jeu ou opérateur, et ne constitue pas un conseil financier. Chaque chiffre est recalculé à partir des enregistrements publics cités ci-dessous ; aucun opérateur n'a relu ni approuvé cette analyse avant publication.

Méthodologie

Rejeu effectué le 30 octobre 2026. Sources primaires uniquement : l'événement d'amorçage publié par bustabit en janvier 2015 (chaîne de 10 000 000 de hachages SHA-256, hash terminal c1cfa8e2…, sel = hash du bloc Bitcoin 339 300 annoncé avant son minage) ; le relevé contemporain des manches n° 1 135 194 à 1 135 198 publié par l'opérateur dans le même forum (hashs, HMAC intermédiaires, points de crash affichés par le jeu) ; le quatrième événement d'amorçage (septembre 2025) et le code source du vérificateur ouvert de l'opérateur pour le schéma actuel ; le registre public de la chaîne de blocs (mempool.space) pour les hashs des blocs 339 300 et 917 000, relus le 30 octobre 2026. Recalculs menés indépendamment par nos soins (Python, bibliothèque standard) : étapes de chaîne entre les cinq manches, HMAC-SHA-256 de chaque manche, conversion en point de crash par la formule publiée, règle de divisibilité par 101, et remontée complète de la chaîne depuis la manche n° 1 135 194 jusqu'au hash terminal — atteinte en exactement 1 135 194 itérations, ce qui fixe les numéros des cinq manches. Le vérificateur intégré à la page exécute le même calcul en JavaScript (SHA-256 et HMAC implémentés dans le fichier /assets/pr3/pr3-verifier.js, lisible par tous) ; ses résultats ont été confrontés, valeur par valeur, à nos recalculs et aux valeurs intermédiaires publiées en 2015. Aucune donnée d'opérateur autre que ses publications n'a été utilisée ; aucune manche n'a été jouée pour cette étude.

Relevé complet des cinq manches : hash, sel, HMAC-SHA-256, valeur intermédiaire h, reste modulo 101, point publié, point recalculé, correspondance et nombre d'itérations jusqu'au hash terminal, au format CSV. Télécharger le CSV

Réutilisation libre dans la presse et la recherche, avec attribution : « Source : Chicken Road Productions, "Provably fair, vérifié pas à pas" — rejeu de la manche bustabit n° 1 135 198 à partir des enregistrements publics de l'opérateur (2026) » — https://chickenroadproductions.com/provably-fair-verifie-pas-a-pas/

Disponibles pour un entretien ou un commentaire sur ces données : contactez la rédaction via la page Presse.

Références

1. Bustabit, « Bustabit.com Provably Fair Seeding Event », Bitcoin Forum (bitcointalk.org), janvier 2015 — l'événement d'amorçage : construction de la chaîne, hash terminal publié, sel du bloc 339 300, code de référence. bitcointalk.org/index.php?topic=922898.0
2. Bustabit (RHavar), vérification détaillée de cinq manches consécutives, fil « bustabit.com — The Social Gambling Game », Bitcoin Forum, mars 2015 — hashs des manches n° 1 135 194 à 1 135 198, étapes de chaîne, HMAC et points de crash publiés par le jeu. bitcointalk.org/index.php?topic=709185.2120
3. Bustabit, « bustabit — Fourth seeding event », Bitcoin Forum, 27 septembre 2025 — retour au schéma classique : chaîne de 100 000 000 de hachages, hash terminal 567a9837…, sel du bloc Bitcoin 917 000. bitcointalk.org/index.php?topic=5560454.0
4. Bustabit, vérificateur open source (code source et constantes des schémas successifs), GitHub — github.com/bustabit/verifier
5. Registre public de la chaîne de blocs Bitcoin, via mempool.space : hash du bloc 339 300 — mempool.space/api/block-height/339300 ; hash du bloc 917 000 — mempool.space/api/block-height/917000 (relus le 30 octobre 2026).
6. NIST, FIPS 180-4, « Secure Hash Standard » (SHA-256), doi:10.6028/NIST.FIPS.180-4 ; Krawczyk, Bellare & Canetti, RFC 2104, « HMAC: Keyed-Hashing for Message Authentication », 1997 — rfc-editor.org/rfc/rfc2104
7. Chicken Road Productions, « Prédicteurs » de jeux crash : nous avons rejoué leurs signaux sur 10 000 manches, 2026 — la conséquence côté prédiction d'un résultat scellé avant la manche.