pm sent
I've checked your stats and everything seems to be in good order. You have placed 24 bets on our site, all of which were properly accounted for. I can find nothing wrong with the way our site works, your balance was properly tracked through every bet. You ended with a balance 5 Satoshi higher than when you started. |
|
|
|
There's something wrong with dice. No matter how much profit I made, the balance doesn't go up.
Thank you
We have tested things extensively over the past few days and everything checks out. If you still believe this to be an issue, send me your username in a PM and I'll take a look. |
|
|
|
Nice update. I am not sure if you updated the provably fair implementation now or already before, but I just had a proper look again. The implementation looks now very close to perfect  I happily activated your site on my site again. There are still some smaller things that could be fixed: 1. Changing the client seed manually doesn't actually work (but "generate new" button does work.) So needs some change event listener that puts the new clientseed in the JS var and localstorage. Thank you, will fix ... 2. Ideally the function verifyRoll() will also check the HASH which is the first part of verifying a result. So something like this: if (activeCoin == 'btc') {
if (sha256(vSecret+'|'+vSalt) != vServerSeed) alert('Oh noes - serverseed hash changed! Contact site owner to see what happened or manually verify your bet.');
return (Math.floor((100 / Math.pow(2, 32) * ((vSecret + vClientSeed) % Math.pow(2, 32))) * 100) / 100).toFixed(2);
}
Obviously that alert should never happen though Will also add (thank you!) 3. If you use the above code, you would be checking the hash that you got after the bet. But you should check the hash that you saved before the bet (just for the theoretical situation where MP tries to cheat by changing the hash too.) You put this serverseed(=hash) already in the box with insertProvablyFairHtml() before the bet. So you can simply remove the following line from updateProvablyFairHtml() to ensure you verify the hash that you got before the bet: // $('#newBetServerSeed').html(response['serverSeed']).hide().fadeIn(delay);Will also fix ... 4. It says "Next Bet" in the second box, but that is actually the "Previous bet"  Silly me :-) Still I believe your provably fair implementation is now superior to almost all "per-roll implementations", so these are just smaller things that should be easy to fix That is high praise coming from you, appreciate it. I'll fix the above issues sometime today; very much appreciate your feedback. PS, I only tested Dice-BTC. Perhaps I can look at Plinko and NXT some other time if you want.
Plinko isn't implemented in the verifier yet because it uses a different algorithm to determine the final slot the ball falls into (it still uses the hash/seed and everything else, but it doesn't just compute it down to a single number using a single-calculation algorithm). I just didn't get around to implementing this. NXT uses a different system to compute the roll result (taken from primedice) but now that you mention it, we could actually unify the logic for both coins, there's no real reason to have 2 algorithms in place. I will work on unifying the code so that both/all coins are treated identically. Once again, thanks a lot for your feedback. I'll let you know when these changes are done. |
|
|
|
Site updates: auto client seed is now a full range as moneypot outcome range
now we all know and also NotTardy that this is fixed. this is my view and I am still waiting that someone can answer my question if tardy changed to 5/25 and wagered 10 sat and then back to 6/49 to wager max or near max during his sessions we Jackptracer didnt fix anything and tardy proved already that he wagered with much lower amount at our app/game (strange) if tardy comes back and looses 75+ coins he proved himself as a legit gambler imo if tardy comes back and wagers low amounts imo it smells not good if tardy will not come again imo it stinks Stop with the speculation JPR. You're an app owner. While you hold grudges with other app owners, it does not give you the right to try and throw other people under the bus and/or stir up trouble. Please stop. please explain why you are saying I try to throw people under the bus who are those people I try to throw under the bus? I just gave my view and speculation what is wrong with it? cause I do it? I am not allowed and other users are allowed? As an app owner, people give your comments a bit more credence. Wild speculation like the comments you have provided are detrimental to other app owners and Moneypot, just as many of your past comments have been detrimental to the team. If you wish to continue, you will be asked to leave. I have taken so much heat sticking up for you and your right as an app owner and you continually spit in my face. I am done. Last warning. let me understand what last warning means? you will throw us out and close our app? that what yahoo asked for? Can't we all just get along and be professional about things without throwing wild accusations into the wind? |
|
|
|
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. |
|
|
|
I also thought the same about this why using moneypot, only a few people know how it works
Only a few people know how MoneyPot works!  Okay, let's say 5ato5hi8itcoin are one of the money pot users and he knows anything about the money pot and the another are the people are never or not know about the money pot. this is a great joke.  Parse error ... |
|
|
|
BetterBets, what is going on?
A week or so back you were accused of not allowing users to take advantage of the full client seed range that moneypot offers.
Today, I visit your site and I realized i can't even set the client seed anymore. When hitting save, it does nothing. Its a hoax. The client seed does not update, it uses your "next random" seed. You don't even allow the user to disable seed randomization anymore. WTF, you don't even update the client seed in the input, it requires a full browser refresh to view the next client seed. You physically can only hit the my account tab once. I thought this may have been a browser issue, but I tested in both FireFox and Chrome and was presented with the same result.
Why is that? Is it because your first attempt to forfeit the rights of the player in your "provably fair" system was discovered? I pity your website. You are a disgrace to your users. What is so hard by allowing users to set seeds in the full range? All of the major dice sites do it and if you ever even want to be a player you need to get with the program.
Its no wonder Moneypot is sputtering, its crappy app owners like yourself that bring them a bad name.
There are many gamblers who play there and a lot of games are quite popular on the moneypot so i don't believe it in your words "Not Provably Fair AGAIN" easy if they are not probably fair why they are growing fast. Because we're a decent, honest gambling site who have offered lots of innovative promotions over the past 18 months and because, despite our flaws, we're nice guys. Until I am shown otherwise, I believe the issue this thread refers to has already been fixed. I asked the guy who started this thread, to tell me exactly what he's doing so I can (maybe) reproduce it. I tested the stuff he reported and as far as I can tell it has been fixed as of a few days ago. Either he enables me to reproduce his problem or he should stop beating a dead horse. |
|
|
|
I also thought the same about this why using moneypot, only a few people know how it works
Only a few people know how MoneyPot works! I quite honestly have no idea what the original poster (5ato5hi8itcoin) was trying to say ... |
|
|
|
Since your server is making the generation of the random it makes it no different than a static seed. You should offer the ability for both. Some people have lucky numbers. And your code still does not work. My account cannot be expanded unless you reload. Seed won't save. I suggest if this is not by design that you do some compatibility checking
It would be appreciated if you would not throw out baseless claims. As others have said, the client seed it is generated on the client, as it should be Some people have lucky numbers.
I really doubt that but lets for the time being assume that some people believe to have lucky numbers. Even so, (NLNico explained this quite nicely) keeping the client seed constant is opening up a potential cheating avenue for the processing server, so I don't think this is a good idea. Seed won't save.
I just tried it again. Seed saves perfectly fine and is used on the next roll. Once the next bet is placed, the seed field in the user account panel updates to display the new/current seed. My account cannot be expanded unless you reload.
I just tried it and it works perfectly fine, several times in a row. However, it's being pushed below the provably fair info which I will admit is not the smartest thing to do. I'll fix that, hopefully today. So far everything you have said it blatantly false. Please go play somewhere else. What browser are you using? does not work in Chrome I use Chrome, which is our recommended browser. Tell me exactly step by step what you're doing. |
|
|
|
'csNext' is not returned, it is a parameter in the request They generate that clientseed randomly in the browser with the RNG you provided.. so that is fine. The problem is that they are sending it to the server already before getting the next serverseed hash (which is my first point in my last post in that previous thread  ) The reason we do this is that it allows us to verify client seed integrity against the user profile. The next server seed is not sent to Moneypot, so they don't know it. However, for the client seed this probably doesn't matter, so it's probably best to disable this feature. |
|
|
|
Since your server is making the generation of the random it makes it no different than a static seed. You should offer the ability for both. Some people have lucky numbers. And your code still does not work. My account cannot be expanded unless you reload. Seed won't save. I suggest if this is not by design that you do some compatibility checking
It would be appreciated if you would not throw out baseless claims. As others have said, the client seed it is generated on the client, as it should be Some people have lucky numbers.
I really doubt that but lets for the time being assume that some people believe to have lucky numbers. Even so, (NLNico explained this quite nicely) keeping the client seed constant is opening up a potential cheating avenue for the processing server, so I don't think this is a good idea. Seed won't save.
I just tried it again. Seed saves perfectly fine and is used on the next roll. Once the next bet is placed, the seed field in the user account panel updates to display the new/current seed. My account cannot be expanded unless you reload.
I just tried it and it works perfectly fine, several times in a row. However, it's being pushed below the provably fair info which I will admit is not the smartest thing to do. I'll fix that, hopefully today. So far everything you have said it blatantly false. Please go play somewhere else. |
|
|
|
BetterBets, what is going on?
A week or so back you were accused of not allowing users to take advantage of the full client seed range that moneypot offers.
Today, I visit your site and I realized i can't even set the client seed anymore. When hitting save, it does nothing. Its a hoax. The client seed does not update, it uses your "next random" seed. You don't even allow the user to disable seed randomization anymore. WTF, you don't even update the client seed in the input, it requires a full browser refresh to view the next client seed. You physically can only hit the my account tab once. I thought this may have been a browser issue, but I tested in both FireFox and Chrome and was presented with the same result.
Why is that? Is it because your first attempt to forfeit the rights of the player in your "provably fair" system was discovered? I pity your website. You are a disgrace to your users. What is so hard by allowing users to set seeds in the full range? All of the major dice sites do it and if you ever even want to be a player you need to get with the program.
Its no wonder Moneypot is sputtering, its crappy app owners like yourself that bring them a bad name.
If you would have read the previous thread, you would have noticed that our revamp of the provably fair system was mostly done but not quite complete yet. It will be completed by next Monday ... Also, did you ensure to press Ctrl-Reload to force your browser to force your browser to load the latest version of the altered javascript files? I just tested this and it seems to work OK. You don't even allow the user to disable seed randomization anymore.
According to everybody, disabling client seed randomization is a bad idea since it makes things predictable for the party processing the bet. EDIT: To make sure everybody got the lates update, I disabled the cloudflare cache for now. |
|
|
|
Decided to wager a bit here to see if I have any chance in October competition but I had a warning of "serverseed mismatch" as soon as I logged in ( and I wasn't botting before as pop up warned me). Ignored it and started sitebot but I 'm frequently having my bet interrupted by this pop up:  If I click OK on it bot restarts. Any clue on what is it about? Also noticed these new informations displayed on the right and guess they are related to the new provably fair sistem implementations: am I right or something weird is going on with my account?  I think this is a timing issue in the update code; I'll fix it tonight. For now, I've removed this popup. Reload the page and you're good to go. I'll update the thread once I've worked around this. |
|
|
|
Looks like a good improvement but still some things: 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. 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: If I make 10 low bets and my next clientseed will be "1,523,456,648" - 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. 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. I've added a box on the side where upon placement of the bet, the locally available info (client seed + server seed) are displayed right away. 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. Using this info, the system then re-calculates the bet result (on the client using a JS function) and displays this as "Verified result". 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. Done. Player can set client seed and then the previously discussed local client seed generation resumes. 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. 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. I had this too. I am guessing that loading the demo site makes an empty serverseed (which isn't null). I would probably change: if (_serverSeed === null) {
localStorage.setItem("serverSeed", serverSeed);
} else if (serverSeed != _serverSeed) {
alert ('ServerSeed mismatch detected! If you previously used a bot to do API betting, you can ignore this error. Otherwise please report this to our staff');
}to: if (serverSeed !== null && serverSeed != '') {
if (_serverSeed === null || _serverSeed == '') {
localStorage.setItem("serverSeed", serverSeed);
} else if (serverSeed != _serverSeed) {
alert ('ServerSeed mismatch detected! If you previously used a bot to do API betting, you can ignore this error. Otherwise please report this to our staff');
}
}Almost there 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. |
|
|
|
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. 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.)
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. 2. Initial site loading - get clientseedCheck 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. 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. 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.
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. 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.
Done. Player can set client seed and then the previously discussed local client seed generation resumes. 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.
Done, see info from point #3. 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.
Done, see info from point #2. 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.
Done. See info from point #2. 8. Make it easy for players to verify the bets on a third-party verifierThere 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 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). 000. Small things
Some smaller things: you should just delete the "Client Seed Sequence" reference now, it's only confusing and never used.
Done. 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. 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. |
|
|
|
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. 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 |
|
|
|
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. 3) IMO, you should generate a random client seed before every bet in the browser. If a player bets with the same client seed every time, in theory MoneyPot could give "next server seeds" based on their betting pattern. So if a player is betting high every time, they would give low numbers based on the same repeated client seed. I am not accusing MoneyPot of this AT ALL, RHavar seems a trustworthy person to me, but provably fair is all about not needing to trust the site owner. ^ 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. 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. |
|
|
|
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. 3) IMO, you should generate a random client seed before every bet in the browser. If a player bets with the same client seed every time, in theory MoneyPot could give "next server seeds" based on their betting pattern. So if a player is betting high every time, they would give low numbers based on the same repeated client seed. I am not accusing MoneyPot of this AT ALL, RHavar seems a trustworthy person to me, but provably fair is all about not needing to trust the site owner. ^ 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. 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. |
|
|
|
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. |
|
|
|
now this is lobos wie er leibt und lebt back to the roots  Natuerlich, had jij iets anders verwacht? (to keep things linguistically interesting) just not to answer my questions like
if you are also the coder of wealthydice or if pokerowned is the owner of wealthydice
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. 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.
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. 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"
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. |
|
|
|
|
Show Posts
