'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 clientseed is generated randomly in the browser - not on the server. Having a static seed at a "per roll implementation" is not provably fair (imo) and allows the gambling site to cheat. Being provably fair should be more important than fulfilling someone's superstition IMO.

In theory a combination is possible, when using a hash of chosen static clientseed + a nonce. Fixing the provably fair implementation should be the priority though. If this extra feature is really a big demand from players, they can always add this later.



PS, I agree the provably fair implementation is not yet perfect, as noted in my last post in the previous thread. But it seems clear to me that the dev is working on it.

Actively cheating players without them knowing why/how much/when/etc? No, sounds like a bad idea. There is no way for you to prove you will keep a 1% HE. You could let a big real player lose any bet and let your "house players" win their profit (and claim it's fair because other players won.) It seems just like a bad idea imo.





However, if you give a hash with the outcome before each bet.. then it could be interesting. Basically you would not let players pick a clientseed. So this way, you could cheat them by predicting their next bets (and give hashes based on that.) Players could also abuse this, by trying to trick (and/or learn) your algorithm/patterns.

So players will be able to verify if the outcome is really the hash that you gave before they made their bet. But you could still increase your odds by predicting how they bet. Meanwhile the player could also increase their odds by trying to predict how you predict their betting.

I don't think it's really a smart idea either tbh. But it is interesting

Looks like a good improvement but still some things:



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

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




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

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


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

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



Very nice

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

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

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

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

Personally I would do something like this:



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


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








Almost there

Technically this isn't correct. Bitcoin transaction can be seen almost instantly, but can be reversed within ~10 minutes after it. Visa transactions can be seen almost instantly, but can be reversed within several months after it.

You could argue that making a double spend is easier than having a stolen/fake visa and I would agree. But then again, it's all about target usage + risk/reward. For an online order with real delivery, knowing 100% sure in 10-20 minutes is probably still better than knowing (let's say) 99% in 0 minutes (but still 99% after a week.) You won't deliver the product in 10 minutes anyway.

For some use-cases, like buying an expensive item in a real-life store (where you don't want to wait 1 min - 2 hours for confirmation), perhaps bitcoin isn't the ideal payment system. That's okay, you don't need to use bitcoin for everything.


That is true. Most likely there will be layer 2 solutions like Lightning Network that will allow accepting instant-transactions with much more confidence.

Well the blockchain does refer to the most secure one, so yes, the bitcoin blockchain

TBH I think theories/techniques of guessing the risk of 0-confirmed transaction are interesting too, so I am sorry to make such an obvious statement

But in reality (one of?) the biggest problem(s) bitcoin organically solved is the double-spend problem and the solution is really the blockchain.




Of course if anyone wants to accept 0-conf TXs based on risk/reward.. that's up to them. For gambling sites I know plenty of sites have been scammed and changed it to 1-conf, so only few sites accept 0-conf (to be fair, for example Luckybit has a pretty good record on that though.)

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

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

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



Provably Fair on a MP app

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ideally you will verify each bet in the browser.

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

You guys do this



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

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







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

Several dice sites do list this. Especially sites that accept investments (crowdfunded bankrolls.)

SatoshiDice
18e5jpfn9zo9GQov1Ks9Pzh6Yam2SvFqqo - 1,121 BTC
1DmqFgYfKMT1F8B3tGhVMFf82vdgdSsjNV - 1,580 BTC

BitDice
146syqE3vnfQp4VauBRUnUuAgvxMoitxcK - 1,500 BTC
1P8yKwe4LMRfy1kCBgC97w6Z3D3cNLYbxg - 554 BTC

MoneyPot
37Ymp6HJLMVnxvhdFFH9C2jpRcB7LTmZPc - 810 BTC

Crypto-Games.net
1Lfb39v37yRCK4HzWcPkDzTGFG8eebCUF7 - 613 BTC

SafeDice
1SD1ciWyeDNf26YoAUjSsifQZK1ShFJ2s - 129 BTC

Some of those are tracked on my site https://dicesites.com too (I will still improve this feature soon-ish.)

Private owned sites generally don't make this public.

Although those public addresses can show proof of solvency (should be in combination with account balances), the disadvantage is privacy. Especially with companies like Coinbase who are trying hard to block funds from gambling sites and freeze related accounts, public addresses can be a problem.

BetKing for example (with 5.6k BTC invested), doesn't make their addresses public anymore because of it. Owner still wants to have private audits from time to time (last from Dooglus.) I might make a script to daily verify those private addresses/signed messages and put the amount/percentage on my site (but it's still not as perfect as public since you still have to trust me to do that fair )

There is a solution for the double spend problem, it's called the blockchain.

Yikes. 100+ BTC on Blockchain.info wallet? I don't know if https://www.buytrezor.com delivers to your country, but a hardware wallet will be much(!) more secure. Highly recommended to look into that!

I Think Your Usage Of Capitals Is Pretty Annoying.



It can be profitable, but you are correct that it is very risky. You have to do your research well and make good judgments into which sites you will invest. And even if the owner is trusted/fair you might lose simply because of variance and winning players. That being said, personally I have made decent profits by investing last few years.

I got some total profit charts: https://dicesites.com/graphs

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.

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

Ah okay, logging out + back in (w/ 2FA) works fine for me. So not sure what the issue is then.

Does this work for you GB?

There has been few topics about it. My personal conclusion is that people don't really care indeed:


People mostly just want a fun experience (which is fine because that is what gambling is about.)

There are plenty of people playing on those sketchy non-provably fair non-transparent "bitcoin slots" which generally have a 5+% HE. Meanwhile there are plenty of dice (and other) sites offering 1% (and lower) HE which seems like a much better deal. But yeh, if you enjoy playing slots.. you might still prefer those high HE slots.

If you want to risk your money by playing on a site, you do want to get the idea that the site is trusted. Looking at how much other people have wagered and how long the site has been around - definitely can help for getting an idea about that. That's why I do think those statistics are important for (some) players.

My site https://dicesites.com is indeed all about those statistics. A lot of other review/overview sites just give good reviews to any casino that pays them nicely or has a good affiliate program. However my site shows only statistics and let the player decide which site is good and looks trustworthy for them.

On the subject of "faking stats", I obviously take that very serious. And for me, there has been 2 clear cases of "faking stats": FortuneJack and BetBTC.co dice (both 2 links link to more detials.) I might make a blog 1 time about those 2 sites faking stats (with more proof btw.)

It is possible that other sites fake stats too, but I try my best to figure that out. In a way I think crowdfunded casinos are less likely to fake bets, because they would be not only faking stats - but directly stealing from their investors (which is much worse so owner would need even worse ethics.)



PS: I will also update my site this month to be much better for players and have more sites

Exit scam?

Seriously though, I like to think optimistic, maybe this is just a regular bitcoin-node problem and the 102 BTC winner will still be paid. But it is looking worse and worse Their silence doesn't help either. Obviously no one should play/deposit till that high-roller issue is resolved.

Ps, you should probably change the title to emphasize this is about pocketdice.io.

The 0% HE on bitcoinbetting.website seems temporary. I am not sure what to think about that site because they first had a 50% HE and took a long while to fix that. Besides that I am also annoyed they keep spamming comments on reddit on irrelevant topics (example.) Looks sketchy to me, but you could try it with small amounts.

That being said, I don't know any other gambling site that currently offers 0% HE betting.

edit: actually in theory https://www.bustabit.com could be 0% HE if you play good. Although historically there has been a 0.3% HE (which is still low.)