The Crypto Gambling Foundation will be calling out fake "Provably fair" sites

[porto-pok]

What are you talking about ? what is a provably fair site ?

[gapjustin]

Welp, I think it's a good idea to do this. however I don't think someone who owns a gambling site should be thebone doing this as he/she might be biased.

biased to what?

Biased about their own site.
Who knows, maybe in the future an even better PF system could come out. Being unbiased in that situation is so much better for the rest. Also if you do this while owning a site yourself, it could be seen as just bashing on competition trying to get others out of the game in an underhanded method. So I still think it's better if someone without any affiliation to any site does this.

[dogedice.me]

Hey guys,

First of all, we are happy to join the CGF.

Secondly, I would like to say that

The proper way of creating a true provably fair website consists of 3 simple aspects.

[Server Seed Hash] + [Client Seed] + [Nonce]

Is not absolutely true. For example, BitDice does not have [Nonce] part, we show [Server Seed Hash] prior the bet, generate random [Client Seed] on the client and show the [Server Seed] after the bet.

http://prntscr.com/h4pi2f

This method gives few advantages:

1) If the server was compromised hacker can get an advantage over only 1 next bet. ( This prevents the case that happened with PD )
2) The casino doesn't know about future player outcomes.

Regards,
Alex.

[marckenigsberg]

I would be trying to categorize sites (from best to worst):

* Trustless
* Provably fair  (follows best practices)
* Provably fair (warning: suboptimal, not practical for human verification)
* Not Provably Fair   (game design makes provably fair impractical)
* Not Provably Fair   (for no good reason)
* Fake Provably Fair  (claims to be provably fair, but isn't)

This is a great categorization RHavar.
It helps a lot to distinguish the nuance!

[JackpotRacer]

Hey guys,

First of all, we are happy to join the CGF.

Secondly, I would like to say that

The proper way of creating a true provably fair website consists of 3 simple aspects.

[Server Seed Hash] + [Client Seed] + [Nonce]

Is not absolutely true. For example, BitDice does not have [Nonce] part, we show [Server Seed Hash] prior the bet, generate random [Client Seed] on the client and show the [Server Seed] after the bet.

http://prntscr.com/h4pi2f

This method gives few advantages:

1) If the server was compromised hacker can get an advantage over only 1 next bet. ( This prevents the case that happened with PD )
2) The casino doesn't know about future player outcomes.

Regards,
Alex.

good to see more and more joining in

to be frank I am not a Provably Fair expert. my question to you is if the player can verify thousands or more bets after his betting session? or is it only bet after bet after bet that he can verify?

thx

[marckenigsberg]

Starting next week the crypto gambling foundation (www.cryptogambling.org) will be publicly disclosing sites which don't use proper provably fair methods.

You guys are doing a great initiative here.
Well done!
As someone in gambling since 1999 and crypto gambling since 2013 I totally get the need for this.
I'd like to suggest than an education aspect here is key too.
In my experience the reason provably fair has not gotten the traction it could is because players do not understand it.
It woould be good for all the brands if more people understood the benefit.

[RGBKey]

Good job, Now you want to  stop them from cheating people? I used to gamble a lot but after some time I realized the only outcome was for me to lose no matter how I gambled and how many strategies I used. I wanna know what happens to casinos if they all use real provably fair system? Probably they will all close down their business and go home, Because if you let the results to be determined by random outcomes then one would use a simple strategy to win at the end.

Not sure if you're trolling, but just in case some people don't know how this works, that's not at all how that works. Casinos wouldn't close down if they were probably fair. "Provably fair" does not mean you won't lose money. It means you know exactly what the odds are, and since you're betting against the house, you know the odds are against you by 1-2%. Provable fairness doesn't stop you from losing money, it stops the house from changing the odds against you in a way you weren't expecting.

You're still playing a game where you're expected to lose money to the house in the long run. That's gambling.

[Kprawn]

