Bitcoin Forum

I was looking at some moneypot apps to check, and noticed a major flaw in the BetterBets.io implementation of the MoneyPot Provably Fair System.

This flaw allowed Moneypot to cheat all players who played on BetterBets since the creation of the site. (approximatly 1 year I believe)

The Moneypot algorythm is this one:

(ClientSeed + ServerSeed) / 2^32 resulting in your individual roll outcomes between 0 and 99.99

2^32 = 4,294,967,296

In case the sum of ClientSeed and ServerSeed is higher than this number, the rest is taken and divided by 2^32, resulting in your roll outcome.

Most sites implement this correctly and let the user chose a number between 0 and 4,294,967,296.
But BetterBets is limiting the User to a chose a number between 0 and 2,147,483,648.

This allows Moneypot to chose a ServerSeed that will make the Users/Players lose. Because the User can only change the outcome by max 50 %. Sounds complicated, but it isn't. Heres an example:

Let's say Moneypot picks a Serverseed of 0.

Now the User picks his ClienSeed in the given Range between 0 and 2,147,483,648.

Then the roll result will be between 0 and 49.99.

With other words, if the User plays 2x on high, he will lose.
And there is no way the User can change this because BetterBets limits the ClientSeed he can chose.

Of course nobody can prove if BetterBets and Moneypot used this to make people lose and fill their own pockets.

But what we know is, that BetterBets.io has NEVER BEEN PROVABLY FAIR.


Just to mention this: That only counts for BetterBets.io, all other Moneypot Sites are provably fair because they let the User pick his Clientseed up to 4,294,967,296. At least the ones I've checked.

Regards !

Btw. no I did'nt play there and got buthurt because I lost. I've done my homeworks, this is a fact...

Are you joking? Because I ever saw someone hit 99.99 or even 0 to make a big hit and now you said that their client doesnt let us hit that? You should check their big winner tab and then you can post something like this

U understand me wrong. I said that they only allow u to change the outcome by 50 %. So whatever Serverseed they give you, you can maximal add 50 % to it.

So if they give u ServerSeed of 2,147,483,648 then your outcome can be in a range between 50 and 99.99, depenedent on the ClientSeed you pick. But with this given ServerSeed it would not be possible to have an outcome below 50.

To better understand that I recommend to just try to calculate your outcome for an example. It's really not hard to do.
Server can chose a seed between 0 and 2^32 and the client only between 0 and 2^31. The sum of both numbers devided by 2^32 will be your roll result.

You will notice that u can only change the outcome to a 50 % range between the possible 0 and 99.99.
And which range this is, get's basically defined by the ServerSeed you get provided.

Good post, although a bit sensationalist.



Assuming that is true (I didn't check) you are correct, it would make betterbets not provably fair. This is almost certainly an oversight on their part, as for them to cheat would require a collaboration between them and moneypot. If they use the same system for rubies (I didn't check) then cheating is a lot more possible.

Actually if what you're saying is true, BB needs to fix this ASAP because it means a) they're not provably fair, b) It would allow MP to cheat their customers.

I strongly, strongly doubt BB has used this to cheat. But you would be correct, they are not provably fair if you can only pick a seed of half the range.


I wrote this a while ago: https://gist.github.com/RHavar/a6511dea4d4c41aeb1eb  which is what MP casinos really should be using (client side) for picking client seeds. I'm not sure why anyone would use anything different.

Thanks for your confirmation. I did not say they did, I just said it would be possible.

Thats exactly the randomizer I'd also recommend. It's integrated in most browsers I believe.

Their manual client-seed stuff seems correct:

https://dl.dropboxusercontent.com/spa/rmczv2tqcr196vz/0wk_we9v.png


But looking at how they actually generate it, I found the obfuscated function:


which we can easily deobfsucate as _0x58ef is just a global variable with some constants, and we get this:



Which has the problem you pointed out, that it doesn't use the full range and it's also using Math.random() which is also a bad idea. They should be better using the gist I have.

