Topic: BetterBets.io - NOT provably fair (Read 3369 times)

Wealthydice will be updated once we are done with the complete revamp of our provably fair system. This was scheduled to be completed but I've been sidetracked by my daughter getting a nasty stomach flue (possibly worse, we'll find out tomorrow), throwing up all over the place and generally being sick.

Apologies for the delay.

If you sold a script and get to know about a serious issue in it, what are you going to do ?

Wealthy Dice now shows that you can chose the seed for the full range, but you CAN NOT.

It still allows only for the half range ...

Once again, thanks for your feedback. I'll be implementing these sometime this week, but I've got a ton of customer work I have to take care of right now, because if I don't, I (or rather my company) will be in trouble.

I'll report back when I have an update.

I agree with your sentiment, I've decided to give the OP some positive trust due to the way that the post was dealt with. It could have easily been very negative under scam accusation and caused negative reputation on the site.

yep correct wording "Awesome transparency" thats the way it should be

I am still surprised that the OP did not get the appreciation he deserves for bringing this up. not from BB and not from MP. very sad!

without him we would not get this insight and see how NLNico and Lobos are working to get this important Provably Fair thingy to work as it should

thx to OP - NLNico - Lobos for doing it here in public and not in the dark (skype)


 

Awesome transparency guys - thanks for all that information Nico, its really helping me learn about how these dice sites fit together! I almost unwatched this post - glad I didn't =)

Looks like a good improvement but still some things:



Yeh, you shouldn't do that You really have to consider all the situations from a perspective where both MP and you (BB) want to cheat the player and how they could possibly do that

You are sending now the next clientseed to "the gambling site" (from player perspective MP+BB could be colluding and the same) before the player gets the next serverseed hash. I adjusted a previous example slightly, but still almost the same is possible:
I understand that you don't actually send the next clientseed to MP, so MP has no idea what the next clientseed will be, but there is no way for the player to verify that you really don't send this information.




TBH with the "per roll" implementation, I think it's fine to only save the clientseed locally and not on the server/profile. This would actually make things easier for you too, I think?

Each bet just has a clientseed (loaded from localStorage or generated in browser) and sent to server only upon making a bet (so after user got serverhash for that bet.) After a successful bet, a new clientseed will be generated in the browser (and saved.) This new clientseed is shown to user, unknown to server, adjustable locally and again sent upon betting.


Looks good, but for the first bet, the serverseed hash is still not shown. This way a player cannot verify if the first bet was generated fairly (unless checking in source/requests.)

Also showing every bet as list might be too much. I personally think just showing the last bet (and current/net info) is fine.



Very nice

You only check the roll number though (indeed properly in browser.) You should also check: if the hash that you got before the bet is the same as "SHA256(server_roll+'|'+server_salt)". Because now if MP changes the hash, you will still say it's verified. The whole idea of the hash is to ensure that MP generated the server_roll before they knew your clientseed and therefor couldn't influence to a preferable outcome. That only works when you verify the hash that you got before the bet though.

Ideally you could check if wager is same as loss (in case of loss) or the expected bet return is same as actual profit of that bet. I don't do that on my verifier because I don't have access to it. But since this is all on your site, it makes perfect sense to verify that info too.

Small detail: personally I would probably add a JS alert when something goes wrong, rather than only coloring that column red.

Yeh, I am not sure if it really makes sense in the account settings though. I understand it from your technical perspective, but for the user it doesn't make much sense. Also it seems like it doesn't really use the clientseed I choose even after I click save?

Personally I would do something like this:



So:
1. Clearly show the clientseed and hash for next.
2. Allow player to change clientseed right there (no need to click "Save" button either, like previously mentioned: just save in localStorage upon change or focusout.)
3. Only show last 1 bet. In theory it's better that you show multiple last bets, but I think that might be too much for user. Up to you though
4. I renamed "ServerSeed" to "ServerHash". My previous post was probably not very clear about that either, but I think that makes more sense to call it hash.
5. You could make the salt/hash to a disable input box, so there is no overlay problem but still easy to copy-paste.


I had this too. I am guessing that loading the demo site makes an empty serverseed (which isn't null). I would probably change:
to:








Almost there

So, after a few hours hacking, I'm happy to be able to report the following status:

Note: Please see the end of this post for 3 "Edit" points which were added after the initial post to clarify some potential issues.


A new server seed is requested through the MP API when a new account is created. This has worked this way since site launch (as otherwise we wouldn't be able to place bets against MP), so nothing has changed here. Please note, that a new server seed is (and was) *not* received from MP if a bet fails so the latest valid server seed remains the one which is being used.

Regardless of the above, I've added code to save the server seed to local storage. When the page is loaded, the local server seed is compared to the server seed in the user profile (from DB) and if they don't match, the user will get an alert.

The exception to this is if the local storage server seed is null (meaning that a user has not logged in since the new code is in effect or has wiped his local storage). If this happens, the system writes the server seed received from the DB to local storage for future verification.




Client seed is now also saved to local storage and as such, will be re-used if a bet doesn't go through.

When a bet is placed, a new client seed is generated and sent along with the bet data and then saved to the user profile in the DB. If/When the bet is returned as successfully processed, the previously generated client seed is written to local storage for reuse and checking. This ensures that
a) Client seeds are available for checking and are continously updated as bets are placed
b) Client seeds are only updated if a bet is returned as successful, meaning that if a bet fails, the next roll will reuse the client seed of the failed bet.




