Bitcoin Forum

Basically, the issue is that many casinos provide a new server hash for each bet. (Which means AFTER the client seed is provided unless you change it before every bet, because otherwise they will know your seed from last bet).

This system of one server seed for each rolls allows each bet to be "verified" immediately after each bet, but it's bad because it is meaningless if the client seed isn't also changed afterward before the roll. Those system designs probably result from wanting to provide instant bet verification and poor understanding of what makes something provably fair. Verification is actually harder to do and more tedious, because it is only provably fair if the player changes seed before each roll. If you're labeled as provably fair, that's what you should be getting by default. Not something optional that isn't explained to you.

Here's a simplified explanation of cheating that could be done through such a system by a nefarious casino operator:


The point is, every player could verify all their bets, it wouldn't catch this kind of cheating.

Many dice games/casinos use such a flawed system. There should never be any scenario where server seed are generated after the client seed as it allows the casino to do selective seeding! If a player can play that way, the system is flawed, because it's possible to make a provably fair system where the player is always covered. Players don't need to choose between provably fair or spamming bets.

Just-Dice was a very good example of a correct implementation. You still had to change your client seed after receiving the server seed, but server seed stays the same, until you request it to be revealed to verify bets. At will verification, but you must not forget to then change your client seed. Get new server seed, THEN add your seed, then good to go to spam bets.

Coinroll is another good example, where a daily predisclosed secret is used for everyone. This make changing it after the fact very hard as it would impact all rolls for the day, plus the hash is provided upfront making it pretty much impossible to find another secret which matches the hash. Verification is delayed slightly but we believe this is the best method currently available. We also don't provide a default client seed. We use the client's last deposit tx, which means we don't even have the possibility to choose a default client secret that would be advantageous for the current daily secret. The only way Coinroll could cheat would be by providing rolls that don't match seeds. It makes it hard to cheat as this would be easily noticeable that some bets results are not right. Even if a casino did it for only 1% of players/bets, it would only need a few people tracking bets to start noticing. We also provide archives of all betting on Coinroll for public auditing.

A well designed provably fair system is supposed to make it possible and easy to spot fraud by the operator. A system where the player can either choose to be covered with tedious manual work (changing seed before each bet) OR bet at will without being able to check if bets are actually provably fair is not needed and pointless when players could be covered at all time with a system like Coinroll's or Just-Dice's.

Regards from Coinroll's staff

Please add your input to this thread to let casino operators know of your support for all crypto gambling venues to update their provably fair system and be bound to higher transparency standards. I would also recommend gambling list creators start demanding systems similar to Just-Dice's or Coinroll's for being listed as provably fair.

I agree that the "provable fairness" offered by services which change the server seed for every bet is very hard to take advantage of as a player.

If I play at PrimeDice, Bitzino, prcdice, and probably many more, for every roll I make I have to:

1) make a note of the server seed hash for this roll
2) pick a client seed in an unpredictable fashion
3) make the bet, noting the number they rolled
4) verify that the hash of the published server seed matches the one in step 1
5) verify that the published server seed combined with my chosen client seed gives the roll I saw in step 3

That's a LOT of work. Almost nobody is going to bother doing it, and so for all practical intents and purposes the site isn't provably fair for the majority of people.

Compare the above 5 steps *per roll* to what a player at Just-Dice or CoinRoll would have to do per roll:

3) make the bet, noting the number they rolled

That's right - they can just spam their bets, keeping a record of the rolled numbers.

That is because the bulk of the work required to verify PrimeDice rolls has been moved to the very start and very end of play, not per roll.

At Just-Dice, steps 1 and 2 are done before you start play, and steps 4 and 5 are done after you finish a session. You verify all your rolled numbers in bulk, using a single pair of seeds.

At CoinRoll, step 1 is the same for every player (the site has a global server seed per day), step 2 uses your most recent deposit's txid (obviously out of the site's control (unless they use transaction maleability, I guess?)), and steps 4 and 5 can only happen at the end of the 24 hour period.