Yeah, the guy who stared this thread contacted us and alerted us to this (and caught me in a bad mood after 14 hours of writing code and stuff, my apologies for that).

For some reason we changed this ages ago, I honestly don't remember why (it's been more than a year). I just fixed this, you can now enter seeds for the full 2^32 range.

For anybody wondering: we have never fudged a single bet and have never even discussed the subject of doing so with Moneypot (and neither have they). We are both stand-up operations who take security and fairness seriously.

So your bets are processed correctly but we (as stated above, for some reason I have long since forgotten) limited the client seed range. Nobody ever noticed or brought this to our attention or it would have been fixed ages ago; I've fixed it within 10 minutes after I was alerted of the issue.

Our apologies for the oversight.

I'll implement your gist tomorrow; thank for pointing it out; I was not aware of it's existence (thanks for making it available).

Hopefully this resolves it once and for all.

Edit: I just also fixed the 2147483647 range limitation in the auto-generation.

No problems. Also while stepping through the validation of the manual client seeds, I think there's a couple of minor bugs:


I believe the line "if (_0x2a5dx90 > 4294967296) {"  should be >= not >. And if it's over, it should probably be set to 4294967295 not 2147483647, I guess.

(i might be wrong, stepping through obsfucated code is a annoying :P)

I just 5 minutes ago fixed the assignment of 2147483647 and >= comparison.

Well this was a positive outcome  :o Kudos to betterbets for fixing the problem in minutes, and to allinbox for being one of the very few people who actually verify stuff!

Your gist is implemented as well but hasn't been pushed to production yet (will happen probably tomorrow).

Sleep is for wussies :-)

thank you very much for your posting and work

did you check our app/games? would be interested to know if it is the same with our games

I am not an expert and a non coder. please let me ask a question

could BB cheat their customers?

could BB cheat their customers with MP together?

edit
could MP cheat without BB's help?

edit2
you said this was since BB exists so it was already when RH owned MP?

edit3
you wrote "This allows Moneypot to chose a ServerSeed that will make the Users/Players lose."

could they also decide that a user/player will win?

I am not saying that anyone did cheat but I am trying to learn and understand it in full. sadly we have no coder now to let him check and explain it

cheers

Good to see this issue was resolved so fast.

I wonder if situation similar to this could be also possible for other services powered by MoneyPot. I mean people are usually lazy to check.

Op said this is possible only for BetterBets.io and "all other Moneypot Sites are provably fair because they let the User pick his Clientseed"

Is this really the case?

Op if you don't play at betterbets then there is a motive behind your post. I'm going to guess extortion probably.  This looks like some kind of oversight error. They fix it in minutes....now we can pick client seeds in the 4 billions on accounts.  So dev said they spoke to you and it seems outcome wasn't what you wanted -gimme money or I'm posting- and you made this post. Does this about sum it up?

can you prove your claims or are you just brown nosed? BB and MP should be thankful to this guy and his findings easy as that

they should even give him a bounty! maybe a movado watch or some btc

thx to op for posting his findings and helping MP to stay clean

They fixed it mainly because he contacted them and asked about this issue. Without him we probably wouldn't be aware that exploit like this can be even possible.
I don't know if he demanded money for this, but if I were the owner of BetterBets.io I would honor Op with some kind of small bounty for his bug hunting.

Wow really nice explanation of the provably fair system, with this provably system plus the house edge, I believe most players will lose big at BetterBets.io

@allinbox Thanks for letting us know about this bug. It is always good to have people which took a closer look into "provably fair" systems. I played on betterbets.io months ago. I actually could not notice any inconsistencies playing there.

"could BB cheat their customers?"

