Topic: Primedice.com | Since 2013 | Longest Running Crypto Casino | 113 BTC Jackpot! - page 1281. (Read 1989585 times)

That doesn't sound too bad the alternative coin
Would be most likely like play money, but still something to think about

stunna you should make your own coin just for gambling

and add it to your site!!

I will make this situation right as I've stated before, I stand by my word (although I'm very vulnerable to delaying things). I've already paid out one coin and am 100% open to any suggestions on what to do for the remainder. It obviously won't be easy to track down people who may have placed that particular bet so one alternative that was suggested to me was to just get the average bet * bets effected and distribute it somehow or donate it.

It would be hypocritical of me not to make this situation right after I attacked prc for the sjess issue.

Yea as I expected, very impressive. I do wonder what dice websites would do if you weren't around to point out their flaws.

I didn't notice your PM, sorry. I'll take a look.

Did you see I mentioned that the 37.5k number is the expected number of rolls that were incorrectly paid out as losers when they should have won if the house edge was 1% as advertised? I mentioned it 3 times in my post.

I also said "it could be more or less"...

Of course reality can be very different than expectation, but it could be off in either direction. It could be that many *more* than 37.5k bets were affected - I can't know the actual number. I can just be really sure that it isn't NINE, as Stunna claimed here.

Edit: QFT

Thank you for keeping an eye on the betting verification process dooglus, you are doing God's work.

I sent u a pm regarding that , but u didn't reply .

That 37k number is somewhat estimate but it can be so far from true.

Same as 1% house edge even in long run might not be even close to that, as i think it was the case with jd ?
On jd house got only like 0.3% profit right ?

No, we didn't have any such issues.

I once forgot to manually debit a player's account after he requested a withdrawal that was too large for automatic processing, so he got a 1300 BTC freeroll which I later rolled back.

Other than that we had various DoS issues which I wasn't prepared for.

We did pretty extensive testing of the site before launch, including an open public test using testnet coins.

But I'm kind of OCD and have an eye for details. I coded the whole thing myself. It seems that with both the PD and PRC issues the root cause of the trouble is trusting third parties to be competent. They often aren't.


That's an odd argument. JD invented crowd-sourced gambling as far as I know. It changed from a state of non-existence to a fully working site. I wrote it from scratch. If you expect issues, why not run it with testnet coins until the issues are resolved?

I read one site recently (I forget which) saying something like "there are probably lots of exploitable bugs in our code so we don't keep much in the hot wallet". That seems crazy to me. Why not audit your code so you can be reasonably confident that it's not exploitable rather than just assuming you're going to get ripped off?

Stunna's idea is awesome. Not sure if it'll make much of a difference to win/loss ratio but receiving a bit back for large wagers would be nice.

However, I doubt a bonus could be implemented since hoards of bonus whores would try abuse the system by rolling extremely low odds. There would have to be some sort of odds restriction. Then there's the fact no one will want to have btc locked to an account because they decided to try for the bonus. Although the last bit could be easily remedied by releasing the bonus in small portions. Either way I doubt stunna would go for it

I think you still misunderstand the situation.

The house edge was over 50% for some bets, and all kinds of values lower than that for all kinds of other bets.

Look at the 0.5% bet, for instance.

On PD2 you had to get a "raw" roll of 99.505 or higher to win. That's a 0.495% chance of winning, or 0.005% lower than advertised (as all bets were).

That results in a house edge of 1.99%, almost twice the advertised edge.

Here are some more examples, showing various actual house edge numbers from 50.5% down to 1.0055%. No bet actually had the advertised 1% edge:


Since 750 million bets were made with this flaw, and the flaw is expected to have affected 0.005% of all bets, that means an expected 37,500 bets were affected by the problem.

I'm glad to hear that you've compensated one of the [edit: expected - it could be more or less] 37,500 victims.

Yea but JD was also made from scatch, so I'm wondering if he had any issues since launch.

Well jd did not change much.

PD3 is made from scratch , so yeah i expected some issues at the start.

I'm curious Dooglus, out of the 1 year you ran JD did you run into any problems like all of these other websites are having, such as provably fair, something similar to that prc incident etc?

That's a reasonable argument.

The site is indeed provably fair, and he did get a fair roll. The documentation is wrong about just how that fair roll happens, and indeed the methods (for there are 2 - one in words and one in code and they're different) described in the documentation both would lead to unfair rolls if they were actually how things were done.

So all that needs to happen is for the documentation to be fixed and everything's fine.

Actually i think it was 1.005% ?

What is more important than the method of fairness or any algorithm is the fact that the roll was fair and the user got the exact win odds expected to win the bet which he did indeed.

I personally feel that your point about the "difference' causing him to lose is invalid, would he have adjusted his client seed etc knowing that the system used was different? This only seems to be important after the fact given that he lost.

I'm doing my best to provide a fair experience, I'm also working on code so I can be less reliant on developers to solve these sorts of issues. At the end of the day though his roll was fair and unmanipulated.


Also coinfist is a shill for another casino: https://bitcointalksearch.org/user/coinfist-365873  (Notice all his posts are him screaming that PD is a scam in all caps) I'm not refunding him 0.01 which he lost placing a 100% fair bet. He literally created his forum account to simply type anti PD posts. Instead of proving that the verification section text  was incorrect you should instead try and prove that he did not get a 100% fair bet.


Also with regards to the 37,500 bet situation, I've already compensated the guy who should have won the 9900x payout 1 coin and will see if it is possible to run some sort of query for anyone who made this bet. In this situation the site was documented 100% correctly, just the house edge was advertised as 1% not 1.01% on old PD incorrectly.


Primedice is 100% fair but our verification page text has mistakes on it and is inaccurate end of discussion. We will edit this page today (hopefully without error this time)

Tnx for explanation dooglus.

Well, I think it has been changed, but not enough, and the changes that were made were wrong.

Have there been any developments re. looking into the estimated 37500 bets on PD2 that were settled incorrectly?


The last I saw you say about it was that you would be talking to the developers, but maybe I missed a post:

I don't know if it's that clear cut. If you launch a site with the documentation saying "we are provably fair because we do A, B, C to generate your rolls" but what you actually do is "A, B, D", then when the outcome of A, B, C and A, B, D differ, such that the player would have won if you did what you said you were going to do, but he loses because you actually do something different... then it seems like he has a winnable case there.

He took you at your word that you were doing A, B, C but it turned out you weren't doing that at all, and the difference caused him to lose.


I think the code snippet was updated recently. It was just updated wrongly, making it even worse than before since now it often computes very low rolls, like the 00.02 in the case that brought the error to light.

I'm sorry for the lack of update in documentation, I was told this was updated probably about three times now but apparently it has not changed. I do not have a strong understanding of provably fair and will poke our main dev to resolve this today. RGB Key pointed out the same thing a few days ago but apparently the error was related to him using the wrong algorithm, will have our developer chime in later.