Those all don't touch a point that very little people realize.
Provably fair means that you can re-create the seed using known hashes.
You're kind of mixing up terminology here, but you're also on the wrong track. Provably fair means you can prove the game was fair. End of story. If you can't do that, then it's not provably fair.
I could stay here and talk about provably fair all day long, it works, and it stands for something. But the other element that people miss is how a random number is turned into a gambling number. For dice, for roulette, for god knows what kind of gambling system that uses random numbers to generate its bets.
This is all making no sense. Let's use Just-Dice.com provably fair system for reference (mainly just because it's the basically the scheme pretty much everyone uses):
https://just-dice.com/ and click "fair?"
There's no randomness employed. It's all based on cryptographic hashes ( hmac.sha512 ) in particular. The problem with randomness is that you can't prove that it's in fact random. That's why they use the output of a hash function. Although the site probably uses randomness itself to generate the original server seed, but it's irrelevant to the user.
You see, the original number CAN be random, but the way it's converted into a bet would make all the difference, and makes me seriously doubt every gambling website out there.
It's simple :
You generate a true random number using server + client seeds + a nonce that gets incremented. So far so good. But once you do generate the random number, (let's say that has a range of 0 - 1.000.000), instead of having your algorithm use a normal distribution to convert the random number into a percentage, you lie in your odds.
Say every number between 0 and 50.000 will result in a losing bet of 1x, but everything else will increment into a nice exponential looking slope.
This effectively makes the house edge 5%, and goes completely undetected, and unprovable unless you have access to the code that turns a random number into a bet.
This makes absolutely zero sense. If you don't understand how it works, it's best to just ask or take a look instead of coming up with a random guess and then hypothesizing how it's broken. A proper provably fair scheme guarantees an exact house edge, because they encode the way to convert the output of a hash into a game result. From that you can derive an exact house edge.
This is probably very common because rare are the websites that open-source, and fully client-side their bet verifiers. And even then, you'd need someone with knowledge to go into the source code, verify that there isn't a hidden range that benefits the house more than they should.
All decent provably fair sites have fully open source client side verification tools that are hosted externally. For just-dice:
http://rgbkey.github.io/just-dice/http://jsfiddle.net/usrfyxn0/show/https://bitcointalk.org/index.php?topic=586751.msg10190283#msg10190283https://github.com/VolosStorm/JD-Roll-VerifierYou'll notice all of them convert into a roll, thus encode the house edge (1% in this case).