Primedice.com | Since 2013 | Longest Running Crypto Casino | 113 BTC Jackpot!

[Shogen]

Looking to maybe add a form of "Rake back" to Primedice.

This would mean if you wager a certain amount the house edge would be lowered. Here's an example:

 - User A has a total wagered 50 BTC. He then receives 0.1% of all his bets back (Win or lose) - Making house edge 0.81
 - User B wagered of 200 BTC. He then receives 0.2% of all his bets back (Win or lose) - Making house edge 0.71
 - User C had a total wagered of 1,000 BTC. He then receives 0.3% of all his bets back (Win or lose) - Making house edge 0.61

Sound good?

That sounds very good. It will make Primedice even more addicting lol.

[hilariousandco]

Also, on the affiliate dashboard it says I have 5 referred users but there are only 4 listed below that.  Explanation please?

That has happened with me as well. Says three refs but only two show up.

[icey]

Looking to maybe add a form of "Rake back" to Primedice.

This would mean if you wager a certain amount the house edge would be lowered. Here's an example:

 - User A has a total wagered 50 BTC. He then receives 0.1% of all his bets back (Win or lose) - Making house edge 0.81
 - User B wagered of 200 BTC. He then receives 0.2% of all his bets back (Win or lose) - Making house edge 0.71
 - User C had a total wagered of 1,000 BTC. He then receives 0.3% of all his bets back (Win or lose) - Making house edge 0.61

Sound good?

Sounds very good, any way in which we can lower the edge towards 0 suits us!

Out of interest, what's the biggest jackpot paid out so far?

[Stars]

Primedice is cheating

Today I was just using PD to bet and doing the double-or-nothing experiments.
It was going fine at first. But suddenly, I had 11 consecutive-losing bets.
They were pretty odd, weren't they?
So I did some verification using the script provided by Primedice.

See the screenshots below. I did verify all 11 bets. All 10 bets are correct, but the No.2 bet from top is wrong.
On the screenshot, the roll is 92.29. However, the result I got from script is 0.02.
So I should win that bet, there would not be the last one bet(top one) which cleared me out.

BET #805607190 INFO

SERVER SEED (REVEALED)
41fa224237f452360db8d35a276f4067fce6cad8d3dbf3c73bde2e804c8cb8c7
CLIENT SEED (NONCED)
ca45edd88ef251dd43edf42dc97c7ffb-3391

Screenshot of 11 consecutive-losing bets
http://prntscr.com/4ed9mo

Screenshot of BET #805607190 INFO
http://prntscr.com/4eda18

You can look up these bets by the bet id shown in the screenshot and verify them by yourself.
This did not just happen once but twice today and almost clear me out.
Since Primedice has been online for so long, I could not imagine how many times it has cheated.
I probably will do the same experiments on other bitcoin gambling web site. But Pirmedice is not trustworthy and return my bitcoin.

I also found the possible unfair when you PVP with "strangers" on Primedice.
See the post: https://bitcointalk.org/index.php?topic=733500.msg8315850#msg8315850


The script I am using:

            //the seed pair itself
            var clientSeed = "ca45edd88ef251dd43edf42dc97c7ffb"; //dont forget to exclude the dash and the nonce!
            var serverSeed = "41fa224237f452360db8d35a276f4067fce6cad8d3dbf3c73bde2e804c8cb8c7";

            //bet made with seed pair (excluding current bet)
            var nonce      = 3391;

            //crypto lib for hmac function
            var crypto = require('crypto');

            var roll = function(key, text) {

                //create HMAC using server seed as key and client seed as message
                var hash = crypto.createHmac('sha512', key).update(text).digest('hex');

                var index = 0;

                var lucky = parseInt(hash.substring(index * 5, index + 5), 16);

                //keep grabbing characters from the hash while greater than
                while (lucky >= Math.pow(10, 6)) {
                    index++;
                    lucky = parseInt(hash.substring(index * 5, index + 5), 16);

                    //if we reach the end of the hash, just default to highest number
                    if (index + 5 == 128 + 1) {
                        lucky = 99.99;
                        break;
                    }
                }

                lucky %= Math.pow(10, 4);
                lucky /= Math.pow(10, 2);

                return lucky;
            }
            console.log(roll(serverSeed, clientSeed+'-'+nonce));

Interesting.

[cHoCo]

806,462,841

define this bet

[AirFlame]

Welcome to v3.0 Cheat experiment called "if they will notice"

[jjc326]