I've added a box on the side (currently it's always visible, we'll see what our users say) where upon placement of the bet, the locally available info (client seed + server seed) are displayed right away. Once the bet returns as being successful, the display is updated with the info from the server (betID, server secret, salt, next server seed and the reported roll). Using this info, the system then re-calculates the bet result (on the client using a JS function) and displays this as "Verified result". If returned result and verified result match, these are marked in green. If not, they are marked in red.

This makes it easy to see:
1) The new server seed becoming the actually used server seed for the next bet
2) The verification of reported bet result against a locally computed one.




Done. Player can set client seed and then the previously discussed local client seed generation resumes.




Done, see info from point #3.




Done, see info from point #2.




Done. See info from point #2.




I still need to a link to the newly added sidebar bet info box to allow this, but for now I think we're OK (you can always click on the bet link and use the link from the popup/modal which displays).



Done.





Should also be fixed.


In closing: thank you for your help. I think/hope that we now got it right and that we have an unassailable provably fair system. I would appreciate if if you could:

1) Comment on my replies to your points and see if everything sounds OK.
2) Give my JS code another look to see if it all holds up.

Hopefully all is OK and we can now put this thing to rest.



EDIT: if you're getting a semi-broken layout when going to our site, please press CTRL-Reload to force your browser to reload the new CSS file.

EDIT2: Turns out on Firefox there's a difference in the way a certain CSS command is implemented leading to a text overflow on the provably fair box. I'll try to find a way around it but our strong recommendation is to use Chrome, it's simply a better browser.

EDIT3: One of our users has reported a "Server Seed mismatch" error the first time he visits the site after this update. I can't reproduce it so far but I'll try to figure out why.

WOW Nico

A hell of a job

APPLAUSE CLAP CLAP CLAP

I copied it for our next coder

Nico,

thank you for having taken the time to summarize all the details for a quality provably fair implementation; it's really helpful to have this in a single post rather than having to gather all the pieces from various posts all over the place.

Look for an implementation of this on BB (and WD) in the very near future.

Lobos

Okay, so I can see in the HTTP requests that you send a new proper-random clientseed every bet now. But there are still some things missing. I guess some of that I should have previously mentioned and emphasized (although RHavar did mention some of it in a reply.) Anyway.. it might be best if I just describe what I think would be the best provably fair system for a MP app. Probably more MP apps could use this This might get a bit long..

Note that almost all provably fair implementations, even on biggest non-MP sites like Primedice, could be improved in my personal opinion. So I don't think it's easy to get all the details right, but still fundamentally there are things missing now on BB. Obviously some of these things take more time than the "1 minute fix" that I mentioned But still I think it's worth it to take some time to fix it properly.

The thing I like about MP (with regards to provably fair), is that it allows app/sites to "protect" their players against MP. Because in the end, only MP can cheat the players if the provably fair mechanism is bad. But if you as a MP app actively verify all bets, it gives the provably fair mechanism an advantage compared to non-MP sites. Because if you do that, it would need some serious scammy colluding between MP and app owner to cheat the players. However, this only works if the implementation is good.



Provably Fair on a MP app

1. Initial site loading - get serverseed
If player is 100% new, generate new serverseed hash. If played before, get the same "next serverseed hash" as before.

The last part is important (saving the serverseed hash), because otherwise MP could "refuse" a winning bet by faking a bad connection. If a player would F5 after that "bad connection on bet" and get a new hash, MP would have prevented losing a bet. So it's important to get the same hash. In theory the player cannot trust your site either (potentially you are colluding with MP), so ideally this will be saved locally (localStorage seems ideal).

I can see the hash in the "getInitSettings" request and also that the same hash is saved server-side. Ideally you can still improve this to save it locally too and for example verify the hash with the one you get by getInitSettings (if wrong: probably check if that local hash was already used? then show error if really wrong.)

2. Initial site loading - get clientseed
Check localStorage if there was a previous generated clientseed, if yes, use that. If no, generate a new one in browser with proper random generator (not Math.random.)

