What a hash commitment proves, and the three things it cannot

The trick, in one paragraph

A cryptographic hash turns any input into a fixed-length fingerprint with two properties that matter here: you cannot work backwards from the fingerprint to the input, and you cannot find two inputs with the same fingerprint. So if someone shows you the fingerprint of a secret today and the secret tomorrow, you can hash the secret and check that it matches. If it does, the secret they showed you is the one they had yesterday. They could not have swapped it in between, because a different secret would have a different fingerprint, and they could not have chosen the secret to fit the fingerprint, because that would mean reversing the hash.

That is a commitment scheme, and it is the whole cryptographic content of “provably fair”. The house generates a server seed, publishes its SHA-256 hash, plays rounds derived from the seed, and reveals the seed when the pair is retired. Everything else is plumbing.

Three things it proves

All three checks are local: they need the revealed seed, your client seed, the nonce and the derivation code, and nothing from the house at check time.

The third claim is the one that does the work for a player, and it depends on the derivation being public. A hash of the seed tells you nothing about how the seed became a dice roll or a card. Here that function ships in the client, the same code the demo uses to generate results and the verifier uses to check them, so a recomputed round is a real recomputation rather than a request to the server to confirm itself.

The verification walkthrough does all three steps on a real round. If you have never done it, do it once; the point of the scheme is not that you check every round but that you could check any of them, and the house cannot tell in advance which.

Three things it cannot prove

It cannot prove the seed was random. A commitment pins a seed down; it says nothing about how the seed was chosen. If the house knew your client seed when it generated the server seed, it could in principle generate seeds until it found one whose first rounds it liked, and commit to that one. The hash would check out perfectly. The standard defence is ordering: the server seed is committed first, and the client seed is set afterwards, so that whatever the house committed to, it did not know what it would be combined with.

That ordering is where this site’s panel has a boundary worth stating plainly. Setting a client seed here does not leave the current server seed in place; it rotates the pair, and the new server seed is generated by the same request that carries your new client seed. From the client it is not possible to show that the new seed was fixed before the request was read. Whether the server pre-generates the next seed, as some operators do by publishing the next commitment in advance, is not visible in the client’s API, and there is no “next server seed hash” field to check against. This has been raised with the game team, and the fix is a small one: commit the next server seed before the client seed that will be paired with it is accepted, and show that commitment in the panel.

Until then, the practical version of the defence is the one the scheme already gives you in every other respect: the reveal. A house grinding seeds against your client seed would still have to reveal each seed at rotation, and every round under it can be recomputed. What the boundary means is that a suspicious streak in the first rounds after a seed change cannot be ruled out by the hash alone; it can only be examined, round by round, after the reveal.

It cannot prove the game is fair in the other sense. “Provably fair” means the randomness was honest, not that the odds are even. A dice game can be perfectly verifiable and still return 99% by design; the edge lives in the payout table, which is a published number and a separate promise. The ethics of the house edge is about that promise. The commitment is silent on it.

It proves nothing about rounds nobody checks. The scheme is a deterrent, not a guarantee. A round you never recompute is a round you have taken on trust, exactly as you would anywhere else; what changes is that the trust is optional, and the house cannot know when you will exercise it. That is a large improvement on a shuffling machine you cannot see inside, and a smaller one than the word “proof” suggests.

The hash is a receipt for the randomness. It is not a certificate for the game.the sentence to remember

What would prove more

• A pre-committed next seed. Publishing the hash of the next server seed before any client seed can be paired with it closes the ordering gap above. It is the single change that would let the panel prove the seed was fixed before your input was known.
• A public source of randomness. Mixing in a beacon that nobody controls, such as the drand network, removes the question of who chose the seed altogether; inside drand describes how that works and what it costs.
• A published derivation, kept public. Already the case here, and the part most easily lost when a client is rewritten. The verifier is only as honest as the code it runs.

None of these changes what a hash is. They change what the hash is a fingerprint of, and when. The scheme is simple enough that its limits are simple too, and a player who knows the three things it proves is in a better position than one who has been told it proves everything.