I think JD's system is better than CoinRoll's, since it puts control entirely in the hands of the player. He gets to reveal his server seed whenever he wants to and doesn't have to wait until midnight. But both systems are vastly better for the player than having to do all that tedious work for every bet you want to make.

By the way, if this step involves clicking a button that in turn calls javascript Math.random() function then that's no good, too. It can end up badly like brainwallet (http://mineforeman.com/2014/06/27/brainwallet-org-exploited-and-bitcoins-stolen/).

The argument I'd make is that this longer process allows for real time verification, which I find preferable.  People are either going to take advantage of provably fair functionality or they're not, and most of them are not.  Those who are taking advantage are either going to only make a few rolls and be done, so it hardly matters if there's a few extra steps involved, and I'd argue that it's unlikely they would return to see the server secret after 24 hours anyway, or they're going to automate the process, so again it doesn't matter if the process is longer or not.

The major problem I have with a daily secret type setup is that it exposes the site operator to risk should that list ever get out.  I agree that JD's system is a decent compromise, as at least bets can be verified every 10 rolls or so as opposed to every 24 hours.

The thing is those that want to use provably fair will not want to do the work for every single bet. They'll want to do it in batch. So why are players not simply covered at all time by a provably fair system? It's deceptive because a bet that might just not be provably fair will still show the same "provably fair" checking instructions, but not all bets will be provably fair, only those where the client seed was provided AFTER the server seed (which usually means not a lot of them). Easy for a casino operator to abuse by doing selective seeding, yet all bets would show roll as "correct" under that system, even if cheating was going on. That's why as far as I'm concerned, any system where server seed can be provided after a client seed is retarded.

It shouldn't involve extra work on every single bet. There is alternatives. Every player can be covered at all time. They can then later verify any bet at any time, easily, should they wish to do so. They can also run checks in batch on large samples. Someone could audit everyone's bets. You can verify after the fact if you got the right roll, even if you didn't take any step to get provably fair. If you're labeled as provably fair, that's what you should be getting by default. Not something optional that isn't explained to you.

