problem with off-chain "provably fair" games

[knowitnothing]

Each and every roll has to have some kind of external input that the casino cannot predict, even if the user is "lazy" and leaves the same settings in place.  I believe forcing the user to change their seed every time would work.

Changing the user seed every time doesn't solve anything, it just complicates the situation for the user to check for provably fair results (no need to make up what you believe this is, this has been discussed several times in this same forum, even outside this thread). Never forget that the server is ultimately responsible for reporting back the results.

Suppose you're changing the user seed before every bet. The system can just "shutdown the server, disconnect the user, etc" (I forgot the exact words you used) after it obtains the outcome of a bet, but before it sends back to the user. When the system "resumes its operation", it can just make up some excuse. Since the user seed is always changing, the earlier one you used would've changed now and the new bet will produce a different result (hopefully one that doesn't make the server shutdown, disconnect the user, etc). If you are not keeping track of every user seed change (lazy user as you say), you won't even know which seeds you used and you might not be able to check the results later.

if there is a 100% provably fair option why not implement it? because it is to complicated? or there is no need to implement it because the players are not asking for it? IMHO the house/casino should implement the 100% provably fair option if it exists.

First we need to understand which part of it is not provably fair, otherwise there is no hope to implement it. What I see some people suggesting is not provably fair (like using, or claiming to use, an external service), and that's why you won't see any of the current provably fair games implementing that.

[Rannasha]

I find it very peculiar that they don't understand it is nearly impossible for the casino to rig the results.

the "nearly" would tell me that it is not provably fair and the casino has a chance to rig the results.
to be frank I am not an expert of the provably fair thingy. but I fully understand what knowitnothing is saying and it makes a lot of sense to me. what I mean is, that if there is a 100% provably fair option why not implement it? because it is to complicated? or there is no need to implement it because the players are not asking for it? IMHO the house/casino should implement the 100% provably fair option if it exists.

It depends on what you consider "100% provably fair".

The common definition (in BTC-gambling-land) of provably fair is that if the server claims you rolled (for example) 12345 as your lucky number, that this number was actually generated in the way that was advertised and that it wasn't changed after the fact to make sure you'd lose.

What it doesn't mean, and what this thread was originally about, is that the server can't change the parameters of the bet afterwards. If I bet 1 BTC at 50% odds, a malicious website may change this bet into a 10 BTC bet at 1% odds after having determined that this would be a losing roll for me. The current provably fair schemes don't prevent this and it is possible for a casino website to be provably fair (in the sense that the numbers it rolls for its users are indeed what it claims), but still cheat their users (by changing bet-size / odds after the roll was submitted).

Then again, this type of cheating is very obvious as a user would immediately spot things like changed bet-size or odds. The type of cheating prevented by the provably fair scheme is much, much harder to detect.

In the end, when you deposit money to play at an online casino (or any other web-service for that matter), you're trusting the operator not to run with your money. So no matter of how many fancy mathematical algorithms are implemented, some level of trust is still required.

[lucasjkr]

I'm apparently dumb as a doornail, because I still don't understand how you can be assured that cheating can't / won't occur.

My understanding is that the server generates its secret seed, hashes it, and displays the hash. Right is far?

Then, a seed needs to be generated for the client. I assume the clients computer doesn't generate it, otherwise someone theoretically write a JavaScript that always generates the highest possible "roll", no?

So if it's done on the server, why can't the server generate several rolls instead of one, and deliver only the losing roll to the client? I just dint get it. It would seem like the client would need its own secret to insure that the server wasn't doing anything fishy, if everything is server side, I don't see how you can "prove" anything to the client except that, in aggregate, each of the bets paid at approximately the odds that were advertised?

Can we explain in English? Knowing that while I think I have a clue, I'll get lost when you start using programmers syntax?

[ASICSRUS]

.." Now, when you reveal the secret (whenever you want to)..."


whenever i want to what to?lol~ok then what makes it secret if its revealed?  

[ASICSRUS]

"Now supposing your connection is dropped before placing a bet, then the nonce isn't incremented. This means you can just reconnect and submit the same bet, and you will get the result that you would've got earlier if you were connected."


what so timing means nothing? 

[knowitnothing]

I'm apparently dumb as a doornail, because I still don't understand how you can be assured that cheating can't / won't occur.

My understanding is that the server generates its secret seed, hashes it, and displays the hash. Right is far?

Then, a seed needs to be generated for the client. I assume the clients computer doesn't generate it, otherwise someone theoretically write a JavaScript that always generates the highest possible "roll", no?

The user manually enters, i.e. types, his seed /after/ seeing the hash of the secret seed. So the secret seed is generated without any knowledge about the user seed.

[ASICSRUS]

Under this scheme each user would be required to provide a new seed for each and every roll.  If some users did not change their seed from roll to roll then the server could determine the outcome several rolls in the future (in those specific cases) and simply cut that user off, shut down the server, etc.  Any system where the server can determine future rolls in a deterministic way, even in a small fractions of the plays, is not provably fair because you cannot force the casino to keep playing.  

You can never force the casino to keep playing.  You also can't force them to actually make withdrawals when players win.  There's a limit to how far provably fair can go.

If a casino shuts down because you're about to make have a big win then something is clearly wrong.  The casino should operate within their bankroll and be able to pay out any bet they offer, so cheating the player isn't of interest to them.  It doesn't take much to get a bad reputation and with so much competition, players will just go somewhere else.

Provable fairness generally simply means that there's no way the house can influence the outcome of the player's bets.  It's usually implemented as:

1) server picks server seed
2) server displays hash of server seed
3) user picks client seed
4) play happens
5) server reveals server seed
6) player verifies that play happened according to server and client seed