The first part is for the same reason as "saving serverseed hash". Imagine if a player makes a big bet that would win, but MP fakes a bad connection. Your player will probably get an error "try again later" or something. Player F5-es, you generate new clientseed and he bets again. Bet succeeded and was a loss with this second clientseed. No one will ever noticed that the player was cheated, but in reality MP would have gotten a free re-try of that losing bet. From a player-perspective, they cannot trust you either (since you could also fake a bad connection.) That's why the clientseed should be saved locally like localStorage.

You generate the clientseed properly now with a cryptographically secure RNG, but don't save it.

3. Show the serverseed hash + clientseed
The app should show the serverseed hash + clientseed, so that a player can write it down.

Showing this hash and clientseed is crucial, because the player needs to verify the serverseed didn't change. If you only get the hash after the bet, it has no value.. because the site could just give u any losing seed+hash (that "verifies".) So basically, getting the serverseed hash before each bet is a crucial part of the provably fair mechanism. Obviously the player must see the clientseed too, even though you generate it fairly in the browser, because not everyone can check their HTTP requests and JS vars.

Ideally this will be a small "Provably fair" box on the site - potentially one that can be shown/hidden. Small detail: I think it's important for "per roll" implementations (like MP app) to ensure that no HTTP request was made when someone clicks on the "Provably fair" tab/box too (because it notifies the site when the player is actively checking their rolls.) Besides that you should already have the serverseed hash and clientseed, so no need to make a HTTP request.

Currently I cannot see where you show the serverseed hash + clientseed, you really must show this. That being said, for nerds like me, I can figure it out in the HTTP request and JS vars for the initial bet. But not everyone is a nerd like me.

4. Allow player to change their clientseed
Okay, so now you generate the clientseed in a fair/secure way in the browser. In theory the player doesn't have to change their clientseed. That being said, not everyone has the technical knowledge to verify that the clientseed was indeed really generated in the browser. Potentially the clientseed was generated by "the gambling site" (in this case MP+BB) and since "the gambling site" also know the serverseed, they could make any outcome they want based on previous plays if they generate both seeds.

Again, I know this is technically incorrect.. because you generate that clientseed 100% fair. But for non-technical people who still want to fully ensure that their bets were made 100% fair, allowing them to change the clientseed is an easy way to ensure this. This adjusted clientseed will be only used for the next bet (and also saved locally like #2.)

You should still allow the player to change their clientseed even when you generate a new clientseed every roll.

5. Player makes bet (sends bet details + clientseed) - gets result/seeds/secret + next serverseed hash
Okay, we made it.. time to make a bet. So the HTTP request to make a bet includes the clientseed since MP needs this to make the bet too. The HTTP response will have the bet result (roll/win/loss/profit/..?) But it should also include: the used serverseed (which is secret + salt) and the next serverseed hash.

The used serverseed is useful, because then you have all the components to calculate/verify the roll result in the browser. We will come back on this later at #7. Ideally you could show the previous secret, salt, hash, clientseed in that "Provably fair" box of #3 too, although they can be accessed through the bet detail popup too.

The next serverseed hash is also crucial. Like mentioned in the previous points, the player needs this hash before each bet to ensure the bets were made fair and the serverseed didn't change. So after this first bet, you will again need to show the serverseed hash for the next bet so the player can write this down and afterwards verify the hash didn't change. So this next serverseed hash should be shown.

Currently you do not return and show any of this information. Even nerds like me, cannot get the next serverseed hash after the first bet unless I click bet details of previous bet.

6. Generate new clientseed
After the bet and after we got the next serverseed hash, we generate a new random clientseed in the browser.

You changed this in your last fix so this is good now. Although it must be still saved and shown like previous points.

7. Verify the bet in browser
Like I said, the advantage of the MP provably fair mechanism is that you, as gambling site, can actively protect the player from MP cheating. To do this, you would need to automatically verify the bet after each bet was made. Since you have all the seeds/hash/profit, you can: 1) check hash 2) calculate outcome/roll and verify if same 3) verify if profit/loss is correct. This should be all done in the browser. Give error if not fully verified.

Note that most gambling sites do not do this. Verifying is all about not having to trust the gambling site and checking if they calculated the results fair. But if you use a site to verify, you are trusting that specific site to properly verify it. So in theory, if the gambling site cheats the player, their own verifier will probably say it was all fair too. That's why I think third-party verifiers are much better and basically on-site verifiers doesn't make much sense ... for non-MP sites.

However, for MP sites, it makes perfect sense. Because in this case, the MP app is the third-party verifier since it is checking the results coming from MP. This way you can actively protect the players against potential MP cheating. So from a provably fair perspective I see this as an advantage of MP (apps) compared to non-MP apps. Obviously this advantage is only used if you actually do this.

Ideally you will verify each bet in the browser.

8. Make it easy for players to verify the bets on a third-party verifier
There is this great site called dicesites.com that has verifiers for a lot of sites and allows URL parameters (seeds,hashes,etc) to easily verify bets with a single click. This makes it easier for players to verify their bets on a third-party.