Also, on the affiliate dashboard it says I have 5 referred users but there are only 4 listed below that.  Explanation please?

That has happened with me as well. Says three refs but only two show up.

Happy to know it's not just me. Waiting for explanation please. 

[MICRO]

Also, on the affiliate dashboard it says I have 5 referred users but there are only 4 listed below that.  Explanation please?

That has happened with me as well. Says three refs but only two show up.

Happy to know it's not just me. Waiting for explanation please. 

That's weird , probably has to do with issue i told torba to fix , like if u have more than 30 refs it won't show them all , so he will make scroll there , but for that idk what could be. But ur ref is probably there in db, so that should be an easy fix.

As for that bet , i will try to figure it out while we wait for dev or somebody else to see whats up .

[dooglus]

See the screenshots below. I did verify all 11 bets. All 10 bets are correct, but the No.2 bet from top is wrong.
On the screenshot, the roll is 92.29. However, the result I got from script is 0.02.
So I should win that bet, there would not be the last one bet(top one) which cleared me out.

This is like PRC's "sjess" problem all over again, only worse.

PD3 seems to have 3 different ways of generating rolls:

1) the way the site actually does it (use digits 1 through 5, then 6 through 10, 11 through 15, etc. until it finds a number under a million); that's the best way, and the way that JD did it.

2) the way the text on http://primedice.com/#/verify says it is done (use digits 1 through 5, then 2 through 6, 3 through 7, etc. until it finds a number under a million):

First five characters are taken from the hex string to create a roll number that is 0-1,048,575. If the roll number is over 999,999, the proccess is repeated with the next five characters skipping the first one.

That's a bad way to do it, but is how PD3 did it during beta. I told them it was bad and they fixed it, but still apparently didn't update the text.

3) the way the code snippet on http://primedice.com/#/verify shows:



The "hash.substring(index * 5, index + 5)" bit will give a very low number if the first group of 5 is over million (it's using digits 1 through 5, then just digit 6); the code should say "hash.substring(index * 5, (index + 1) * 5)" or "hash.substring(index * 5, index * 5 + 5)". It looks like another case of untested code being put on a live system.

Method 1) rolls 1025966 which is too high, then rolls 139229 which when you take the last 4 digits and put in the decimal gives a roll of 92.29 (a loss for you)

Method 2) rolls 1025966 which is too high, then rolls 686818 which when you take the last 4 digits and put in the decimal gives a roll of 68.18 (a loss for you)

Method 3) rolls 1025966 which is too high, then rolls 000002 which when you take the last 4 digits and put in the decimal gives a roll of 00.02 (a win for you)

So PD needs to decide which of the three methods they're really using, and update the other two to match it. They also need to decide what to do about all the bets whose outcomes are different in any of the three methods.

[a1choi]

I reviewed this situation and thought about it an extensive amount. I have no ill feelings towards Dean but strongly agree with Dooglus and his opinion regarding this.

The situation reminded me a bit of Phil Ivey's edge sorting (There are a few key differences though) Read here: http://regressing.deadspin.com/how-phil-ivey-beat-or-maybe-cheated-a-casino-for-mill-1562993963

^ In this situation Ivey should be paid and Borgata should sue the card company, however Borgata has a massive legal team and endless terms & conditions.

With regards to PRC, the game was played as intended, as described in the verification section and some compensation is due. I thought about what I'd do, personally If I was in Dean's shoes I'd refund Sjess in full, if it was a massive amount though I'd probably consider some sort of partial settlement.

Given that your site is just starting off and Sjess arguably should have reported this error rather than exploit it I recommend you provide Sjess a half refund at minimum.

In the end it is mainly PRC's fault for not properly testing their website I recommend they reach out to Sjess to do some pentesting rather than punish him.

Regardless I wish you luck with the site, could someday fill J-D's shoes.

so is there going to be any refunds?

[MRKLYE]

[dooglus]

This is like PRC's "sjess" problem all over again, only worse.

Interesting

OK, so it's a different situation.

At PRC dice they designed a bad provably fair algorithm that rolled 'high' too often, implemented the bad design perfectly, someone discovered it, exploited it, profited, but wasn't allowed to withdraw.

At PD here the provably fair algorithm was bad during beta, I pointed it out, they fixed it, but didn't update the documentation or the verification script. I pointed that out and they tried to fix the verification script but got that wrong.

So PRC had a bad design, correctly implemented and correctly documented.
PD had a good design, correctly implemented but poorly documented.

I expect Stunna would argue that the site is working as intended, that only the documentation is wrong, so "suck it". Except he'd use better words.