1 happening before 3 makes sure the server can't influence the outcome, because the client seed changes everything
2 makes sure the server can't change its seed after picking it

Step 4 can be a single roll, like at primedice, or multiple rolls, like at coinroll, just-dice, ggdice, and probably many more.  If it's multiple rolls, then a nonce is used which changes for each roll in a predictable way, so that we can have multiple unpredictable outcomes for a single seed pair.

The fact that the server knows the player's next thousand outcomes doesn't change anything unless the server does something obvious like blocking the player's account before he's about to have a big win.


My attention was drawn to this thread after a pleasing discussion of the merits of provable fairness on the Just-Dice trollbox:

20:17:13 (194226) <mistymountain> you fuck me this round doog what did you just switch it?
20:17:52 (194226) <mistymountain> bullshit odds went up or something
20:18:18 (194226) <mistymountain> gmre changes uncresd reds i'm not dumb
20:18:38 (194226) <mistymountain> so fucked
20:19:21 (194226) <mistymountain> cherry pick times when its better hmmm~semon seed time lol]
20:19:28 (143789) <dammmmit> lol misty sounds so hard like ASICSRUS
20:19:51 (194226) <mistymountain> don't start w.the provably fair nonsense omg
20:20:34 (194226) <mistymountain> i'll move this to the tgread its cool
20:20:49 (194226) <mistymountain> nitcoin talk
20:21:14 (194226) <mistymountain> 91 percent not
20:21:31 (1) <dooglus> misty: if you calm down a little I'm sure we can get to the bottom of this
20:21:51 (194226) <mistymountain> im at bottom here
20:22:24 (143789) <dammmmit> MISTY I NEED TO KNOW, ARE YOU ASICSRUS ON BITCOINTALK?
20:22:51 (194226) <mistymountain> ok i had a bad feeling should have stopped
20:23:10 (194226) <mistymountain> Big Baller ihub
20:23:28 (2) <Deb> sup misty?
20:24:15 (194226) <mistymountain> it's cool i guess it appears something chaned monkeys behind the curtain?lol
20:25:20 (2) <Deb> misty you can check that the rolls were fair
20:26:00 (194226) <mistymountain> not even i'll post it on the board you turkey
20:26:17 (2) <Deb> who is a turkey misty?
20:26:48 (194226) <mistymountain> you all are turkeys in my book gooble gooble
20:27:15 (2) <Deb> really misty
20:27:36 (194226) <mistymountain> doog is the turkey=)
20:28:04 (194226) <mistymountain> it seemed egit but yeah all in bitches
20:28:05 (2) <Deb> well, at times i might agree misty, but never about math or fairness he'll always win there
20:28:11 (143789) <dammmmit> hey misty want a 0.02 donation?
20:28:35 (194226) <mistymountain> ok oll burn it lol
20:28:35 (193176) <chester> hi mistyASICS
20:28:49 (194226) <mistymountain> Baller to you
20:28:54 (1532) <satoshi> misty why do you even gamble
20:29:28 (194226) <mistymountain> [1ERmwC46]<dammmmit>turkey
20:30:33 (194226) <mistymountain> wjat are you smoking fool
20:31:33 (194226) <mistymountain> goog you nigged me!!!
20:33:19 (194226) <mistymountain> Deb fucking cunt gtfo no bitches up in here y0

