Just-Dice.com : Invest in 1% House Edge Dice Game

[GOB]

FUD is growing: http://www.reddit.com/r/Bitcoin/comments/1nidbv/statisticsjustdice_scam_investigation_conclusion/

Probably the author is the one of the email who did not receive the 400BTC :-D. Not much sense in that article however.

yep it could be the one who send the ugly blackmail letter. but I dont agree with You that the article/theory doesnt make sense. it is a possible scenario imo.

+1

Yeah, it must be the blackmailer, and you are correct, the scenario he describes is not non-sensical. In fact it's entirely possible, and furthermore, from day one Dooglus himself mentioned this was a weakness and that he could not find a trustless way to implement the site. Just look at the first 25 or so pages from this thread. He addresses this.

This, btw, is why that ransom demand was so ridiculous-- he was merely threatening to make public  a theory which Dooglus made public as a possibility on day one (or day 20ish).

[wachtwoord]

Second question: As your simulation shows, there's a 10% risk that we reach 57% of initial bankroll, assuming 1/2 kelly (it's a bit of a simplification I guess, since casino bankroll is dynamic, but it doesn't matter for our purposes). Say the whale/player stops at this point. That's a possibility, right? We could specify, ahead of time, "player keeps gambling until he brought the house down 40%". It was your choice to let the simulation run until the player is broke, but in reality, a player could pull out, leaving the site at 40% loss.

The site is not dependent on any one gambler, but rather on the sum of all gamblers playing at the site. If revenue declines to zero (everyone stops playing) yes that would be bad. But that is true for any business.

[oda.krell]

Second question: As your simulation shows, there's a 10% risk that we reach 57% of initial bankroll, assuming 1/2 kelly (it's a bit of a simplification I guess, since casino bankroll is dynamic, but it doesn't matter for our purposes). Say the whale/player stops at this point. That's a possibility, right? We could specify, ahead of time, "player keeps gambling until he brought the house down 40%". It was your choice to let the simulation run until the player is broke, but in reality, a player could pull out, leaving the site at 40% loss.

The site is not dependent on any one gambler, but rather on the sum of all gamblers playing at the site. If revenue declines to zero (everyone stops playing) yes that would be bad. But that is true for any business.

Sure. But that wasn't my question. I wanted to know how to formally include the possibility that the (simulated) whale stops playing at a certain point (defined by how much he brought the house down), and how to calculate the results of "another" whale who continues playing at maxprofit.

[elm]

FUD is growing: http://www.reddit.com/r/Bitcoin/comments/1nidbv/statisticsjustdice_scam_investigation_conclusion/

Probably the author is the one of the email who did not receive the 400BTC :-D. Not much sense in that article however.

yep it could be the one who send the ugly blackmail letter. but I dont agree with You that the article/theory doesnt make sense. it is a possible scenario imo.

+1

Yeah, it must be the blackmailer, and you are correct, the scenario he describes is not non-sensical. In fact it's entirely possible, and furthermore, from day one Dooglus himself mentioned this was a weakness and that he could not find a trustless way to implement the site. Just look at the first 25 or so pages from this thread. He addresses this.

This, btw, is why that ransom demand was so ridiculous-- he was merely threatening to make public  a theory which Dooglus made public as a possibility on day one (or day 20ish).

good to see that at least one is trying to think in a game theory way. and yes doog mentioned the  problem himself a few times. and I am wondering why it is not discussed here how to find a 100% way to secure also the operator and investors in a provably fair way. I just dont get it. we are talking about millions of $$$ at risk. I could in my simple words explain how I would like to see it and if it is possible why the OP and investors wouldnt like to implement it. until now they even didnt care to discuss it. I am not a genius I am just realistic and think one has to be open minded and see all possibilities.

please dont shoot me

[Lohoris]

So, what the rest of investors would think about trying with a 1.5% edge? It's going to be difficult to have doog agree on that as all the marketing of JD is based on the extremely low 1% edge, but I would love to hear your reasoned opinions.

I would totally agree.

After all, this site is made for profit, so if profit isn't there, we need to change something.

So your argument is the classical "Something must be done, this is something therefore it should be done"  

Of course not.

We must weight pros and cons, quite obviously.

[TheFuneral]

