Quote from: a1choi on June 03, 2015, 03:54:43 PM

Not sure if you're talking about the 2nd method here (nonceless), but i would find this system provably, but not fair. As, it could be possible that the user does not update his client seed while the serverseed will update after every bet. If the operator is unscrupulous, he could take advantage of the users that don't change their client seed as often, and find a serverseed pair that will have an advantage, assuming that the user does not change his betting % or hi/lo option.

of course this would require some work on the operator's part as well as some added technical knowhow, but i could see something like this being done.

Well, the client-seed should be changed each roll to something random either manually (which is crazy tedious) or by a client you trust/verify (ideally a browser plugin, or third-party)

But even with the same client seed it's really not as easy for an operator to cheat, as you'd imagine. That's because the nash for a casino is to not cheat, because if someone knew you were cheating they could do the opposite bet, and *destroy* you. I don't imagine many site operators would be insane enough to cheat this way.

(Although, no sites ever sign an indisputable proof of hashes so any provably fair disputes quickly degrades into a he-said-she-said fight)

So its really just best if the client uses a different random seed each bet to avoid any doubts.

I personally think the simplicity of verification is one of the most important properties of any provably fair scheme. And generally, I think that actually means not using a nonce. I'd rather just audit them by verify a few big bets, than trying to keep a big history history of my bets and follow a convoluted scheme. By far preferable to this, would be userscript that does it for me, in real time.

Even with nonce schemes, which do make it easy to generate a list of bet outcomes (which is of limited use, if you don't keep track of your bet amounts/direction/target) it's amazing how few people actually do verify bets. Some very successful sites have operated for months (accidentally) not being provably fair before anyone even noticed. Or just last week, I spent about ~30 minutes writing a verifier for 64blocks and gave up due to the complexity (e.g. every new game, scrape 64 bitcoin blocks(?!) and verify a complex chain that works both forward and backwards). I have no doubt that's completely fair, with nice properties but when even I, the person who implemented the original scheme it's based on (in bustabit) (which was originally largely Dooglus/Eric's idea) can't be bothered to finish writing the code it's unlikely many people in the world have.

That said, I do think these guys should just go with a nonce scheme unless they're going to build an easy to check browser plugin that set a random client seed, and verifies each bet