He stopped talking at that point.  I think maybe Deb muted him.  Not sure which of his last two lines pushed her over the edge.

nice what are you trying to say? LOL

[ASICSRUS]

I'm apparently dumb as a doornail, because I still don't understand how you can be assured that cheating can't / won't occur.

My understanding is that the server generates its secret seed, hashes it, and displays the hash. Right is far?

Then, a seed needs to be generated for the client. I assume the clients computer doesn't generate it, otherwise someone theoretically write a JavaScript that always generates the highest possible "roll", no?

The user manually enters, i.e. types, his seed /after/ seeing the hash of the secret seed. So the secret seed is generated without any knowledge about the user seed.

What?~ you cant see the hash of the secret seed until after the results!!! 

[Rannasha]

My understanding is that the server generates its secret seed, hashes it, and displays the hash. Right is far?

Correct.

Then, a seed needs to be generated for the client. I assume the clients computer doesn't generate it, otherwise someone theoretically write a JavaScript that always generates the highest possible "roll", no?

So if it's done on the server, why can't the server generate several rolls instead of one, and deliver only the losing roll to the client? I just dint get it. It would seem like the client would need its own secret to insure that the server wasn't doing anything fishy, if everything is server side, I don't see how you can "prove" anything to the client except that, in aggregate, each of the bets paid at approximately the odds that were advertised?

Can we explain in English? Knowing that while I think I have a clue, I'll get lost when you start using programmers syntax?

To generate a roll fairly, you need 3 things:
- A server seed/secret. This needs to be a secret to the gambler, so he can't predict the outcome. On the other hand, it needs to be fixed and impossible for the operator to manipulate, which is why the hash of the server secret is available in advance. (EDIT: The "hash" is a function that depends on the input, but where the outupt can't be traced back to the input. Consider a very simple example of a very long number as input and the hash being the sum of all its digits. There is no way to calculate what the input was if I only know the hash, but if the input is changed, so is the hash (in 90% of the cases). In reality, these functions are much more complex to ensure that any change in the input only has a mindbogglingly low chance of generating the same hash.)
- Something that the gambler can choose/influence. This is to ensure that the operator doesn't pick seeds that give a higher than average chance to lose for the gambler. This is called the client seed. Most websites will set a random number as the client seed, but allow the gambler to alter this seed. It is important that the hash of the server seed is shown before the client seed is altered. Otherwise the operator can check what client seed the gambler has chosen and then keep generating and testing server seeds until it finds one with a good loss-rate.
- Something that changes with every bet in a predictable way, so that both gambler and operator know what changes. This is simply to ensure that successive bets have different rolls. This value should be public. This value is also called a 'nonce'. Typically, it's just the number of bets since the last time the seeds were changed.