Doog is there anyway we could setup the system so duplicate usernames can't be made?

It's essentially destroyed the chat and turned it into a begging war or copy-cat place. The only time it's useful, and I see you on then, is at night when everyone is asleep.

[nicolaennio]

FUD is growing: http://www.reddit.com/r/Bitcoin/comments/1nidbv/statisticsjustdice_scam_investigation_conclusion/

Probably the author is the one of the email who did not receive the 400BTC :-D. Not much sense in that article however.

yep it could be the one who send the ugly blackmail letter. but I dont agree with You that the article/theory doesnt make sense. it is a possible scenario imo.

+1

Yeah, it must be the blackmailer, and you are correct, the scenario he describes is not non-sensical. In fact it's entirely possible, and furthermore, from day one Dooglus himself mentioned this was a weakness and that he could not find a trustless way to implement the site. Just look at the first 25 or so pages from this thread. He addresses this.

This, btw, is why that ransom demand was so ridiculous-- he was merely threatening to make public  a theory which Dooglus made public as a possibility on day one (or day 20ish).

good to see that at least one is trying to think in a game theory way. and yes doog mentioned the  problem himself a few times. and I am wondering why it is not discussed here how to find a 100% way to secure also the operator and investors in a provably fair way. I just dont get it. we are talking about millions of $$$ at risk. I could in my simple words explain how I would like to see it and if it is possible why the OP and investors wouldnt like to implement it. until now they even didnt care to discuss it. I am not a genius I am just realistic and think one has to be open minded and see all possibilities.

please dont shoot me

My proposal is to put a very low maxbet, at least smaller than 0.125%. In that case it would be statistically impossible to hide a consistent cheat. But at the same time the website would lose much of its appealing...

[oda.krell]

FUD is growing: http://www.reddit.com/r/Bitcoin/comments/1nidbv/statisticsjustdice_scam_investigation_conclusion/

Probably the author is the one of the email who did not receive the 400BTC :-D. Not much sense in that article however.

yep it could be the one who send the ugly blackmail letter. but I dont agree with You that the article/theory doesnt make sense. it is a possible scenario imo.

+1

Yeah, it must be the blackmailer, and you are correct, the scenario he describes is not non-sensical. In fact it's entirely possible, and furthermore, from day one Dooglus himself mentioned this was a weakness and that he could not find a trustless way to implement the site. Just look at the first 25 or so pages from this thread. He addresses this.

This, btw, is why that ransom demand was so ridiculous-- he was merely threatening to make public  a theory which Dooglus made public as a possibility on day one (or day 20ish).

good to see that at least one is trying to think in a game theory way. and yes doog mentioned the  problem himself a few times. and I am wondering why it is not discussed here how to find a 100% way to secure also the operator and investors in a provably fair way. I just dont get it. we are talking about millions of $$$ at risk. I could in my simple words explain how I would like to see it and if it is possible why the OP and investors wouldnt like to implement it. until now they even didnt care to discuss it. I am not a genius I am just realistic and think one has to be open minded and see all possibilities.

please dont shoot me

Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?

[pascal257]

Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?

You'll always have an entity that is able to determine the server seed.

[elm]

FUD is growing: http://www.reddit.com/r/Bitcoin/comments/1nidbv/statisticsjustdice_scam_investigation_conclusion/

Probably the author is the one of the email who did not receive the 400BTC :-D. Not much sense in that article however.

yep it could be the one who send the ugly blackmail letter. but I dont agree with You that the article/theory doesnt make sense. it is a possible scenario imo.

+1

Yeah, it must be the blackmailer, and you are correct, the scenario he describes is not non-sensical. In fact it's entirely possible, and furthermore, from day one Dooglus himself mentioned this was a weakness and that he could not find a trustless way to implement the site. Just look at the first 25 or so pages from this thread. He addresses this.

This, btw, is why that ransom demand was so ridiculous-- he was merely threatening to make public  a theory which Dooglus made public as a possibility on day one (or day 20ish).

good to see that at least one is trying to think in a game theory way. and yes doog mentioned the  problem himself a few times. and I am wondering why it is not discussed here how to find a 100% way to secure also the operator and investors in a provably fair way. I just dont get it. we are talking about millions of $$$ at risk. I could in my simple words explain how I would like to see it and if it is possible why the OP and investors wouldnt like to implement it. until now they even didnt care to discuss it. I am not a genius I am just realistic and think one has to be open minded and see all possibilities.

