Topic: PRCDice.eu - Largest Dice invest site - Open since 2013! Chat, Play, Invest! - page 65. (Read 89229 times)

People tell me my distrust of Microsoft is misplaced. Maybe that's the case.

But for anyone who shares my impression that Microsoft's security leaves something to be desired, it turns out that PRCdice is written in .NET, which I guess means it runs on an MS system.

I wouldn't trust my coins on a Windows machine, and wouldn't recommend others do so either.

But maybe I'm just jaded by years being forced to run Windows at various jobs whereas in fact Microsoft do in fact produce stable secure software after all.

Yes.

That's exactly how I found the issue (binning by roll/10):

It scares me that apparently Dean didn't even verify that his rolls were evenly distributed.  Generating rolls with the flawed algorithm and just binning by integer should reveal the flawed distribution pretty quickly wouldn't it?

I'm not sure it's accurate to say they were cheated ~5% of the time they bet lo. Because maybe they still won some of those bets. But they will have lost more bets than they should have if they played much, yes.

I played a bit, both for BTC and for DOGE, and always roll 'hi'. I ended up with a small profit both times.

That could look suspicious - I know how to read code, I admit to having read the code before I played, and then I only ever bet 'hi'.

How is Dean meant to decide which players were taking unfair advantage of the system deliberately, and which were doing it unwittingly?

The coding was doing exactly what the text description said it would do.

I looked through it myself when I first heard about PRCdice and noticed that they were doing it differently than JD.

I wondered why, and thought it wasn't necessary, because even taking the hash 5 characters at a time there's an incredibly tiny chance that you will ever run out of the 128 character sha-512 hash.

But it didn't occur to me to go further and consider what re-using known "too high" characters would do to the distribution. And I'm kind of kicking myself for that. It was pretty obvious, but I missed it.

Anyone betting "low" was getting worse odds than advertised, whether they were betting "less than 50" or any other chance.

It could be argued that the ones whose number was determined by just the first 5 characters of the sha-512 hash got a fair roll, and the rest (which will be around 4.6% of all "lo" bets) weren't fair.

>>> 100*(1 - 1e6/16**5)
4.632568359375

If the flaw was with the coding/or wasnt looked at. Then I guess sjess should be paid.
If it is decided that bets will be rolled back. Then people who lost money should be paid back.
As if they were betting under 50. then odds were less from what was promised.

For those who care about the details of the "issue" at PRCdice:

https://prcdice.eu/home/provablyfair says:


So it looks at the first 5 hex characters. That gives a number between 0 and 16^5-1 = 1048575

If that number is less than 1 million, it is used as the rolled number. But if it isn't, they use characters 2 through 6.

Since the first 5 characters are 1 million or more, the new number will be at least:

>>> (1e6 - 0xF0000) * 16
271360

so (1000000/1048575) = 95.4% of the time, the rolled number will be randomly distributed between 0 and 100, but the remaining 4.6% of the time it will be guaranteed to be over 27.136.

So playing "over 27.14%" is a winning strategy.


The question is, what to do about this...


If you read the description of how provably fair numbers are generated, noticed that numbers over 27.4% come up a little more than they would if picked at random, and decided to bet on >27.4, is that cheating?

There's no bug in the coding - it does exactly what it says it does in the description on the site.

If it is cheating, which bets do you roll back? Maybe some guy figured it out, but decided to bet ">49.5" to avoid detection. Betting ">27.4" kind of suggests you know exactly what you're doing. But even then maybe some of the people doing it were just copying the big winner's strategy because it was "lucky" for him. And maybe the big winner was just copying someone else.


Wow, I'm glad I don't run a dice site!

Irrespective of any Down swings, looks like Dean is handling the site well enough. Would be great to see it grow.

thumbs up for this site

hoping that this site will have many new things!

I hadn't heard about that, but it's interesting given our recent discussion about cheating:

I am surprised that they pause betting today because some guy had a lucky streak and causes a loss of 10BTC to the casino.

thx for the leaderboard for doges dice.got me 5th place

