In advance you get "server_hash" which is a combination of "server_seed + random_seed".
The result is generated by the server_seed and the client_seed (latter is generated in the browser.) You can check that the server_seed was not changed after making the bet, by verifying the hash in combination with the random_seed. They don't know your client_seed in advance so they cannot calculate the end result before you bet. This makes Rollin provably fair. There is no way for Rollin to cheat without you noticing (if you verify the hash.)
Why not just use server_seed without random_seed? I am guessing it is like an extra protection against brute-forcing the server_seed. Originally that comes from systems that don't give a server_seed but a server_roll_number (which would be easily brute-forced without extra random_seed.) But since their server_seed is long enough, I am pretty sure they could remove the random_seed indeed. However, currently the site is just as well provably fair.
Ideally they would use the "nonce-method" too, because in theory for perfect provably-fair-usage, currently you should copy hash, change client_seed, verify, etc after each bet. But technically their implementation is fine for a "per roll" implementation (correctly generates random client_seed in browser, etc.)
I BTW made a verifier for Rollin here: https://dicesites.com/rollin/verifier and an article about provably fair for those who want to learn the basics here: https://dicesites.com/provably-fair
The result is generated by the server_seed and the client_seed (latter is generated in the browser.) You can check that the server_seed was not changed after making the bet, by verifying the hash in combination with the random_seed. They don't know your client_seed in advance so they cannot calculate the end result before you bet. This makes Rollin provably fair. There is no way for Rollin to cheat without you noticing (if you verify the hash.)
Why not just use server_seed without random_seed? I am guessing it is like an extra protection against brute-forcing the server_seed. Originally that comes from systems that don't give a server_seed but a server_roll_number (which would be easily brute-forced without extra random_seed.) But since their server_seed is long enough, I am pretty sure they could remove the random_seed indeed. However, currently the site is just as well provably fair.
Ideally they would use the "nonce-method" too, because in theory for perfect provably-fair-usage, currently you should copy hash, change client_seed, verify, etc after each bet. But technically their implementation is fine for a "per roll" implementation (correctly generates random client_seed in browser, etc.)
I BTW made a verifier for Rollin here: https://dicesites.com/rollin/verifier and an article about provably fair for those who want to learn the basics here: https://dicesites.com/provably-fair
Hello sir,
Very well, after read, you are right and i agree with you, however, let me point it out that since long before the cryptographic hash collisions always exist, sha256 its not exception, making a fast search you can find articles like this about that matter:
http://crypto.stackexchange.com/questions/24732/probability-of-sha256-collisions-for-certain-amount-of-hashed-values
I don't see why the need of the random seed be in their hands until the end of the roll, because with an hash collision the hash can be that one that they show or some other as we can read in the article above . I don't see the need of it and i find it shady stuff (and since when you send the bet request they get your client seed, and then server reply with what ever the output it is, they can do what ever they want to the random seed), however thanks for at last some technical explanation. I'm convinced that if they try to add one extra lets call it " protection " like the random seed is cause they are accustomed to do monkey business and that could be used for protection of the casino but as well for user prejudice.
Regards
its weird did you try to contact the support?
