I've been researching the mechanics behind "provably fair" systems used by sites like freebitco.in and duckdice.io. There's no doubt of the validity of the (HMAC + seed + nonce) hashes being verified for consistency. What I could find are many explanations of what 'verified' means, and the mathematics behind conjuring a number between 0 and 10000.

There are many promises made of not tampering with seeds *after* the roll, giving the impression the server commits to a seed before the client submits theirs.

>   When sites only reveal the server seed hash for the next round after the client sends their seed for the current round, the submitted client seed can be used to generate rolls of unfavorable outcome.


Consider the flow of playing a round on freebitco.in:

A player opens the page to play a new round. The server seed hash is presented along with nonce, the user is able to choose their seed if they wish. By default it is left unchanged after being generated.

After choosing the odds/multiplier, player smashes HI or LO to deliver a payload containing their variables: https://static.freebitco.in/cgi-bin/bet.pl?m=hi&client_seed=OneSeedToRuleThemAll&jackpot=0&stake=0.00000001&multiplier=666&rand=0.1234567890987654321&csrf_token=000000

It's at this point, one would assume the server, prior to playing this round, had already prepared the next server-seed it will use for the next roll.

However, between receiving the client seed and sending the results of the current roll; the server has the opportunity to cycle through any number of potential server seeds. Coupled with the client's seed, and the next nonce, the server can pre-compute rolls to select a known outcome for the following roll.

With the result of the current roll being delivered to the user, along with the next server seed hash, giving the illusion of unbiased selection, all the server must do now is to assume the user will stay on the path of least resistance.

>    The end-user has a predictable behavior pattern, and at least in the case of "Provably Fair" gambling, it becomes a vector of potential exploit.

Compared to jamming one of two keys and watching your coins evaporate, there is more resistance in: scrolling back to the top of page, clicking on the "PROVABLY FAIR" link to open the dialoge, type in a bunch of nonsense into the text area for the next client seed, close the dialoge, and replay.

None of this means that servers are scamming users. But it does give an invite to any nefarious practice which could fly under the radar: deny big wins only allowing small amounts, to force a loss on a large wager, or to break a new world-record losing streak.

>    And they could do it while still providing a "Verified Hash" after every roll.

Because hash verification only proves the server didn’t change the seed after generating the result. It can't validate the conditions of the seed's generation, and says nothing about why or how they picked that seed in the first place.

The "provably fair" model only floats if:

1. The server commits to its n+1 seed before knowing the client's.
  - Can prove having generated the seed for the game following the current roll, before seeing the client seed.

2. Users routinely rotates their client seed; no less than after every single roll.

If a "provably fair" system doesn't include any sequencing or legitimate proof of seed commitment, then it’s not provable. It’s just branding.

Thanks for reading!