Not without the help of Moneypot. But BB did open the Chance for MP to cheat their users. Leaving the question why u would limit the userseed at all. It wasnt a limitation by the programming language, the dev told me. (I'll come to that in a later post)

"could BB cheat their customers with MP together?"

Yes.

edit
"could MP cheat without BB's help?"

Considering they wouldnd limit the Userseed or just set a randomizer, like stated by ryan - No.

edit2
"you said this was since BB exists so it was already when RH owned MP?"

It has been allways like this since BB was opend I got told so most likely yes.

edit3
"you wrote "This allows Moneypot to chose a ServerSeed that will make the Users/Players lose."

"could they also decide that a user/player will win?"

I assume that the sense of that would be to win money from the invested funds. That is most likely possible, because they can lookup the ServerSeed and set the UserSeed so the exact outcome would be known before the roll is done.
This actually is the case for every investsite. They all know the outcomes of either all your future rolls (in case the seeds are static and used for more than just one roll) or at least for the next one in case a randomizer is used to generate a new Seed for each Roll.

Anyways you always either trust the one whos running the site or not. They always can steal your investments and nobody could ever prove it.


Btw. I've only checked your dustlottery and your implementation allows the User to chose from the full range. But also using the same seed for more than 1 roll would allow MP to cheat technically, but this would be caused by the User himself then and not by the App owner/dev.
Actually you still would need to change the seed for each roll, so I believe the best option would be to use the randomizer from ryan but leave the option for the User to change it if he wants that.

I think there are like 1k or 2k MP apps. Even tho the most are not active, its hard for MP to check them all for such issues, and even then the code could be changed after verification.
A while ago I noticed that some simpledice app was changed to some bitcoindoublerscam. I told that to the MP owners, and they immediately deleted the app from MP.

Actually there's another app which uses the BetterBets script. They have the same issue, but considering that they are a new site and might not know about the issue I wanted to wait until its fixed before I post about it. Actually I wasnt sure yet if I will post it at all. But it seems to be fair to let the people know about this. I should probably have mentioned them as well instead of waiting.

However I'm not sure if all apps are provably fair. But the ones I was looking at, didnt have a limitation for the seeds at all. I just didnt want to advertise any sites here, because I'm just not related to and it also doesnt fit to the topic basically.

Your information is very meaningful to users there, I think so

I was kinda waiting for this. Actually I'm asking myself about why I am wasting time on this.
Since the point of noticing about the issue, I was wondering what to do with. I mentioned the issue in a chatroom, but either people thought I would have lost there and just cant handle the loss or they just didnt understand what I am talking about.

While I was pretty sure about it, I thought it would be better to ask somebody who has more experience with this. Maybe I really would have overseen something.
I hope it's ok to mention him but I dont see why it wouldnd. So I wrote a mail to dooglus regarding this issue, just to not do anything without being 100 % sure about it being an issue or not.
After I got confirmed about my opinion for it being not fair, I again asked me what to do.

So I came to the point, to contact the owners of BetterBets and Wealthy Dice per private message on BCT.
Told them shortly that theres an issue with the seedlimitation and asking them to change it. A few minutes later I thought it wasnt clear enough explained so I wrote a second message to both of them.

Here are my outgoing PM's to the owners of both sites:

https://i.imgur.com/6eL2pQ5.png?1

So I was expecting them to fix the issue in first place, leaving me the option to report it or not. I have had no problems with both apps so I had no intention to damage their image or anything.
I still wasnt sure if I will post about the issue at all or just leave it as it is after being fixed. The thing is that BetterBets.io is there for 1 year or something, and nobody ever seemd to have noticed it.

They are the biggest app on moneypot with a wager of over 35k bitcoins, alone since the ownerchange of Moneypot.
This are their stats:

Bets   151,692,636
Wagered   35,031,617,084.98 bits
Bets Profit   480,245,287.65 bits (1.37%)
Expected Profit   348,492,607.60 bits (0.99%)

So people obviously lost 480 bitcoins there + what was lost under the old owner.

I got answerd pretty quick from both sites. Here are their answers:

https://i.imgur.com/vl6XOoQ.png?1

Actually I was still waiting for a further message from Wealthy Dice about the issue being resolved, thats why I didnt mention them yet. But when looking at it a second time, it seems they both have the same dev.
I didnt notice that yesterday, otherwhise I would have mentioned wealthy dice as well.

Wealthy Dice is a pretty new Moneypot app, so I wanted to wait at least until its fixed in case I report it. I thought that would be fair in case they just bought the script without noticing about the issue.

So I added the BetterBets-dev on skype, wondering why he would want to speak with me. I said all I wanted and just wanted it to be fixed.
But of course gamblingsites often getting attacked by people after losing some coins there. After a couple minutes he confirmed my request to add him to my skype list like I was asked to do so.

Here's the whole conversation:

A warm welcome ... (besides the fact, I clearly did NOT ask for any kind of conversation with him ...)

https://i.imgur.com/V4Ntma3.png?1

Nonsene talk ... actually it looks a bit like he would have no clue what he is coding together there.

https://i.imgur.com/mfpo133.png?1

https://i.imgur.com/o9GGyUI.png?1

Actually until this point I was trying to relax and just end the nonsense talk as fast as possible. I did this all in a way that would probably be most preferable for a Gamblingsite, which claims to be provably fair - but simply isnt at all.
I should have just posted it straigh away at bitcointalk, so I wouldnd have to listen to that.
Getting offended while you're trying to help somebody that u dont even know, in the hope he might have just done it by an accident.

https://i.imgur.com/lSvomrM.png?1

Maybe I missunderstood this, but for me it was looking like he wanted to hide something.
My english isnt the best, but "be my guest" sounded for me like he would be trying to get this into some direction.
And it wasnt me who wanted to talk, right ?

https://i.imgur.com/f2lxBiZ.png?1

https://i.imgur.com/QnTtx4B.png?1

Leaves the question why I didnt release this straight away no ?

He actually said he had a bad day, and I got him in wrong moment.
Also he said "sorry" so even if he was a dick, I was going to accepted his sorry and thought I'd leave it like this.

I have nothing to hide, so this is all of the communication that happend.
You are free to believe my version or not, up to you.

At the end the point is the same, the site wasnt provably fair until yesterday.

So you essentially tried to blackmail him and he didn't bite.

No ethics.

Why would you even publish those logs here? They make you look like an idiot.

All in all, this limited keyspace thing isn't that damning. Props to BetterBets for resolving the issue quickly!

They dont have the same dev, Lobos is the main lead dev for betterbets and since wealthydice is using betterbets script or purchased license to use it then they rely on lobos as well for the fixed version of this flaw. There is no point for betterbets to open up wealthydice, it belongs to another subject nonetheless

This was the impression I got from the posts. Either way their system seems to rely on wagering volume so making people lose on mp side or bb side is plain stupid.

To crackpotracer no I'm not just kissing ass I've been playing on BB for a long time. I even lost a few btc on your site too but your despicable forum behavior will keep me from returning. What's even more interesting is betterbets admins told me to try your site but I see you trying to be a dick to them and everyone else on mp related sites. Don't bite the hands that feed you tool.

Op was asking for a bounty and imo it is legit

lobos asked him not to publish it! why would he do this? he or BB should publish it immediately and fix it as they did anyway

lobos behaved in a very unprofessional way

why would wealthy need to ask lobos if they have their own coder? another good question is if lobos is also the coder for wealthy?

A "bounty"? Lol. OP begged for a ransom, and BetterBets didn't play along.

Bug bounties aren't paid out to keep people quiet. That's called blackmail.

At best this is a programming error and confusion between a signed and unsigned integer. Should have never made it onto a productive system. I suspect that they have been fair and not used this to con their users - but saying that I wouldn't use the site until the matter is cleared up. Good spot - it shows that it is good to do your homework. I'm sure the devs will be happy you found it if they are legitimate.

very well said!!!

but how can one exaplin that this happens to a coder like lobos? I know everything can happen but his behavior tells otherwise or he does not like to confirm own mistakes = sad

please fix your site first before accusing fine people who only wanted to help other players and also the app owner and MP owners

yes he should get a bounty imo and it was legit to ask for it. lobos asked not to publish it and this tells a story

and if bounties are not paid to keep people quiet and it is called blackmail to use your wording why did lobos ask not to publish it? he should publish it immediately easy as that

Unfortunately, its an easy mistake to make - this kind of thing can happen when a programmer tests his own work - its always better to get external testers involved. I work with a lot of programmers and a lot of them very rarely admit to making errors even if they are very clear.

thx for explaining and imo one year or more and no one saw it and not he owners and dev? all can happen and I dont point my finger at BB or MP as all is possible

interesting would be if MP pre owner RyanHavar could tell or confirm if it was already when he owned it

Because coders are human and complex code is always never bug free. This is a subtle bug in the sense that it didn't break anything so it didn't get noticed. It's as simple as that.

Wealthy bought a license for the BB code and their site will be updated tonight.

I read about it but may I ask you if you  lobos is also the coder of wealthy? why would they need to ask you to help to fix it? their coder could fix it as I understood it was just an easy mistake

is pokerowned the owner?

thx

Who is the owner is entirely their business.

As for why would they need to ask: have you ever tried to find a subtle bug in large codebase? It's far from easy (although in this case it could have been done). And given the sensitivity of the issue, why would the not ask for confirmation on a codebase they don't know all that well ... it's the responsible thing to do IMHO.

The issue as explained by the OP of this thread was resolved before this thread was created, it was a 1 minute fix in our casino source code. The problem with a 'bug' like this is that it would have required 2 parties to coordinate and exploit if our intentions were to hurt players. They are not and never have been, this issue just limited a user to 2 billion seed combinations versus 4 billion seed combinations. I am happy that this was brought to our attention, however as pm's and chat logs were made public you can see (if you can read German) this turned into a situation where by not paying 2.5 BTC to this individual would result in a 'Betterbets not provably fair thread'.

Allinbox, I appreciate your efforts to privately inform us initially of this potential issue, because of your information we changed the allowed seed combinations from 2-4 billion possibles for our players. This potentially could have allowed bad actors on Moneypot to game the bankroll. I cannot speak for them, but in the past 10 months that my team has come to know the Moneypot team they are nothing but amazing business owners and extremely honest people. I would and have trusted them with my own funds in the past so while this client seed may have been a target for those with ill intentions, it's extremely unlikely to occur at our place of business or theirs.

This was resolved, I'm sorry for any confusion it may have caused some players.

Same thing I would probably do in other to save the reputation which is even more important than the bounty even if he asked for one. The issue is the fact that he noticed it means someone else might noticed it and instead of raising it as OP has done, the next is scam accusations but I must say I am glad the way the issue was resolved instead for allowing it drag for too long to handle...

Classy. Your site wasn't provably fair (due to an oversight), and thanks to the OPs discovery now is. But instead you are blaming "competitors" and not offering the OP at least a little bounty.


Actually, this would've allowed the casino to completely control with 100% certainty if the bet was going to be high or low. I don't believe this was ever used to cheat players and was a simple oversight (which does happen), but let's also not understate it. It was a very serious flaw.

That sucks, and will lose confidence in betting.

now this is lobos wie er leibt und lebt back to the roots  ;D

just not to answer my questions like
if you are also the coder of wealthydice or if pokerowned is the owner of wealthydice

so I ask here @all who knows if @pokerowned is wealthy app owner? the app shows wealthydice as owner but pokerowned is handling the thread as his own app.

just for info someone described the bug
"At best this is a programming error and confusion between a signed and unsigned integer. Should have never made it onto a productive system"

there is only one competitor in this thread. and yes you tried once to hurt our image you just did not succeed

you and everyone is welcome to search our site for flaws. we even invited the OP to check us out

IMO the OP was helping and not hurting you nor MP but lobos reaction and handling was unprofessional and suspicious. your mistake gave actually the option to think that MP could be involved and that means that your mistake was hurting MP owners now and before when RH was owner. IMO MP owners and pre owner would never try a cheat and kill their business

please dont forget to check our site for flaws but we need more time to fix it cause we dont have a coder right now

what we can learn is that the best way is straight forward if someone finds a bug or flaw and especially if it is a provably fair bug.

Natuerlich, had jij iets anders verwacht?  (to keep things linguistically interesting)


I am the guy who provided the codebase, set it up for them and explained how things were structured. They did the reskinning themselves and I don't know who exactly did it (and I don't really care). They change some stuff on their own but me for advice on stuff which can affect betting and some of the more complicated logic, etc.