please dont shoot me

My proposal is to put a very low maxbet, at least smaller than 0.125%. In that case it would be statistically impossible to hide a consistent cheat. But at the same time the website would lose much of its appealing...

please let add another important point that it looks like no one is taking notice of. please show me one casino that has no minimum and maximum bet and is going up and down with the maximum bet like JD. there is no imo.  a normal and healthy casino has a bankroll that is only used to pay out the winners and the bankroll is not jumping in and out and changing each few minutes/hours the maximum bet. that makes the difference in the outcome and result of JD.

[oda.krell]

Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?

You'll always have an entity that is able to determine the server seed.

Can you explain why that is the case? Isn't there a way to set up as a system that, once it is running, doesn't allow changes to it anymore, i.e. it does what it needs to do (sending server seeds, reveal one if asked by player), but doesn't allow additional changes or attempts to read out data?

If that is a problem that is provably impossible to solve (say, a know problem in CS), then I'm not going to continue arguing of course

[GOB]

My proposal is to put a very low maxbet, at least smaller than 0.125%. In that case it would be statistically impossible to hide a consistent cheat. But at the same time the website would lose much of its appealing...

Can we all agree that if the server seeds are compromised or (hypothetically) Dooglus is double-timing the investors (I'm not suggesting this is the case), that no amount of edge or limited max profit will save us??? Why does this keep getting brought up?

If the server is hacked, then you need to divest, period. But there is no evidence so far that it is hacked or that nakowa knows the server seeds. He simply has a huge bankroll and can take the enormous swings. That isn't to say it's not possible.

[pascal257]

Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?

You'll always have an entity that is able to determine the server seed.

Can you explain why that is the case? Isn't there a way to set up as a system that, once it is running, doesn't allow changes to it anymore, i.e. it does what it needs to do (sending server seeds, reveal one if asked by player), but doesn't allow additional changes or attempts to read out data?

If that is a problem that is provably impossible to solve (say, a know problem in CS), then I'm not going to continue arguing of course

If you're sending the seed from another server it needs to be saved. That's worse than the current situation because you then have the seed on multiple systems.
If you pull the seed from another server for each roll, it still needs to be saved somewhere. If we assume doog is evil, he would not be able to determine how long the seed is valid, but at least he got it. But that would only shift the responsibility to another entity. Also you can't prohibit reading the seed, since the server needs it the rolls and if the server gets it, ultimately doog gets it.

[GOB]

Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?

You'll always have an entity that is able to determine the server seed.

Can you explain why that is the case? Isn't there a way to set up as a system that, once it is running, doesn't allow changes to it anymore, i.e. it does what it needs to do (sending server seeds, reveal one if asked by player), but doesn't allow additional changes or attempts to read out data?

If that is a problem that is provably impossible to solve (say, a know problem in CS), then I'm not going to continue arguing of course

To calculate the result of the roll, the server MUST have the server & player seeds, and the nonce. With those three pieces of info it calculates the hash and generates the pseudorandom number. The service is called "Provably Fair" because it is fair in the sense that since we have the hash of the server seed ahead of time, we can see that the server did not alter the server seed to alter the result of the roll.

However, that doesn't protect you from the server (or someone with access to the server, such as [theoretically] Dooglus or a hacker), from knowing the server seed, and thus knowing what number will roll each time, thus allowing that person to bet in such a way that they eventually come out a winner, even if they win/lose in the right proportions and make their play seem random.

I AM NOT TRYING TO SPREAD FUD. I am simply explaining the weakness of the system (Again, Dooglus said this stuff himself at the beginning of the thread).

There are ways of avoiding this situation where the server knows the server seed before you choose hi/lo, but it involves using, for example, the blockchain, since that is a trustless source of consensus. The way it works (I know some sites do this), is that you chose your roll (hi/lo) or whatever before block T is found, and then after the block T comes out, the roll is calculated as Hash(part of block T, client seed,....) etc. The problem is this is slow. If you want the fast style of play like in JD, then you need trust, ** as of right now **.

If you can find a way to keep the fast style of play and make the system trustless, that would be an amazing innovation. I don't think it'd be correct to say it's impossible, it simply hasn't been developed yet.

[elm]

Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?

You'll always have an entity that is able to determine the server seed.

Can you explain why that is the case? Isn't there a way to set up as a system that, once it is running, doesn't allow changes to it anymore, i.e. it does what it needs to do (sending server seeds, reveal one if asked by player), but doesn't allow additional changes or attempts to read out data?

If that is a problem that is provably impossible to solve (say, a know problem in CS), then I'm not going to continue arguing of course

To calculate the result of the roll, the server MUST have the server & player seeds, and the nonce. With those three pieces of info it calculates the hash and generates the pseudorandom variable. The service is called "Provably Fair" because it is fair in the sense that since we have the hash of the server seed ahead of time, we can see that the server did not alter the server seed to alter the result of the roll.

However, that doesn't protect you from the server (or someone with access to the server, such as [theoretically] Dooglus or a hacker), from knowing the server seed, and thus knowing what number will roll each time, thus allowing that person to bet in such a way that they eventually come out a winner, even if they win/lose in the right proportions and make their play seem random.

I AM NOT TRYING TO SPREAD FUD. I am simply explaining the weakness of the system (Again, Dooglus said this stuff himself at the beginning of the thread).

There are ways of avoiding this situation where the server knows the server seed before you choose hi/lo, but it involves using, for example, the blockchain, since that is a trustless source of consensus. The way it works (I know some sites do this), is that you chose your roll (hi/lo) or whatever before block T is found, and then after the block T comes out, the roll is calculated as Hash(part of block T, client seed,....) etc. The problem is this is slow. If you want the fast style of play like in JD, then you need trust, ** as of right now **.

If you can find a way to keep the fast style of play and make the system trustless, that would be an amazing innovation. I don't think it'd be correct to say it's impossible, it simply hasn't been developed yet.

The problem is this is slow I agree that no gambler wants a slow motion game outcome. but why not present the results hours or a day later? would it still be slow outcome for the games?

[oda.krell]

Isn't there a way to set up a server that generates the server seeds and sends them to just-dice, but that doesn't allow those seeds to be read out ahead of time, i.e. before they are sent?

You'll always have an entity that is able to determine the server seed.

Can you explain why that is the case? Isn't there a way to set up as a system that, once it is running, doesn't allow changes to it anymore, i.e. it does what it needs to do (sending server seeds, reveal one if asked by player), but doesn't allow additional changes or attempts to read out data?

If that is a problem that is provably impossible to solve (say, a know problem in CS), then I'm not going to continue arguing of course

To calculate the result of the roll, the server MUST have the server & player seeds, and the nonce. With those three pieces of info it calculates the hash and generates the pseudorandom variable. The service is called "Provably Fair" because it is fair in the sense that since we have the hash of the server seed ahead of time, we can see that the server did not alter the server seed to alter the result of the roll.

However, that doesn't protect you from the server (or someone with access to the server, such as [theoretically] Dooglus or a hacker), from knowing the server seed, and thus knowing what number will roll each time, thus allowing that person to bet in such a way that they eventually come out a winner, even if they win/lose in the right proportions and make their play seem random.

I AM NOT TRYING TO SPREAD FUD. I am simply explaining the weakness of the system (Again, Dooglus said this stuff himself at the beginning of the thread).

There are ways of avoiding this situation where the server knows the server seed before you choose hi/lo, but it involves using, for example, the blockchain, since that is a trustless source of consensus. The way it works (I know some sites do this), is that you chose your roll (hi/lo) or whatever before block T is found, and then after the block T comes out, the roll is calculated as Hash(part of block T, client seed,....) etc. The problem is this is slow. If you want the fast style of play like in JD, then you need trust, ** as of right now **.

If you can find a way to keep the fast style of play and make the system trustless, that would be an amazing innovation. I don't think it'd be correct to say it's impossible, it simply hasn't been developed yet.

Thanks for the more detailed explanation. I should also say, I trust dooglus. It's more out of curiosity that I'm wondering if a trustless system not involving the blockchain could be set up...

Can you explain what is wrong with the following set-up:

1) the rng server/seed server

