Topic: problem with off-chain "provably fair" games - page 2. (Read 4799 times)

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.

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

you finally made it here?  omg /\\/

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

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

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


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.

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?

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

Correct.


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.

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

nice what are you trying to say? LOL

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.

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

.." 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?  

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?

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.

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.



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.

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.

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

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:


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.

I'm sorry, but I think it's someone else that is confused here. Provably fair basically means you have enough information right now that you can later use to verify that all the rolls should have occurred exactly as they occurred (add to that what we already discussed about server seed, user seed, etc). You just want the site's operator to act in a fair way, which you obviously wouldn't believe if I simply said that I'm operating in a fair way (right ?).

The pattern situation you describe is indeed a possible situation, but that unfortunately doesn't remove the provably fair status. But the big issue with this conspiracy theory is that it takes a single user to take the entire bankroll if such thing is in place. The users would start noticing how every default seed pair are behaving, and then take advantage of that to win all the bankroll. Forcing some kind of change (please be more specific) for every roll doesn't fully eliminate that, and at the same time it makes much harder for the player to verify the provably fair status.