The forum  { https://forum.cryptogambling.org/ } is still very quite, I would have thought that there would have been a lot

more activity for a important need like this. I hope whomever is affiliated with this, would be properly screened, because only

one mistake will kill this initiative. People are already paranoid about these sites that are "ranking" gambling sites. 

[RHavar]

Is not absolutely true. For example, BitDice does not have [Nonce] part, we show [Server Seed Hash] prior the bet, generate random [Client Seed] on the client and show the [Server Seed] after the bet.

http://prntscr.com/h4pi2f

This method gives few advantages:

1) If the server was compromised hacker can get an advantage over only 1 next bet. ( This prevents the case that happened with PD )
2) The casino doesn't know about future player outcomes.

Regards,
Alex.

Your method is absolutely provably fair, and certainly does have advantages (like I think it's the best way to build an API) -- but it's very suboptimal from a users point of view. Realistically it's hard to get users to do the provably fair verification once, let alone for every single bet. Also with the nonce system even if a user doesn't record their server-seed hash (which, let's face it: almost all the time) once a person has made more than half a dozen or so bets (with the same seed) it doesn't matter as it wouldn't be possible for a malicious site operator to find collisions anyway.

I think the only way to make the one-seed-per-bet system really useful for users would be to provide a (small and easily auditable) browser plugin. The browser plugin itself should randomize the client seed (when a bet is happening) and itself verify the result of the bet (issuing an alert when it doesn't verify). The browser plugin should never advertise itself, so the site has no way of knowing if the user is using it or not.

That said, I do think it's just far better to use a nonced-based system.

[Nelka4]

Hey guys,

First of all, we are happy to join the CGF.

Secondly, I would like to say that

The proper way of creating a true provably fair website consists of 3 simple aspects.

[Server Seed Hash] + [Client Seed] + [Nonce]

Is not absolutely true. For example, BitDice does not have [Nonce] part, we show [Server Seed Hash] prior the bet, generate random [Client Seed] on the client and show the [Server Seed] after the bet.

http://prntscr.com/h4pi2f

This method gives few advantages:

1) If the server was compromised hacker can get an advantage over only 1 next bet. ( This prevents the case that happened with PD )
2) The casino doesn't know about future player outcomes.

Regards,
Alex.

By adding a nonce you will be able to allow your users to easily verify bets. Otherwise they are forced to verify bets one by one. This isn't exactly a good way to go. You could possibly change the server seed hash knowing what the next client seed is thus outcome. I don't see this as a proper method of fairness.

When you say if your server was compromised, the hacker would only know 1 outcome of the roll, wouldn't they be able to consistently see the next server seed hashes (Unhashed) and thus do exactly the same thing?

I don't personally see this as a optimal way of going about true fairness.

[cwil]

Is not absolutely true. For example, BitDice does not have [Nonce] part, we show [Server Seed Hash] prior the bet, generate random [Client Seed] on the client and show the [Server Seed] after the bet.

http://prntscr.com/h4pi2f

This method gives few advantages:

1) If the server was compromised hacker can get an advantage over only 1 next bet. ( This prevents the case that happened with PD )
2) The casino doesn't know about future player outcomes.

Regards,
Alex.

