Flawed Provably Fair Systems

[cwil]

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.

[1714795087]

1714795087

[1714795087]

1714795087

[1714795087]

1714795087

[1714795087]

1714795087

[1714795087]

1714795087

[dooglus]

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.

mysql> select * from bets order by nonce desc limit 10;
+------------+------+------+--------+---------+--------+--------+---------------------+--------+
| betid      | bet  | high | chance | nonce   | secid  | uid    | date                | profit |
+------------+------+------+--------+---------+--------+--------+---------------------+--------+
| 1269212553 |   24 |    0 | 500000 | 7258337 | 435135 | 467018 | 2014-06-23 18:21:16 |    -24 |
| 1269212514 |  192 |    0 | 500000 | 7258336 | 435135 | 467018 | 2014-06-23 18:21:15 |    188 |
| 1269212479 |   96 |    0 | 500000 | 7258335 | 435135 | 467018 | 2014-06-23 18:21:13 |    -96 |
| 1269212438 |   48 |    0 | 500000 | 7258334 | 435135 | 467018 | 2014-06-23 18:21:12 |    -48 |
| 1269212398 |   24 |    0 | 500000 | 7258333 | 435135 | 467018 | 2014-06-23 18:21:11 |    -24 |
| 1269212353 |   24 |    0 | 500000 | 7258332 | 435135 | 467018 | 2014-06-23 18:21:10 |     23 |
| 1269212310 |  384 |    0 | 500000 | 7258331 | 435135 | 467018 | 2014-06-23 18:21:08 |    376 |
| 1269212278 |  192 |    0 | 500000 | 7258330 | 435135 | 467018 | 2014-06-23 18:21:07 |   -192 |
| 1269212234 |   96 |    0 | 500000 | 7258329 | 435135 | 467018 | 2014-06-23 18:21:06 |    -96 |
| 1269212192 |   48 |    0 | 500000 | 7258328 | 435135 | 467018 | 2014-06-23 18:21:04 |    -48 |
+------------+------+------+--------+---------+--------+--------+---------------------+--------+
10 rows in set (48 min 4.40 sec)

[W-M]

@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

[cwil]

mysql> select * from bets order by nonce desc limit 10;
+------------+------+------+--------+---------+--------+--------+---------------------+--------+
| betid      | bet  | high | chance | nonce   | secid  | uid    | date                | profit |
+------------+------+------+--------+---------+--------+--------+---------------------+--------+
| 1269212553 |   24 |    0 | 500000 | 7258337 | 435135 | 467018 | 2014-06-23 18:21:16 |    -24 |
| 1269212514 |  192 |    0 | 500000 | 7258336 | 435135 | 467018 | 2014-06-23 18:21:15 |    188 |
| 1269212479 |   96 |    0 | 500000 | 7258335 | 435135 | 467018 | 2014-06-23 18:21:13 |    -96 |
| 1269212438 |   48 |    0 | 500000 | 7258334 | 435135 | 467018 | 2014-06-23 18:21:12 |    -48 |
| 1269212398 |   24 |    0 | 500000 | 7258333 | 435135 | 467018 | 2014-06-23 18:21:11 |    -24 |
| 1269212353 |   24 |    0 | 500000 | 7258332 | 435135 | 467018 | 2014-06-23 18:21:10 |     23 |
| 1269212310 |  384 |    0 | 500000 | 7258331 | 435135 | 467018 | 2014-06-23 18:21:08 |    376 |
| 1269212278 |  192 |    0 | 500000 | 7258330 | 435135 | 467018 | 2014-06-23 18:21:07 |   -192 |
| 1269212234 |   96 |    0 | 500000 | 7258329 | 435135 | 467018 | 2014-06-23 18:21:06 |    -96 |
| 1269212192 |   48 |    0 | 500000 | 7258328 | 435135 | 467018 | 2014-06-23 18:21:04 |    -48 |
+------------+------+------+--------+---------+--------+--------+---------------------+--------+
10 rows in set (48 min 4.40 sec)

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.

[moreia]

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

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.

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

[Namworld]

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

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.

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.

[Stunna]

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

[cwil]

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.

[dooglus]

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?

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?

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.

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).

[anp31]

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

[dooglus]

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.

[anp31]

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!"

[cwil]

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.

[dooglus]

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.

[wang_yan]

I want to try this coinroll but deposits are disabled?

[truedeckTeam]

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:

You know how x2 is either roll under 49.5 or over 50.5 for 1% house edge dice site? x99 payout is roll under 1 or roll over 99? The losing rolls are always in the middle of the 0-100 rolling range.

So since a new server seed is provided for each new bet, they could select their server seed assuming the client seed doesn't change and give numbers that tend toward the center of the range instead of being random. Here's what would happen.

1. Client changes the seed after each new server seed, before every bet. He doesn't know server seed, so seed he provides should give a random number. (Painfully tedious, few actually do it, but for those who do, provably fair.)
2. Client doesn't change his seed. All bets are rigged and he doesn't play with a 1% house edge. This would be impossible to be caught since the roll would still match the seeds.

- No, you wouldn't be able to cheat the casino, because the number would still be randomly over/under 50. It would just be closer to 50 than average. The number doesn't need to be on the opposite side such that you could counter it by switching over/under to abuse it. It just needs to be closer to 50 than random numbers would, creating more losses for players. No counter.
- No, you wouldn't be able to notice that the website, across all players, has a much higher house edge than 1% which is unlikely. It's easy to fill with fake "lucky" account to compensate for the actual players who are "unlucky" and have a credible total wager volume/profit. It's also easy to limit to large account/smart targeting.
- No, you wouldn't be able to notice that no actual players report winning, because even if they gave themselves a 2% or 3% house edge or targeted accounts doing large bets for a very large house edge, there would still be winners.

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.

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?