(I think I'm going to use those two last lines for my main post.)

Any site that provides the secret hash after you've input your client seed does not meet the commonly accepted definition of provably fair.  Just to satisfy my curiosity, what sites do you have in mind that do this?  Feel free to answer in a pm if you don't want to disparage other casinos.

Personally, I seriously doubt that a casino would be able to exploit vulnerabilities in a properly implemented provably fair solution.  I think it's likely that the majority of people don't understand the system or how it works beyond maybe the basic knowledge that you should pick a complex seed derived from a high-entropy source, but I also think it doesn't matter so much.  The minority of people who do understand and are checking will notice exploitation and either report it to the community or exploit it themselves if they're able.  Either way, a cheating casino loses.

I think the bigger danger besides how the server seed is produced is a faulty implementation.  Take a look at the following verification javascript from a particularly infamous bitcoin casino:


This particular game gives you a server seed hash, and when you place your bet, you provide a client seed.  After the bet, you are provided with the server seed.  That seems to be following the rules so far.  The problem here is that, like Bitzino, there is a third variable, the initial shuffle.  The initial shuffle is only disclosed upon looking up your betting history.  Obviously the server could change the initial shuffle in a favorable way in this system, and truly cheat the player in a completely undetectable way.  This is solely a problem with a faulty implementation.  I don't know that this casino is actually engaged in any kind of wrong doing, but the opportunity certainly exists.  An interesting thing about this case is that the server secret is actually exposed before a second round of betting.  This leads me to the conclusion that they are deliberately not exposing the initial shuffle, which seems fairly suspicious.  They could actually expose the server secret before the initial bet and without that initial shuffle, it still would not be exploitable.

Edit: I reread the parent post, and I understand your point.  You adequately countered nearly everything I've said.  I don't believe you're correct in that a per bet server seed can't be made provably fair, however.  This is again an issue of proper implementation.  See Bitzino's solution:


It uses a cryptographically secure function, picks a new seed for every bet, and doesn't communicate that seed to the server before the bet is placed.  This could certainly be countered by overwriting this function with a predictable seed generator, but that's easily detected.

I'm not saying that a semi-permanent server seed is a better or worse than a per bet server seed.  I think they both have strengths and weaknesses, but it is very possible to make both approaches work in a fair manner.

Actually, isn't it kind of the same thing? If the user didn't verify the file he was served that generates random seeds, he can't go back after the fact to verify. But it would be a big improvement. Many casinos don't even have javascript that automatically generates a client seed. Such that server seed will change, but not client seed, unless done manually be the user.

A 24h global secret can be remembered by many and the last deposit tx ID as client seed makes it easy for anyone, even if they did no checks before starting to bet, to go back and check them. It also makes it easy for 3rd party to audit.

You mean there's places that have an undisclosed variable in the calculation, no hash of it, that is only revealed after the bet? That defeats the purpose now, doesn't it... It's as good as no system.

I'll be blunt here, you can't fix stupid.  There's a very good reason why provably fair only exists in the bitcoin gambling world.  Everyone else uses ISO 9001 certification of their games coupled with local regulations.  It's a lot simpler for some authority to say that the games are doing what they're supposed to do than to have to audit it yourself.  If you look at Las Vegas in particular, the NGC does an excellent job at keeping casinos honest.  The provably fair system was created because that certification is expensive, no one would probably have wanted to certify a bitcoin casino at the time, and we all hate centralized authority.  Bitcoin at its core is the epitome of libertarian ideals like self reliance.  Some smart people created this system and explained in technical and layman's terms how to use it.  A lot of other smart people have verified that this system works, when used properly.  People need to change their seeds when they bet, that's a part of the system.  In fact, if I'm remembering correctly, after JD switched to its currently system, I complained because I couldn't change my seed every bet.  It was still provably fair, and I could in fact arbitrarily change my nonce, but not being able to change my seed simply felt wrong.

I want to clarify, from the casino operator's point of view, I can think of many ways to exploit a per bet server seed type system.  I can think of fewer ways to exploit the system coinroll uses, but not zero.  From a player's point of view, I can counter all of those.  A player simply has to pick a good, unpredictable seed, and anything a casino operator is trying to pull in regards to its provably fair system collapses.


That's precisely my point, this is a real problem, a site with a system that presents itself as provably fair when it truly is not.  People not using a provably fair system correctly and exposing themselves to possible cheating is much less of a problem.  One of these issues is systemic, while the other is due to incompetence on the part of the player.  That is the key issue.

No, the point is that some players rely on others/trust what they're told. Which means that provably fair system that relies on the user to change his seed for every bet is bad. It leaves many bets not covered at all, that could be cheated in a way impossible to detect after the fact. Once it's done, you can never come back and verify if the bet was provably fair. Why should it be a convoluted, per bet, manual step to turn each bet into provably fair, when they could all be covered by default?

This explains it then... now I know why I have more statistically accurate rolls on just-dice and coinroll than I do on other sites.
To bad Prime has the best sig rate, or else I'd be promoting CR or JD

As has been seen many times on these forums, bad actors are routed out.  People really don't have to understand the intricacies of why it's fair, so long as experts agree that it is fair.  I've personally weighed in on the PrimeDice issue.  It is open to exploitation.  As a part of that thread I posted some simple javascript that corrects that vulnerability.  People need to hold themselves accountable for everything they do.  People should research, ask questions, and listen to the community.  The community in general doesn't want to see people cheated, and we make efforts to prevent it.  Scam casinos get called out regularly, you can look at my post history for examples.  Still, at the end of the day, everyone is responsible for their own actions, and if that includes losing money due to a lack of due diligence, then they should own that and learn from it.

It is simply not valid to claim that per bet server seeds are intrinsically worse than site wide server seeds.  I will concede that more avenues exist to exploit a per bet server seed system, but only in a flawed implementation.  Site wide server seeds are plain harder to screw up.  A provably fair set up includes a server seed hash and initial shuffle if required, and unobfuscated client side code for determining a client seed.  This set up is no better or worse than coinroll's, other than the perk of being able to verify outcomes in real time.  Similarly, you could argue that the perk of your system is that the player doesn't have to change his client seed.  Additionally, there is no merit in claiming that per bet server seed processes are convoluted.  While that may be true on a per site basis, Bitzino, whom I consider the de facto standard on provably fair systems, has created a decidedly fair and simple system.  BitcoinVideoCasino is a similarly excellent example.

We used to allow players to 'randomize' any time they wanted to, but we had one player who did it after every roll. This was causing us to have to store huge numbers of pairs of seeds in the database.

I thought it was an attempt at some kind of denial of service, and so just put a limit on it - "you can only randomize after you've used a seed-pair 10 times".

But now it has dawned on me - it was you, with an automated roll verifier!

Am I right?

After a while of fighting against DDoS attacks, everything starts to look like an attack, even innocent things. :)