Your method is absolutely provably fair, and certainly does have advantages (like I think it's the best way to build an API) -- but it's very suboptimal from a users point of view. Realistically it's hard to get users to do the provably fair verification once, let alone for every single bet. Also with the nonce system even if a user doesn't record their server-seed hash (which, let's face it: almost all the time) once a person has made more than half a dozen or so bets (with the same seed) it doesn't matter as it wouldn't be possible for a malicious site operator to find collisions anyway.

I think the only way to make the one-seed-per-bet system really useful for users would be to provide a (small and easily auditable) browser plugin. The browser plugin itself should randomize the client seed (when a bet is happening) and itself verify the result of the bet (issuing an alert when it doesn't verify). The browser plugin should never advertise itself, so the site has no way of knowing if the user is using it or not.

That said, I do think it's just far better to use a nonced-based system.

Both described methods have negative consequences.  Utilizing an incremental nonce with an unchanging server and client seed prevents real-time verification of rolls, which is obviously useful to people placing a lot of automated bets.  This is, in my opinion, a major flaw.

The author of this thread states that the intent is to protect the average gambler.  The average gambler is not going to notice if a site selectively overwrites its client seed generation code.  The average gambler is not going to understand that a 14 digit numeric client seed, like what I just received from Primedice, makes precomputation attacks much easier.  Additionally, I highly doubt the average gambler cares or could even understand anything being discussed in this thread.

I don't mean to give the impression that this is a bad or misguided idea.  Honestly, as Primedice is a major part of this, I probably shouldn't comment on it at all.  Regardless, it's wrong to make people think that adding a nonce is some kind of magic solution to fairness.  I think this initiative would make more of an impact if they were to champion the idea of strong, user-generated seeds.  I also think that if this group is going to be calling out gambling sites, then perhaps it should call out sites that generate weak client seeds.  Perhaps sites should generate a client seed equal in complexity to the server seed.  For instance, Primedice generates a 256-bit server seed, I'd say they should strive to also generate a 256-bit client seed, rather than the ~40-bit client seed I've received.

[Stunna]

Is not absolutely true. For example, BitDice does not have [Nonce] part, we show [Server Seed Hash] prior the bet, generate random [Client Seed] on the client and show the [Server Seed] after the bet.

http://prntscr.com/h4pi2f

This method gives few advantages:

1) If the server was compromised hacker can get an advantage over only 1 next bet. ( This prevents the case that happened with PD )
2) The casino doesn't know about future player outcomes.

Regards,
Alex.

Your method is absolutely provably fair, and certainly does have advantages (like I think it's the best way to build an API) -- but it's very suboptimal from a users point of view. Realistically it's hard to get users to do the provably fair verification once, let alone for every single bet. Also with the nonce system even if a user doesn't record their server-seed hash (which, let's face it: almost all the time) once a person has made more than half a dozen or so bets (with the same seed) it doesn't matter as it wouldn't be possible for a malicious site operator to find collisions anyway.

I think the only way to make the one-seed-per-bet system really useful for users would be to provide a (small and easily auditable) browser plugin. The browser plugin itself should randomize the client seed (when a bet is happening) and itself verify the result of the bet (issuing an alert when it doesn't verify). The browser plugin should never advertise itself, so the site has no way of knowing if the user is using it or not.

That said, I do think it's just far better to use a nonced-based system.

Both described methods have negative consequences.  Utilizing an incremental nonce with an unchanging server and client seed prevents real-time verification of rolls, which is obviously useful to people placing a lot of automated bets.  This is, in my opinion, a major flaw.

The author of this thread states that the intent is to protect the average gambler.  The average gambler is not going to notice if a site selectively overwrites its client seed generation code.  The average gambler is not going to understand that a 14 digit numeric client seed, like what I just received from Primedice, makes precomputation attacks much easier.  Additionally, I highly doubt the average gambler cares or could even understand anything being discussed in this thread.

I don't mean to give the impression that this is a bad or misguided idea.  Honestly, as Primedice is a major part of this, I probably shouldn't comment on it at all.  Regardless, it's wrong to make people think that adding a nonce is some kind of magic solution to fairness.  I think this initiative would make more of an impact if they were to champion the idea of strong, user-generated seeds.  I also think that if this group is going to be calling out gambling sites, then perhaps it should call out sites that generate weak client seeds.  Perhaps sites should generate a client seed equal in complexity to the server seed.  For instance, Primedice generates a 256-bit server seed, I'd say they should strive to also generate a 256-bit client seed, rather than the ~40-bit client seed I've received.

You make some really good points. The nonce system isn't perfect, and has some major shortcomings such as requiring a seed change to verify as noted. That being said it is still significantly stronger than the quite popular new server seed and client seed pair per bet system.

Thank you for pointing out this shortcoming by PD. This is the whole point of all of this, to encourage an informed discussion that pushes all of us forward. Indeed this is something I will raise with our developers. Perhaps this is also an argument that there should be a 'standard' for provably fair cause otherwise one website can use ultra strong fairness and other sham fairness and still claim to be 'provably fair'. Maybe it's time to create a new term for a strong standard.

Our goal needs to be to simplify provably fair to protect the average gambler. When a normal player goes to the casino he's able to visually see that he can influence the result by 'cutting the deck'. Instead of just trying to teach average players this complicated algorithm we should try and find solutions that are equally fair yet simple. I've just put up a bounty here: https://forum.cryptogambling.org/topic/18-1-btc-bounty-improve-provably-fair/ 1 bitcoin reward for a fresh system which solves the complicated nature of provably fair, 0.1btc per user for small edits that simplify the system.

[RHavar]

I also think that if this group is going to be calling out gambling sites, then perhaps it should call out sites that generate weak client seeds.  Perhaps sites should generate a client seed equal in complexity to the server seed.  For instance, Primedice generates a 256-bit server seed, I'd say they should strive to also generate a 256-bit client seed, rather than the ~40-bit client seed I've received.

Fair point, although 256-bit client seeds is way overkill. Not only would a malicious server have to guess which way you're going to bet (hi or lo), it would have to do a comprehensive search of client seeds for each server-seed it wants to test and then see if there's any statistical deviation. This is already out of the realm of possibility for an 80 bit seed, let alone bigger.

Furthermore, the statistically deviation drops off rapidly with a large amount of client seeds. Even with 40 bit client seeds, I can't imagine it's possible for a malicious operator to brute force a server seed that even has a 0.1% uplift over a randomly selected server seed.

Plus the reality is that for real provably fair validation, you don't want to trust the client anyway so the client seed complexity is pretty meaningless anyway.

[eternalgloom]

The forum  { https://forum.cryptogambling.org/ } is still very quite, I would have thought that there would have been a lot

more activity for a important need like this. I hope whomever is affiliated with this, would be properly screened, because only

one mistake will kill this initiative. People are already paranoid about these sites that are "ranking" gambling sites. 

I agree with you about the forum not being that active, I would have assumed that there would be a little bit more suggestions of gambling sites to verify in the future.
And I don't think that they are affiliated with anyone, at least the website doesn't show it and it doesn't look like they're promoting one operator over another.

I mean, they're not using affiliate links and their articles are very objectively written, they're basically offering you some technical explanations.

Now I do think that they should keep adding more casino's to their list of verified operators, a few weeks without activity isn't that great if you only have 5 verified operators listed.

[cwil]

Fair point, although 256-bit client seeds is way overkill. Not only would a malicious server have to guess which way you're going to bet (hi or lo), it would have to do a comprehensive search of client seeds for each server-seed it wants to test and then see if there's any statistical deviation. This is already out of the realm of possibility for an 80 bit seed, let alone bigger.

Furthermore, the statistically deviation drops off rapidly with a large amount of client seeds. Even with 40 bit client seeds, I can't imagine it's possible for a malicious operator to brute force a server seed that even has a 0.1% uplift over a randomly selected server seed.

Plus the reality is that for real provably fair validation, you don't want to trust the client anyway so the client seed complexity is pretty meaningless anyway.

I don't really think any of the large actors are doing anything malicious.  Smaller operations might try to implement something like what is discussed here: https://bitcointalk.org/index.php?topic=1494470.0.  Utilizing a nonce would not preclude that type of attack.  That said, complex client seeds wouldn't either.

In any case, my argument for client seed complexity is to prevent a class of attack that I haven't seen discussed much but certainly exists.  I'll again reference Primedice, not to suggest they're doing anything malicious, but it's an easy example.  They generate a client seed as such:

Code:

parseInt(Number(new Date) * Math.random() * 10)

This happens whenever the Change Seed modal is opened (or closed, this is probably a bug.)  One problem is that in major browser implementations, Math.random() is implemented using xorshift128+ and is predictable.  Another is that the value of the date object is easily guessable.  Again, I'm not stating that Primedice is doing anything wrong, but when the client seed generation code is called, a call to Facebook's Pixel Events service is also made that easily identifies the fact that the user has opened that modal.  If Primedice were to collect the results of just a few calls to Math.random(), and they don't even need to be consecutive, then it would be trivial for them to predict the generated client seed.

Generating a 256-bit hex string would not fix this, the same attack could be used.  Using a csrng would fix this, until the site decides to overwrite that code in a targeted attack against a high-roller.  The player producing their own complex seed will fix this problem.

Thank you for pointing out this shortcoming by PD. This is the whole point of all of this, to encourage an informed discussion that pushes all of us forward. Indeed this is something I will raise with our developers. Perhaps this is also an argument that there should be a 'standard' for provably fair cause otherwise one website can use ultra strong fairness and other sham fairness and still claim to be 'provably fair'. Maybe it's time to create a new term for a strong standard.

I really don't mean to place such a focus on Primedice, but in addition to the above, I also noticed that the client seed never changes when the user attempts to randomize.  Upon opening the relevant modal, the component components.ModalsWrap.Modals.Seed.Seed.newClientSeed has its defaultValue attribute set to the new random value.  However, it doesn't look like the component's state is ever updated, so the component is never rerendered.  When the Change Seed button is clicked, the currently rendered value in this component is used, rather than the new random value.  In effect, this causes the user to always have the same seed unless they enter their own.

[adaseb]

I also think that if this group is going to be calling out gambling sites, then perhaps it should call out sites that generate weak client seeds.  Perhaps sites should generate a client seed equal in complexity to the server seed.  For instance, Primedice generates a 256-bit server seed, I'd say they should strive to also generate a 256-bit client seed, rather than the ~40-bit client seed I've received.

Fair point, although 256-bit client seeds is way overkill. Not only would a malicious server have to guess which way you're going to bet (hi or lo), it would have to do a comprehensive search of client seeds for each server-seed it wants to test and then see if there's any statistical deviation. This is already out of the realm of possibility for an 80 bit seed, let alone bigger.

Furthermore, the statistically deviation drops off rapidly with a large amount of client seeds. Even with 40 bit client seeds, I can't imagine it's possible for a malicious operator to brute force a server seed that even has a 0.1% uplift over a randomly selected server seed.

Plus the reality is that for real provably fair validation, you don't want to trust the client anyway so the client seed complexity is pretty meaningless anyway.

Yes I agree that a 256 bit client seed is over kill however with the fast CPUs of today it doesn't really consume many resources.

Most of the larger sites are already hosted on Xeon dedicated servers and most of the time those CPUs are pretty much sitting idle. The hashes are done very fast on those CPUs.

[RHavar]

Yes I agree that a 256 bit client seed is over kill however with the fast CPUs of today it doesn't really consume many resources.

Most of the larger sites are already hosted on Xeon dedicated servers and most of the time those CPUs are pretty much sitting idle. The hashes are done very fast on those CPUs.

It's not really about performance, but about the user experience of it. Big hashes are pretty scary, while for instance in bustadice.com, my client seed is: "pleasant macho match" which was generated using strong client-side cryptographic random number generation. Granted there's not that much entropy in it, but it's something that is very easy for me as a human to remember (and thus be sure it didn't change).

And I don't really think low-entropy is a big deal, the amount of uplift a malicious picked server-seed is pretty much negligible -- and rapidly approaches 0 when a user keeps betting.

Plus like I said earlier, players in general don't really have the ability to audit the game client each time -- so really should be picking their own client seed.

[Aengus]

Yes I agree that a 256 bit client seed is over kill however with the fast CPUs of today it doesn't really consume many resources.

Most of the larger sites are already hosted on Xeon dedicated servers and most of the time those CPUs are pretty much sitting idle. The hashes are done very fast on those CPUs.

It's not really about performance, but about the user experience of it. Big hashes are pretty scary, while for instance in bustadice.com, my client seed is: "pleasant macho match" which was generated using strong client-side cryptographic random number generation. Granted there's not that much entropy in it, but it's something that is very easy for me as a human to remember (and thus be sure it didn't change).

And I don't really think low-entropy is a big deal, the amount of uplift a malicious picked server-seed is pretty much negligible -- and rapidly approaches 0 when a user keeps betting.

Plus like I said earlier, players in general don't really have the ability to audit the game client each time -- so really should be picking their own client seed.

Easy to remember client seeds should be implemented more. Not sure why we haven't taken a similar approach. A lot more logical than a string.

[Nelka4]

When will this be happening? Waiting to see how this pans out, really interests me the whole initiative behind this foundation. It's something Bitcoin gambling needs but it needs to happen soon.

[lrdeoliveira]

I've noticed a lot of websites recently who are using the guise of provably fairness to legitimize themselves but in fact since educating myself about how it all actually works, fall into one of the subpar categories Rhaver was mentioning. This should definitely be brought to light as me a few weeks ago would have never noticed anything