Does it even matter? They run their site and we run ours.


I don't quite understand why you're so interested in knowing who the WD owner is. All I can say is this: I've never heard the alias "pokerowned" before but then again, I don't really follow all the stuff going on in this scene.


Correct. And it happened and it's my fault. There was no ill-will or intention to scam behind it. Software is a complex business and bugs happen.

yes sure thing as always go private on skype and talk things out in the dark instead here where it should be discussed

why did the OP ask you for a bounty? cause you did not offer one and he should get a nice bounty from BB and MP

hi lobos

thx for the visit ich habe mich sehr gefreut

not sure though if you were looking for any flaws or just stopped by to visit us today

the WD thread is here in case you didnt see it yet and it is handled by @pokerowned
https://bitcointalk.org/index.php?topic=1609876.0 (https://bitcointalk.org/index.php?topic=1609876.0)

and btw I am sure that you know who @pokerowned is or was.

I have no idea and couldn't care less. And that's the end of that.

I was trying to explain to OP that the 2^31 limit on the client seed was probably a result of the maximum value that could be stored in an integer in the language you were coding in rather than a deliberate attempt to cheat your players.

Something as simple as:


which outputs:


demonstrates the issue with ints in C for example.

You remember C? It was invented around the time I was wearing diapers but you were already wearing big-boy pull-up pants.

