From what I understood its fair only if you reset your client seed after every roll. There were some conspiracies where the webmaster can hash a specific seed knowing your client seed is static and generate a loss in your favor, but it was never proven.
This only works on certain kinds of implementations. A nonce based implementation (just dice, primedice, betking etc), where you have 1 server seed and 1 client seed and a incrementing number, you can make millions of bets before setting a new client seed and still verify all of your bets without the server being able to change the outcome of any of those bets.
Implementations that use a server seed and client seed (fortunejack, rollin, moneypot etc) can theoretically "cheat" you if you play in a predictable manner. For example always use the same client seed and always bet high, the server can pick seeds that are biased towards another direction. Picking a random client seed for every bet prevents this.
I understand what you are getting at, but why does "always bet high" make a difference in the outcome? I assumed the bet amount has nothing to do with the seed hash.
This is kind of where provably fair gets tricky.
The server cannot produce a hash without having picked a server seed. So here's the situation. If you bet predictably as I defined it above, the server can go:
The last 10 bets has been with client seed: 12345abcd
the last 10 bets has been: low
the last 10 bets has been at chance: 49.5%
it's "safe" to assume the next bet will meet these requirements.
1. Pick server seed.
2. Calculate lucky number for server seed using client seed above.
3. is lucky number>49.5
yes -> return hash of server seed
no -> restart from 1.
4. wait for next bet
This anticipates that your next bet will be low at 49.5% chance to win using client seed 12345abcd. If any of these things change, the system fails.
so the hash you see is legitimate, they didn't change anything after you placed to bet to make you lose based on the amount you bet, and you can prove it. BUT they did pick a -probable- result (probable because you're playing predictably) that was biased in a direction.
The same concept can be applied to sites that generate you client seed server side (that kind or ignores the whole concept of a CLIENT seed, doesn't it?) but with one less variable.
the last 10 bets has been: low
the last 10 bets has been at chance: 49.5%
it's "safe" to assume the next bet will meet these requirements.
1. pick server seed.
2. pick client seed (1 and 2 is interchangeable)
3. Calculate lucky number for server seed using client seed above.
4.. is lucky number>49.5
yes -> return hash of server seed and client seed
no -> restart from 2.
4. wait for bet
Of course, this isn't guaranteed to make the site win. If you change from high to low on a whim, you'd win instead of lose.
This approach isn't feasible for any site the uses the nonce based RNG for a few reasons.
1. It takes a LOT more resources (time especially). Causes more suspicion from users when randomizing seed.
2.1 The randomness of the numbers are very good.
2.2 The site has no idea how many rolls you're going to make on the seed. These two points mean that the site might make a seed biased towards low for the first 100 bets (making you lose more than you win) BUT because of the randomness is more biased towards high for the next 1 million rolls, making you win more. This all assumes you use the same client seed between server seeds and play predictably, as defined above.
So my personal tips: Nonce based provably fair: do whatever the fuck you want, just verify your bets after you reset the seed and look for nonce skipping.
single use client+server seed: generate your own random client seed for every bet.
It would be interesting to get a data dump from a few sites like rollin and moneypot and see how many users this could affect and how much of an edge the house could gain by doing this, I personally think not very much.
To Be clear, I'm not accusing any of the above mentioned sites of doing this, I'm merely using examples of where it would be possible to demonstrate why I personally prefer the nonce based RNG systems.