I doubt Prime cheats at all. Coinroll might start advertising again soon, depends on what the new owners want to do.

----
@cwil

I agree if there's an automated system that changes client seed reliably. I'm saying it's convoluted for those that don't because they'll say all their bets are provably fair, they'll show how to verify bets, etc, with no mention that it's the case only if the user changes his client seed. It's simply not accurate if they don't have a system in place that make sure client seed is provided after server seed.

That seems likely :)

Edit: There was a name change bot and some complaints about the lack of UTF-8 characters at some point too, though it seems UTF-8 support was eventually implemented.

What's that? This is news to me.

Do you mean by making 0 BTC bets to increment the nonce?

Or something cleverer I don't know about?

Nope, I could just change the nonce to whatever.  Search your DB for any bets with a negative nonce, I bet you'll find a couple.

actually there are two problems in this field
1: mentioned by Namworld
 (I wonder if some would even cheat on user by grabbing the client seed and change the server seed if the server seed is not requested by the user)
2: Too many people PR on their Provable results to provably fair


PhonyDice should be a better name for PD....

Shameless ad:I'd better stay in Dicenow and leverage invest the house to riches

That sounds dangerous.

Couldn't you set it back to 1 and re-roll the same numbers you've already seen?

It's going to take a long time to query the DB since there's no index on the nonce column.  I'll let you know the results.

Well, I did tell you after months of trying, I was never able to find an exploit in your game.  It would not let you bet with an already used nonce.  This was pre 145,000,000 bets if I remember correctly, that may help.

The query finished:

mysql> select * from bets where nonce < 0;
Empty set (48 min 7.76 sec)

So I'm not sure what's going on. Are you thinking of a different site maybe?

Edit: there's code that sets the nonce to 0, and code that increments it atomically; there's nothing that sets it to any other value, so I can't see how it could ever go negative.

It's possible I am, this was around a year ago.

@dooglus/cwil : The only possible reason would be that you have an overflow, but that seems highly unlikely, as you're probably using an unsigned long or something similar for the nonces.


As for how we manage Provably Fairness on SatoshiCarnival:

• We have a Server Seed that a player can refresh at will, but otherwise will stay the same (with a limit of 24 hours, or three times a Player Seed change).
• Then we have a Player Seed, which players can change at will, to ensure that we cannot control the outcome.
• And finally we have of course a nonce, so a Server/Player seed combination can be used in multiple bets without repeating results.

For a player to check if a bet is provably fair, he just need to keep track of the value of the current nonce.
He can afterwards click on each bet to display the bet details and fairness, which visually displays the steps done in the back-end to calculate the resulting number.
When players refresh their Server Seed, the old one becomes publicly known, and it's possible for players to calculate the hash of the Server Seed / Player Seed / Nonce themselves to know that indeed, this was the result of the bet.