As doog says, no system can be 100% secure and there is always a risk, Just look at the recent Heartbleed incident. Saying that there are various techniques and tools we can use to minimise this risk a lot.

I wouldn't want to detail every method and technique in here that I use or have implemented for obvious reasons.
Also as doog says when people do keep winning you sometimes question what is happening. This is a good thing I guess because it keeps you double checking and making sure things are OK.

Although doog prefers the method of having deposits fund the withdrawals of the hot wallet I think at this point that I prefer the deposit addresses be to a cold wallet and I will top up the new hot wallet as needed. 
That at least prevents any situation where someone may deposit a large amount of Bitcoin and it being instantly stolen from hot wallet before I can do anything about it.

Yeah NLNico pointed that one out too. I'll get that fixed asap.


Yeah I was in middle of actually redoing the whole site before the new wave of players. For now I think I will clean up/refactor all of the client side scripts instead before moving on to V2. 



Yes the existing bankrolls (btc and doge) are for whole site which includes dice, sports and casino games (which currently is only blackjack).
It currently can take up to 1 minute to divest because of that reason. Another solution is to have an option to state what you want to invest in: sports/casino/dice/all.


Yeah totally. It's best everyone does. Thanks.

I don't think it's ever possible to be 100% secure. It's really hard to say how lucky JD was not to get compromised during the year it ran. Running the site I got nervous every time anyone got lucky. There's always that nagging doubt "are they somehow cheating?"

Imagine running the site while nakowa was playing. He was up over 12k BTC at one point I think, and you just have to wonder what's going on.

I've not seen the code of PRC, and don't know anything about where it's hosted so it's impossible to have any idea how secure it is.

I think there's always going to be all kinds of risks associated with this kind of site, and you need to bear them in mind when deciding whether and how many coins to trust them with.

Personally I don't think I would have had many if any coins with JD if I wasn't running it myself. I've had too many bad experiences trusting people with my coins in the past.

As for leaving coins in an unencrypted wallet as bait, I think that's a good idea in general. Don't use your regular computer for your main Bitcoin wallet, but do leave a wallet with a small amount of BTC in it. If the wallet gets emptied, it's an early warning sign that you've been hacked.

Yeh I agree in theory that would be the "best" way to exploit if the attacker can have unnoticed access to the server.

Anyway, Dean is planning to make instant withdrawals this weekend (so obviously with hot wallet.) The original discussion however was that I still think it's ok to manually fill that hot wallet and use cold wallet for deposit addresses, especially with a relative smaller site because 1 deposit can be 50% of whole cold wallet. There can be many ways to exploit if you have access to the server, but still I think it's best to limit each method which would include trying to limit the hot wallet amount.

Also I do think most attackers will go for instant steal simply because they will (and should) be worried that their unauthorized access will be noticed. This however does depend on the method or vulnerability that's used (and the "experience" of the attacker.) (edit: in theory he could "instant steal" the hot wallet also with the server seed of course, only needs 1 deposit, would depend on the attacker I guess)



Of course in the end I hope the site will never be (successfully) attacked but should definitely think of all the possibilities.

Doog, I'm curious how big of a concern this should be in your opinion. (people gaining access to the server seed, etc.) Do you see any security issues with PRC? Or is it just a risk for any site of this nature? How secure did you feel just-dice was? I do recall reading some of your posts where it seemed you felt there was always a risk even on just-dice.

I think most hackers would take an instant 10-20% so that as bait might be a good idea.

What are your thoughts on this Dean?

Exactly. If I can get onto the server to steal the hot wallet, I can also steal the server seeds.

The server seeds are much more valuable, because if I'm care and don't make it too obvious I can drain the whole bankroll slowly over time.

You would be better off leaving 20% of the cold wallet on the server as "bait" for the hacker. Maybe he's dumb and takes the 20% instant payoff rather than slowly bleeding you to death.

The point Dooglus is making, is that people can just keep winning and still drain the cold wallet, it doesn't matter if the PRC processes withdraws manually.

I think you entirely missed the point I was making.

How is their withdrawal schedule in any way related to someone gaining unauthorised access to the server?