The problem with online dice
In over-the-board play you shake the cup yourself. Online, some computer produces the rolls — and you're asked to simply trust that it doesn't favor the house, the stronger player, or whoever pays. A promise is not something you can check. A commitment is.
How commit-reveal works
The server commits — before every roll
For each roll, the server draws a fresh secret random seed for that roll alone and publishes only its cryptographic hash (thecommitment). A hash works one way: it fixes the seed at that moment while revealing nothing about it. From then on the server cannot swap the seed — the published hash would stop matching.
A second number is mixed in
When you roll in a live game, your app draws a random number of its own and sends it to the server. The dice are computed from both numbers with HMAC, a keyed hash, together with the game's ID, the roll's ID and a counter. Nothing about the position, the score or the players goes into the calculation. Your opponent never generates dice, and neither do you: the server computes every roll, and it will not start a new roll until the one on the board has been played.
When the server makes a roll with no player's device involved — in a correspondence game, for example — it supplies the second number as well.
The seed is revealed with the roll
The server shows the secret seed together with the dice. Now the roll is checkable: hash the seed and it must equal the commitment made before the roll; recompute the HMAC and it must reproduce exactly the dice you saw.
Anyone can verify
The Boardgammon app runs this check on every roll you make. You need not take the app's word for it: every online match you play has a public audit page —
api.boardgammon.com/audit/<game-id>— with each roll's commitment, revealed seed and dice, and a short program you can run yourself, so any player, spectator, or third-party script can redo the math independently.
What this gives you
- No roll can be changed after the fact. Once a roll is revealed, its record fixes it: dice that do not follow from the numbers in the record fail the check.
- No re-rolling for a better number. Each roll is committed once, computed once, and has to be played before the next one starts.
- Nothing about you goes in. The calculation takes two random numbers and the labels of the game and the roll. Your rating, your position, and whether you pay are not inputs.
- Fair dice make ratings and analysis meaningful. Rated ladders,PR scores, and per-game luck figures are only worth something on dice you can check. (Yes — the analysis will show you exactly how lucky your opponent got. With numbers.)
- Server-authoritative play closes the other door. The server also validates every move against the rules, so a modified client can neither conjure rolls nor sneak illegal plays.
What the record shows, and what it does not
A roll's record shows that the revealed seed matches its commitment, and that the dice follow from the numbers in the record. For a roll you make, your app was given the commitment before the roll, so it can also tell that the seed was fixed first. When the server supplies the second number too, the record still shows that the roll was not changed after it was recorded; it cannot show that the server did not know, or choose, the roll in advance. We would rather say that plainly than claim more than the record proves.
The whole protocol in one breath
Hash before each roll (the promise) →a second number mixed in (from your device, in a live game) →seed revealed with the roll (the receipt) →public audit page (the check anyone can run). That's what “provably fair” means here — not a slogan, a checkable claim.