The mayor differences between our way and the way many other bitcoin casinos do it:

• In many casinos, players need to wait until the end of the hour or day before the Server Seed is uncovered.
• On SatoshiCarnival, it's possible to check the fairness of ANY bet from ANY player, this we do to show that colluding with players is unnatractive for the staff. (Bankrollers will notice it and complain.
• On SatoshiCarnival, we try our very best to show the procedure of proving fairness in a way that it's the easiest for players to understand, grasp and calculate even if they did not have experience with such systems or cryptography in general before.

Thank you for hearing me out. In my personal opinion, it would be great if other casino's would start using this way of Fairness. I totally agree with the Original Poster that many systems out there are very time-consuming and/or clunky, and in any case not player-friendly.
Let's change that!

Have a nice day,

~W-M

It must be another site I'm thinking of then.  It's funny though, after fairly conclusive proof to the contrary, I still remember it being jd.  At least we know the most bets with a single seed now.

Their game works differently I'm sure
Like I said I have more statistically accurate experiences on JD/CR than PD...some pretty extraordinary streaks have been hit on PD that shouldn't be possible so often

Well idk what kind of streaks you've had, but impressive streaks are not that unlikely. 50000 bets on 50/50 odds and you'd probably have one 15 win/loss streak or more and exponentially more of smaller streaks the further you go down in amount of consecutive win/loss. It takes very large samples to negate variance.

Is there a way to create a simple provably fair scheme without requiring a fixed server seed hash? For example, is it possible to present a user a server seed hash which changes every roll along with a client seed which changes every roll but make it so the user can verify that the client seed being regenerated each roll is not manipulated? This would allow instant verification via command line without having to generate a new pair of seeds if possible, correct?

If you generate the client seed using javascript from the user's browser is this provable?  Is the only strong and instantly verifiable system Just-Dice's or are there other ways to go about instant provably fair without having to require users to input a client seed. Ideally I'd like to make something as strong as JD's system that is very simple to verify via terminal/command line and is very simple to understand, the vast majority of users do not understand provably fair.

Thanks so much

A per bet server secret system should include unobfuscated code, client side client seed generation using a cryptographically secure method like crypto.getrandomvalues, and a hash of all server generated values that will be used in determining the outcome of the bet sent before the client generates its seed.  Additionally, state must be preserved at all times.  One very tricky way of exploiting this kind of system is for the server to simply ignore winning bets by feigning network connectivity issues.  The user should always be provided with the same server hash as before any kind of disconnection as well as the same client side generated seed, which itself should be stored client side.

Transparency is important.  For instance, I say that your client side code should be unobfuscated, but that doesn't mean it has to be served unobfuscated.  Simply provide hashes of the minified version and original version, and make the original available for analysis.  Communication between the server and client should also be plain to read and easily understandable.  I understand that it can make people a little nervous to have much of their code out in the open like this, especially when dealing with the type of money bitcoin sites often see, but remember that security through obfuscation is always a losing bet.

How about if you make up a server seed for the user, then sha256 it iteratively a million times. Like you sha256 it, then sha256 the hash, then sha256 that hash, over and over again. Then you work backwards through them, so each roll's server seed is the hash of the next roll's seed. That way you get to change the server seed every roll in a way the user can't predict, but in a way that you can't manipulate. When the user is done playing, he can verify that each server seed was indeed the hash of the next one. Then to achieve provable fairness he doesn't need to change his client seed except at the start, but can if he wants to.

That satisfies your request to be able to change the server seed while keeping verification lightweight. But I'm not sure I understand where that requirement comes from. Why do you want to be able to change the server seed every roll? What do you have against using a fixed seed plus a nonce?


The problem is that it is impossible to prove anything to a user who doesn't understand proofs. You may as well just put a shiny badge or checkmark on the page. Provable fairness is only worth anything to the people who understand it, and the people who trust the people who understand it.