[MRKLYE]

Eloquently put Doog.

[zahra4571]

Looking to maybe add a form of "Rake back" to Primedice.

This would mean if you wager a certain amount the house edge would be lowered. Here's an example:

 - User A has a total wagered 50 BTC. He then receives 0.1% of all his bets back (Win or lose) - Making house edge 0.81
 - User B wagered of 200 BTC. He then receives 0.2% of all his bets back (Win or lose) - Making house edge 0.71
 - User C had a total wagered of 1,000 BTC. He then receives 0.3% of all his bets back (Win or lose) - Making house edge 0.61

Sound good?

Yeah it's nice, poker rooms use that and its shown good results.
Or maybe bonus for deposit what is similar to this, for example you deposit 100 BTC and your deposit bonus is 120% (120 BTC), withdrawals is in levels after wager some part of 12000 BTC what is the final wager amount to claim whole bonus.
What ever you decide it would be nice to see some bonuses like this.

[MICRO]

This is like PRC's "sjess" problem all over again, only worse.

Interesting

OK, so it's a different situation.

At PRC dice they designed a bad provably fair algorithm that rolled 'high' too often, implemented the bad design perfectly, someone discovered it, exploited it, profited, but wasn't allowed to withdraw.

At PD here the provably fair algorithm was bad during beta, I pointed it out, they fixed it, but didn't update the documentation or the verification script. I pointed that out and they tried to fix the verification script but got that wrong.

So PRC had a bad design, correctly implemented and correctly documented.
PD had a good design, correctly implemented but poorly documented.

I expect Stunna would argue that the site is working as intended, that only the documentation is wrong, so "suck it". Except he'd use better words.

If only verification documentation is wrong what it seems to be than i guess its not that bad situation ?
I think dev has that already updated but as i said he wasn't online for whole day , he shoulda pushed some other updates today also .

[Stunna]

This is like PRC's "sjess" problem all over again, only worse.

Interesting

OK, so it's a different situation.

At PRC dice they designed a bad provably fair algorithm that rolled 'high' too often, implemented the bad design perfectly, someone discovered it, exploited it, profited, but wasn't allowed to withdraw.

At PD here the provably fair algorithm was bad during beta, I pointed it out, they fixed it, but didn't update the documentation or the verification script. I pointed that out and they tried to fix the verification script but got that wrong.

So PRC had a bad design, correctly implemented and correctly documented.
PD had a good design, correctly implemented but poorly documented.

I expect Stunna would argue that the site is working as intended, that only the documentation is wrong, so "suck it". Except he'd use better words.

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.

[dooglus]

If only verification documentation is wrong what it seems to be than i guess its not that bad situation ?

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 dev has that already updated but as i said he wasn't online for whole day , he shoulda pushed some other updates today also .

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.

[dooglus]

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.

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?

It's not just >99.99 that is affected. *Every* bet is 0.005% harder to win than advertised. It's just that when the bet is advertised as 0.01%, the 0.005% error is half your advertised chance of winning, so it is hugely significant.

What this means is that on average 1 in every 20,000 bets in the history of the site was incorrectly marked as a loss instead of a win.

With 750 million bets on the site, that means that around 37500 bets were settled as losses when they should have been wins.

37500 bets assuming that every bet was made on the 10,000x multiplier.

No, you aren't understanding:

*Every* bet is 0.005% harder to win than advertised

Every bet was unfair, not only the 9,900x multiplier ones.

For example:

To win <49.5 you had to roll <49.495000 to beat the unfair rounding, and so only had a 49.495% chance of actually winning.

Similarly, to win >50.5 you had to roll >= 50.505000 to beat the unfair rounding.

Every bet on the site had a 0.005% smaller than advertised chance of winning.

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

I believe the first time I had heard of the rounding issue was after the launch of PD3 and one of our developers immediately said that was incorrect. However, I will be having a conversation with our developers and bring up the points you responded with as they do seem valid.

[MICRO]

If only verification documentation is wrong what it seems to be than i guess its not that bad situation ?

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 dev has that already updated but as i said he wasn't online for whole day , he shoulda pushed some other updates today also .

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.

Tnx for explanation dooglus.

[Stunna]

If only verification documentation is wrong what it seems to be than i guess its not that bad situation ?

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 dev has that already updated but as i said he wasn't online for whole day , he shoulda pushed some other updates today also .

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.

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://bitcointalk.org/index.php?action=profile;u=365873;sa=showPosts  (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)