does anyone know if this was the case? if yes that would sound actually good for the BB dev lobos and all involved parties if I understand dooglus explanation it would have been just a code language limitation

Before this there was actually a similar issue that was indeed a server-side limit (I assume just MySQL INT limit), I mentioned this more than a year ago:


If I remember correctly they did fix that limit quickly so it allowed all client seeds (by manually changing.)

By that time clientseeds weren't generated in browser every bet (which was also part of my feedback):


So I assume they added that "automatic clientseed generation" after that (which is good) but unfortunately had this bug in it to not calculate in the full range (like RHavar mentions earlier (https://bitcointalk.org/index.php?topic=1634315.msg16436664#msg16436664) in this topic.) TBH it is pretty silly to make the same mistake twice, but yeh mistakes happen I guess. Too bad I didn't really check that myself anymore by that time too (:




But anyway, is fixed now and since it would require basically both MP as BB to cheat (based on bet patterns), I don't think that's likely at all and probably just an oversight indeed.

finally the right people are entering this discussion at least for me (dooglus & NLNico)

lets see if I understood what you explained. are you saying that this happened before with BB and you found it out? I understood they fixed/corrected it in those times. and then it appeared again just out of the blue?
I am asking because you said it is pretty silly to make the same mistake twice. but how can that happen again after it was fixed? I am not a coder and will not be in this life :)

let me also emphasize again that I never thought that RH or new MP owners would use this to their advantage. yes they could but it would kill their business in a second imo they are not stupid and not thieves. so there is no reason to attack me again as always (not that I am afraid of any attacks)

we love BTC and the Provably Fair option (& casino) and want to learn and understand and if people have patience we will understand (not many out there)

thx to NLNico & dooglus for chiming in

It were 2 different mistakes, but same problem. One was server-side and one was client-side (that "re-generate button".) I noticed the server-side one which was quickly fixed, but the client-side problem was still there (and now fixed.) I am not sure if I simply didn't notice it or if it was "added" after that. Also the lack of getting a new clientseed after each bet seemed more serious to me....



So yeh.. I noticed that the site actually still doesn't generate a new clientseed after each bet right now :\ I am a bit surprised about that because I thought this would be fixed already after 1+ year. This still allows MP in theory to cheat. If I pick my client seed, for example "1,523,456,648" and make 10 low bets, MP can just give results between 602,552,164 - 2,771,510,647 and it would be a high result. Of course this would also allow a player to cheat if he tricks MP and makes a high bet instead of the "expected low bet". So it is not likely at all that casinos (in this case MP) cheat in situations like this ("based on previous plays".) Still it is a flaw in the implementation and should be fixed.



^ seems like I have to ask for this every 7 months :X

I actually just removed BB from my site now too (probably should have done that much earlier.) It's so easy to fix their provably fair implementation but I feel pretty much ignored. Sure, I still don't think AT ALL that MP cheats nor that BB is doing this on purpose. I understand it's hard to prioritize when most players don't really care (or understand those details.) But it should be our goals to have the best provably fair implementation as possible.

RHavar already gave a solution for in back in July 2015: https://bitcointalk.org/index.php?topic=1065847.msg12018096#msg12018096 The easiest solution is just calling that "new clientseed" function after each bet, takes literally 1 minute to implement.

Nice digging up there NLNico  ;D



Yeah, although I think step b) and c) are also very important. It's good for BB, as they can be sure their customers aren't getting cheated, and it's good for MP because it removes the ability for them to cheat so there's no doubt in anyone's mind. And I doubt it'd take more than 10 minutes, so it's pretty good bang-for-buck. One of the features I was planning on adding on MP but never got around to, was a "cheating" mode, where the server would attempt to cheat (e.g. give results that were not provably fair, try predict, use "bet stalling" ) and then I could test sites with server-cheating-mode enabled, and if the server was able to cheat without the site giving a warning (e.g. alert("We got a bet result that wasn't provably fair?!")   ) the site wouldn't be "certified" as provably fair.