The scheme I just presented is a little better than JD's in that it's instantly verifiable without the player having to hit "randomize" (and thereby change their future rolls).

I've been playing blackjack at one of bitcoin casinos  for long time.I won and withdraw on my first visit only.I started learning about Provably Fair and I red this great article http://www.reddit.com/r/Bitcoin/comments/1frm4x/provably_fair_by_bitzino_not_provable_with/ and I started changing Client Seed before every hand. And guess what happened ? I'm always winning.
In my opinion online casinos keep cheating like they did 10 years ago even if they have Provably Fair system now

This makes no sense.

If you're "always winning" at blackjack, where they shuffle the shoe before every hand, then you're either not keeping track accurately, or you're not playing enough hands for your result to be statistically significant.

You can't win at blackjack on Bitzino in the long run - it's a -EV game.

Yes you'll have winning and losing sessions, and your pattern-seeking brain will try to spot correlations between your strategies and your results, both I doubt your conclusion that changing your client seed helps you win has any validity.

Playing right strategy and having fat pocket to cover long losing streaks leads me to small winnings in every session  if the game is Fair
Changing Client Seed before every hand makes me covered by Provably Fair all the time
I wasn't writing about Bitzino.I lost a lot to another casino.In fact Bitzino is only casino that I trust
This is from comments to the article that I linked.As you can see Bitzino creator confirms that cheating is possible with Provably Fair System


"Creator of bitZino here. Thanks for writing this post, TrevorXavier! I firmly believe that the best cryptography is that which is practiced in the open, with honest and open discussion about any possible weaknesses or avenues of attack.

I've read through your entire post, and I believe that at the core, you are discussing two main issues you see with our provably fair system:

The first issue is that of "stalling". In the rare event that our servers do fail to respond (either due to internet connectivity issues, or downtime on our end), this problem can easily be mitigated by a player by simply ensuring the Hash(secret) has not changed, and then re-entering the same client_seed after reloading the page.

The second issue is that of tainting the javascript that is being executed on the player's browser (Cold Deck, Hot Reading, Mutation, and Controlled Secret all fall under this). I do agree that if we managed to slip dirty code past our users, these are potentially viable attacks. However. these are all very high-risk frauds to perpetrate, because if we were caught doing this, even once, we would completely sacrifice our reputation and future earnings potential.

Furthermore, these attacks are all relatively easy for a savvy user to detect. Since modern browsers come with built-in network analysis tools, it is easy for anyone to see all data being sent down the wire. These tools would make it very easy to detect if we tried to sneak javascript partials into ajax requests.

Ultimately though, a player can be protected from all of these attacks by running a client-side greasemonkey script which generates the client_seed (rather than relying on any code sent from our servers). And, in fact, this is already possible today due to the nature of our app being in HTML5. We have already seen a handful of our players doing this on their own (we can detect it because the client_seeds they send are formatted differently than the ones our javascript generates). Additionally, if a player just edits the client_seed by hand before they play, they are also protected from any of the attacks you listed.

At the end of the day, we still haven't fully solved the trust issue of browser-based cryptography. But, our system still accomplishes its goal - it forces us to either be honest, or take a large risk. We simply have no way to manipulate the outcome of any wagers made on bitZino without taking a risk of being caught. That's why our system is indeed provably fair: it allows savvy players to ensure the house isn't cheating them.

Thanks again for the insightful post!"

He's acknowledging the possibility of detectable cheating.  Bitzino could also just deal itself a blackjack and the player a 16 every 50 hands or so while completely ignoring their provably fair system, but they don't, because it'd be detected.

People keep wheeling out that old post by TrevorXavier as if it proves something about how provable fairness is flawed. It doesn't.

I want to try this coinroll but deposits are disabled?

What would be the best approach to make a decentralized dice roll where users can be house if they want. And casino creating server seeds cannot cheat to win the pot itself by playing as a player?