You guys do this



000. Small things
Some smaller things: you should just delete the "Client Seed Sequence" reference now, it's only confusing and never used.

Sometimes you show a negative value at "Server Secret" when the results gets over 2^32-1 (SQL INT limit?) This causes the "result" verification to be correct but the "hash" not. Example: MP says secret is 3,990,879,637. You say that secret is -304,087,659 for that bet. With clientseed 335,767,772... the outcome will be both 31,680,113 because (3990879637+335767772)%2^32 = (-304087659+335767772)%2^32 - but the hash will be different. Verifier linked from your site.







TL;DR: you should show the locally-saved serverseed hash (that you must get after each bet too) + adjustable locally-saved clientseed to the player and ideally verify each bet in browser after bet was made. Damn, didn't realize I could summarize this in a single line of text rather than this book

the sig manager should throw you out because of stupid postings and spam. I will forward your postings to him

why should we be jealous? we never said BB has an ugly website. we are proud to have the ugliest website and games on MP

lets do a top 10 of hundreds or thousands of MP apps! what do think which rank we have? yes you guessed it right lol

BB is and was till now the flagship app of Moneypot but now exo had more wager than BB and why that? how much does BB or exo earn with all those wager amounts? I will not tell you cause you should do the maths

why did BB sell a license to WD? someone told me that they needed money? didnt you see what RHavar wrote? he gave BB owner a loan of thousands of usd free of interest. he helped them to get started and we know that already long ago.

did anyone help us with money? NO and why not? guess why

did we sell a license? NO and why not? guess why

we will never sell a license but we could sell our app at any time and guess why? yep you guessed it again because it is ours

yes we have no coder right now and it is not easy for us to find one and thats the advantage of BB that they have a coder but again what does it mean? how much do they earn? do the maths

lets see how often you will show us this signature 

He is, he admitted that it was a bad day nonetheless and on the contrary you should probably be hiring someone to make up for your site if you are so jealous with betterbets getting listed in most sites while your site is not despite that both are from MP. Thankyou for the laugh as well

You might have missed the part that I didnt want to talk to their dev or anybody of them. My intention was to get it fixed in first place, otherwhise I would have asked wealthy as well for a bounty no ? And maybe would have used a new bctaccount, wouldnd have posted the log like u noticed sherlock, etc...

But ofc youre free to believe whatever you want. Or maybe its the coins you get paid for listing the gambling sites on your page, that makes you see things different idk...
Anyways the point is the same ... and Nico explained it pretty good.

When I asked you for exactly that case, your answer was:

Sorry to say so, that is a bunch of crap. A coding language is a coding language, they all do the same thing.

Besides that, you didnt even know how the provably fair system of moneypot works. When I explained it to you, you didnt want to believe it either until you saw I was right.
Looks a bit like you dont know what you're actually doing...

thx for the laugh and showing us your signature and again you earned some satoshis! go out and party with your GF with the satoshis

just read back the thread and conversations and then you can tell us if BB dev lobos is a nice and polite guy and not arrogant (as I said) and BB admitted that they had this flaw and fixed it? why did they fix it if the OP was inventing this flaw

on the contrary you should ask BB to give this OP a bounty cause he earned it

If betterbetsdev is an arrogant then you should look at the mirror and see how bad yourself is. Seriously you are adding nonsense here, your personal grudge against betterbets should be directed somewhere else. Quick look and I notice you are just jealous with their site.

yes it is no joke we had a coder who wanted to help and gave me some lines for our code to add (copy/paste) and he told me where to put it and I did it a few times already since we have lost our coder. we had 4-5 coders in the meantime they only wanted coins for nothing or one stole our game and opened a  MP app and is still there and MP just let him do this instead deleting his app (sad)

regarding BB I fully agree with you and I mentioned it before that the OP should get a bounty from BB and/or MP

and this arrogant dev lobos started out tough and arrogant without any reason against OP and dooglus and then came back and down on the floor and fixed it

lol. My head was spinning with the 'codes talk' then I see this. So I say, me too!
Sorry for butting in on you guys' discussion but, I'm glad it's been fixed and all so,

What happens with OP? It was a good spot by him, he spent time and effort, tried to have this resolved privately but he was instead treated rudely/offensively. To the extent that he was even ridiculed and called a blackmailer.
Is this really how BB just gonna brush it off? An attempt to discredit OP and then downplay/trivialize the issue?

BB saves their reputation and OP doesn't even get a word of thanks, much less a reward. He gets taunted and scoffed at instead by some shills. Huh. Well played.   

@NLNico thx again for the detailed explanation very much appreciated

I understand that RHavar's solution is the way to go and as you are saying it is a one minute job to implement it. how long will it last for a non coder like me? ( we have no coder right now )

is there a copy/paste option? I am very god in copy/paste