Hmm, we had that fixed at some point but it seems that code got lost during one of the bigger code merges I did. I'll fix all of this tonight.

My most humble apologies.

OK, the client seed randomization error has been fixed. The way it works now is like this:

1) The client seed is regenerated using the code from Rhavar's gist after every roll.
2) In the event that a server error is reported, the code returns *before* reaching the client seed regeneration statement, leaving the client seed unchanged.

This also means that the "enter your favorite client seed" functionality is no longer applicable; this input field has been removed.

In closing, I would like to say the following:

1) Yes, I messed up. I had numerous personal issues over the past months (cancer case in the family, daughter catching sever pneunomia, etc.) and as a result work was not really on my mind.
2) While we have had these issues, I would like to state that no bet has ever been tampered with intentionally on our side and I'm 99.99999% (basically 100%) certain that this is also the case on the Moneypot side. So while the implementation was lacking, there never was any fraudulent activity which exploited the potential this issue offered.

My apologies for dropping the ball, it will not happen again.

interesting change of mindset! wonder why?

@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 :)

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.  :-\  >:(

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

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.

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

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

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.

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

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  ;D

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 (https://bitcointalk.org/index.php?topic=1634315.msg16465071#msg16465071).) 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 :P 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 (https://gist.github.com/RHavar/a6511dea4d4c41aeb1eb) (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 :P



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 (https://www.moneypot.com/bets/532053521) 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 (https://dicesites.com/betterbets/verifier?ss=956ab8f5eefd0f37ffbd6a760f7a3955&ssh=877C7B71EE03657F7C6D29560D56F9C7D3BA26A64505BE460539B24D9B28632A&sr=-304087659&cr=335767772).







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 :( :D

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

WOW Nico

A hell of a job

APPLAUSE CLAP CLAP CLAP

I copied it for our next coder :)

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.

Looks like a good improvement but still some things:



Yeh, you shouldn't do that :P 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 :P

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:

https://i.imgur.com/0hHRrzq.png

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 :P
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 :)

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

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)


 

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.

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.

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

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.