The triplet of server seed, client seed and nonce is used to generate the outcome of the roll. The gambler doesn't know the server seed (he can only verify afterwards that it wasn't changed by checking the hash), the operator has no influence over the client seed (so he can't generate and test server seeds until he gets a favourable one and use that for the gambler) and the nonce ensures that each next bet is different.

After betting, the gambler can request the server seed for his session. At this point the website shows the server seed and generates a new one (and shows its hash, for the next bets). The gambler knows his client seed and he knows which nonces were used (since this too is public information). He can now recreate his betting session and check that the rolls that he obtained from the website match what he obtained from the verification.

The weakness in this scheme is the client seed. In order to ensure that the operator doesn't cheat the gambler, the gambler *has to* set his own client seed. Most gambling sites give you a client seed to begin with and most gamblers are lazy enough to keep it. In this scenario, a malicious operator could test the combination of server seed and client seed and pick the combination that gives him favourable results. If the gambler changes the client seed, this is no longer possible.

[Mooshire]

I'm apparently dumb as a doornail, because I still don't understand how you can be assured that cheating can't / won't occur.

My understanding is that the server generates its secret seed, hashes it, and displays the hash. Right is far?

Then, a seed needs to be generated for the client. I assume the clients computer doesn't generate it, otherwise someone theoretically write a JavaScript that always generates the highest possible "roll", no?

The user manually enters, i.e. types, his seed /after/ seeing the hash of the secret seed. So the secret seed is generated without any knowledge about the user seed.

What?~ you cant see the hash of the secret seed until after the results!!! 

I have never listened to someone so autistic on the internet before.

[lucasjkr]

Thank you! That's the part I was missing. I was thinking we were talking about, say, satoshi dice, where there doesn't seem to be any interaction beyond sending coins to an address and wondering how much you'll get back.

However, (and there's always a however), after reading bitzino's description, I think I see a potential way the casino could game the system. Far from guaranteed, but I'm interested to see if this is so?

Here's the link first: https://bitzino.com/about/fair

So, each user assuredly has an account.

The site shuffles the deck and signs it, then waits for the client to generate their seed in order to cut the deck. Now, the client can let their browser generate the seed, which would be secure so long as you're random number generator does its job. It ALSo lets you manually enter your own seed to use your own lucky numbers, etc.

If you happen to use the same lucky number or lucky phrase on a consistent basis, the server COULD "shuffle" the deck, cut it as if you were going to enter your normally used seed phrase, then look at the results of the deal. It could reshuffle if it saw that you would get a blackjack, or it could reshuffle over and over until it was assured to deal itself a 19, 20 or 21, so long as you enter the lucky phrase you'd used many times previously. Now, if you changed up your phrase or skipped entering it in favor of letting your browser make the number for you, the game would once again be unpredictable. But by entering your own seed and using the same one over and over, such a site could attempt to skew the results in their favor, no?

[Rannasha]

Thank you! That's the part I was missing. I was thinking we were talking about, say, satoshi dice, where there doesn't seem to be any interaction beyond sending coins to an address and wondering how much you'll get back.

In the case of SatoshiDice, the transaction ID serves as both the client seed and the nonce. The txid isn't known to the operator before the server seed is chosen, so he can't pick a favourable server seed. The gambler can influence the txid (it's possible to generate and sign a tx and then not submit it if you don't like the txid. You can then redo it and get a different txid) and the txid will be different for each bet (which makes it a viable nonce).

However, (and there's always a however), after reading bitzino's description, I think I see a potential way the casino could game the system. Far from guaranteed, but I'm interested to see if this is so?

Here's the link first: https://bitzino.com/about/fair

So, each user assuredly has an account.

The site shuffles the deck and signs it, then waits for the client to generate their seed in order to cut the deck. Now, the client can let their browser generate the seed, which would be secure so long as you're random number generator does its job. It ALSo lets you manually enter your own seed to use your own lucky numbers, etc.

If you happen to use the same lucky number or lucky phrase on a consistent basis, the server COULD "shuffle" the deck, cut it as if you were going to enter your normally used seed phrase, then look at the results of the deal. It could reshuffle if it saw that you would get a blackjack, or it could reshuffle over and over until it was assured to deal itself a 19, 20 or 21, so long as you enter the lucky phrase you'd used many times previously. Now, if you changed up your phrase or skipped entering it in favor of letting your browser make the number for you, the game would once again be unpredictable. But by entering your own seed and using the same one over and over, such a site could attempt to skew the results in their favor, no?

You are correct. And this doesn't just apply to bitzino, but all dice sites too. Like I said in my previous post, the client seed is the weakest link in a provably fair system. If a gambler uses the same client seed all the time, the operator can generate and test server seeds to be matched with the client seed that the gambler always uses and use the server seed that gives the best outcome for the operator.

This means that if you're very picky about your provable fairness, you shouldn't reuse client seeds.

In the end, it also boils down to the trustworthiness of the operator. A malicious operator can just take your deposit and run with it. All the provable fairness in the world isn't going to stop that. Of course, such a scheme has a very short lifetime, while a malicious operator skimming an extra 1% edge of the wagered amount by manipulating the bets on a site that doesn't implement provable fairness (correctly) is much harder to detect.

[ASICSRUS]

My understanding is that the server generates its secret seed, hashes it, and displays the hash. Right is far?

Correct.

Then, a seed needs to be generated for the client. I assume the clients computer doesn't generate it, otherwise someone theoretically write a JavaScript that always generates the highest possible "roll", no?

So if it's done on the server, why can't the server generate several rolls instead of one, and deliver only the losing roll to the client? I just dint get it. It would seem like the client would need its own secret to insure that the server wasn't doing anything fishy, if everything is server side, I don't see how you can "prove" anything to the client except that, in aggregate, each of the bets paid at approximately the odds that were advertised?

Can we explain in English? Knowing that while I think I have a clue, I'll get lost when you start using programmers syntax?

To generate a roll fairly, you need 3 things:
- A server seed/secret. This needs to be a secret to the gambler, so he can't predict the outcome. On the other hand, it needs to be fixed and impossible for the operator to manipulate, which is why the hash of the server secret is available in advance. (EDIT: The "hash" is a function that depends on the input, but where the outupt can't be traced back to the input. Consider a very simple example of a very long number as input and the hash being the sum of all its digits. There is no way to calculate what the input was if I only know the hash, but if the input is changed, so is the hash (in 90% of the cases). In reality, these functions are much more complex to ensure that any change in the input only has a mindbogglingly low chance of generating the same hash.)
- Something that the gambler can choose/influence. This is to ensure that the operator doesn't pick seeds that give a higher than average chance to lose for the gambler. This is called the client seed. Most websites will set a random number as the client seed, but allow the gambler to alter this seed. It is important that the hash of the server seed is shown before the client seed is altered. Otherwise the operator can check what client seed the gambler has chosen and then keep generating and testing server seeds until it finds one with a good loss-rate.
- Something that changes with every bet in a predictable way, so that both gambler and operator know what changes. This is simply to ensure that successive bets have different rolls. This value should be public. This value is also called a 'nonce'. Typically, it's just the number of bets since the last time the seeds were changed.

The triplet of server seed, client seed and nonce is used to generate the outcome of the roll. The gambler doesn't know the server seed (he can only verify afterwards that it wasn't changed by checking the hash), the operator has no influence over the client seed (so he can't generate and test server seeds until he gets a favourable one and use that for the gambler) and the nonce ensures that each next bet is different.

After betting, the gambler can request the server seed for his session. At this point the website shows the server seed and generates a new one (and shows its hash, for the next bets). The gambler knows his client seed and he knows which nonces were used (since this too is public information). He can now recreate his betting session and check that the rolls that he obtained from the website match what he obtained from the verification.

The weakness in this scheme is the client seed. In order to ensure that the operator doesn't cheat the gambler, the gambler *has to* set his own client seed. Most gambling sites give you a client seed to begin with and most gamblers are lazy enough to keep it. In this scenario, a malicious operator could test the combination of server seed and client seed and pick the combination that gives him favourable results. If the gambler changes the client seed, this is no longer possible.

you are forgetting the 4th seed!!!  where have you been!?

[ASICSRUS]

I'm apparently dumb as a doornail, because I still don't understand how you can be assured that cheating can't / won't occur.

My understanding is that the server generates its secret seed, hashes it, and displays the hash. Right is far?

Then, a seed needs to be generated for the client. I assume the clients computer doesn't generate it, otherwise someone theoretically write a JavaScript that always generates the highest possible "roll", no?

The user manually enters, i.e. types, his seed /after/ seeing the hash of the secret seed. So the secret seed is generated without any knowledge about the user seed.

What?~ you cant see the hash of the secret seed until after the results!!! 

you finally made it here?  omg /\\/

http://investorshub.advfn.com/Paulies-Pixel-Palace-2581/

[tonino]

You are correct. And this doesn't just apply to bitzino, but all dice sites too..............................

what does this mean? it is only dice sites related? is the provably fair option different for Roulette, Black Jack, Slots etc

[Rannasha]

You are correct. And this doesn't just apply to bitzino, but all dice sites too..............................

what does this mean? it is only dice sites related? is the provably fair option different for Roulette, Black Jack, Slots etc

In principle, it works the same on all types of gambling: The server has its secret, of which only the hash is shared, and the users have their seeds, which they can pick themselves. The final result, be it a pokerdraw or a diceroll, then depends on the server-secret, the client-seed(s) and some unique value (nonce).

If a user always uses the same client seed, a malicious operator may cherrypick server-secrets that will yield poor results for the gambler when combined with that specific client seed.

[tonino]

You are correct. And this doesn't just apply to bitzino, but all dice sites too..............................

what does this mean? it is only dice sites related? is the provably fair option different for Roulette, Black Jack, Slots etc

In principle, it works the same on all types of gambling: The server has its secret, of which only the hash is shared, and the users have their seeds, which they can pick themselves. The final result, be it a pokerdraw or a diceroll, then depends on the server-secret, the client-seed(s) and some unique value (nonce).

If a user always uses the same client seed, a malicious operator may cherrypick server-secrets that will yield poor results for the gambler when combined with that specific client seed.

thanks for clarifying. how can the casino owner pressure or force a player to change the seed? IMHO many players are just to lazy because they want the action = gambling.

[Rannasha]

You are correct. And this doesn't just apply to bitzino, but all dice sites too..............................

what does this mean? it is only dice sites related? is the provably fair option different for Roulette, Black Jack, Slots etc

In principle, it works the same on all types of gambling: The server has its secret, of which only the hash is shared, and the users have their seeds, which they can pick themselves. The final result, be it a pokerdraw or a diceroll, then depends on the server-secret, the client-seed(s) and some unique value (nonce).

If a user always uses the same client seed, a malicious operator may cherrypick server-secrets that will yield poor results for the gambler when combined with that specific client seed.

thanks for clarifying. how can the casino owner pressure or force a player to change the seed? IMHO many players are just to lazy because they want the action = gambling.

Simple. Don't set a pregenerated client seed like most websites do. Just pop up an input-box prompting for a client seed when a player starts.

The client seed can be used until the server secret for that user is changed. This is either daily, at the users request or both. At that time, prompt again for a client seed and don't accept the previously used seed.

[trout]

huge flame, but the simple observation I made is largerly missed.

There's a difference between "you know when you've been cheated" and
"when you'be been cheated, you can prove it."

Unfortunately, the off-chain "provably fair" casions provide only the first
type of guarantee, whereas the on-chain ones provide the second type.

I don't think one needs the bitcoin blockchain to solve the problem, but
the current algorithms in off-chain casions do not provide a solution.

[knowitnothing]

huge flame, but the simple observation I made is largerly missed.

There's a difference between "you know when you've been cheated" and
"when you'be been cheated, you can prove it."

Unfortunately, the off-chain "provably fair" casions provide only the first
type of guarantee, whereas the on-chain ones provide the second type.

I don't think one needs the bitcoin blockchain to solve the problem, but
the current algorithms in off-chain casions do not provide a solution.

There's no need to complicate the situation. Whenever you make a deposit at any place (this goes way beyond off the chain games), that place is able to do anything with that. The only reason such thing does not happen is because there is no interest in doing so. You can sign messages, broadcasts them, and so on, but since you made a deposit then it's just a matter of trusting the place.