2) the usual just-dice server

3) the player.

the rng server allows exactly the following 3 calls made from outside:

- give me a random number (including a timestamp and a hash of the server seed that was used)

- reveal a server seed (this call be made exactly once per seed, the 2nd time it returns "already revealed")

- shutdown (needs a password, only dooglus has it)

Gambling works as follows: Player sends player seed and some 'bet identifier' to the seed server. Seed server generates a random number and sends it to player and just-dice server. Just-dice server does the rest (size of bet, storing the result, adding/deducting amount from players account etc).

Say an attacker wants to know the server seed you are using. He can ask the server to reveal it, but you will be able to tell afterwards (since the server doesn't allow revealing more than once). It doesn't prevent cheating in this way, but it makes it visible.

Say an attacker somehow intercepts the random number generated by the seed server. That's where the time stamp could help I think: tampering will take time, which will show itself in a delay between time stamp and bet executed on the just-dice server.

How to prevent reading out information if you have physical access to the server? Don't know if that's possible. Is there a way to encrypt more or less the entire execution of a program?

[rdponticelli]

If something has to be done about limiting "daytrading" investments, I would say that a small divestment fee could be a reasonable solution. It would encourage remaining invested, not to degrade the max bet with those fluctuations.

[tucenaber]

Thanks a lot for posting those results, tucenaber. I started doing some simple simulations myself yesterday, but I keep running into one conceptual problem, and was wondering if you maybe have an idea how to solve it:

You're welcome

You start from the premise of a single player playing until he goes bust.

First question: for a sufficiently large player bankroll (say, 10 times the casino bankroll) there should be the possibility as well that the casino does in fact go broke. Can you quantify that risk?

In practice yes, but in my idealized simulation, no. It can get arbitrarily close to zero but will always stay positive. If you want to quantify the risk of the casino going broke, you have to set a lower limit, and calculate to probability of reaching that. But I'm not sure if there is any point since the bankroll is dynamic as you point out. You will have to consider what the investors will do when getting close to the lower bound. Will they flee or jump in?

Second question: As your simulation shows, there's a 10% risk that we reach 57% of initial bankroll, assuming 1/2 kelly (it's a bit of a simplification I guess, since casino bankroll is dynamic, but it doesn't matter for our purposes). Say the whale/player stops at this point. That's a possibility, right? We could specify, ahead of time, "player keeps gambling until he brought the house down 40%". It was your choice to let the simulation run until the player is broke, but in reality, a player could pull out, leaving the site at 40% loss.

Of course it's a possibility. The player can walk away at any point and that's the risky part. If we knew that he would keep playing there wouldn't be anything to worry about. I didn't want to include the stopping rule in the calculation because it is arbitrary, and don't give much extra information in my view.
Since you're guessing anyway, you could just guess about what percentage he manages to take with him. That is no more arbitrary than picking a "target".

The idea behind my approach, is that we can get a upper bound on what the player may be able to walk away with. If we know that we know much more than before Then we guess that in all likelihood he won't be able to quit with more than 50% of that, say.

Now comes the tricky part, at least for me: (a) What if another whale comes along? (b) What if "the other whale" is the old whale, continuing to play. Is the correct way to think about this situation as independent probabilities, so in this case: there's a 10% chance the house lost 43% (assuming the whale "left"), and there's a 10% chance that this will happen again (from the current, reduced bankroll), either by the same whale, or another whale who plays maximum profit bets?

To answer b) I must emphasize that the figures I gave was for the total number plays from beginning to bust. There is no stopping in this scenario. So he can't come back, while he is still playing.
But you are right, that there can be a string of high rollers who each manages to stop playing while ahead. Then they will each reduce the bankroll left from the one before him.

So you need a high enough EV on ordinary players to make up for the reduction by the extreme cases. You could say it is a fragile system, if you are familiar with Nassim Taleb.

If a whale can almost wipe you out you have a problem.

[GOB]

So you need a high enough EV on ordinary players to make up for the reduction by the extreme cases. You could say it is a fragile system, if you are familiar with Nassim Taleb.

+1 for Nassim Taleb anti-fragile reference!

[theskillzdatklls]

I'm in favor of letting people day trade because then it increases my % of the pool when I stay in.