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

[Deprived]

So what would be needed to remove the possiblity for the site operator to defraud the investors, would be an verifiable external source of entropy over which the site operator has no control and that all participants can verify independently.

You actually need a LOT more than that.  Getting a provable source of entropy isn't actually the real difficult part.  The hard part is means by which dooglus can use that source to process rolls AND can prove that the details of the bet weren't changed after he obtained the random number.  What you seem to miss is that distinction - and it's massive.

Here's the rough flow of what should happen :

Player makes a bet
Dooglus obtains verifiable random number
Result of bet is calculated.

How do you ensure that the right random number is applied to an unchanged bet?  Without massively slowing down the system it's very hard to do.  But if you can't guarantee that the bet processed is the one intended before the result was calculated then suddenly NOTHING is secure any more.  Dooglus could cheat players by getting 10 random numbers then working out which combination of applying them to 10 pending bets gave the house the most.  Or he could cheat investors by betting himself, working out the result then changing the bet size (or even odds) dependent on what the result was.  We'd be worse off than we already are.

Conceptually the solution is easy - bets are logged in public first then some combination of a hash of the bet details + a timestamp used to generate the seed for a random number.  But putting that concept into practice is harder than it might sound - you have to deal with things like what if the external source becomes unavailable (do bets hang or are they cancelled?  can he selectly choose not to receive results if he doesn't like them?).  And you also then have to find a random source where it's verifiable which output is produced from which input - but where such results can't be obtained in advance (which means real-time sampling of entropy based on the time-stamp element).

It's using a sledgehammer to crack a walnut.  The solution already exists - if you don't believe he'll act in good faith then don't invest.  Every investment without a fixed rate of return has the potential for the issuer to act in bad faith and cheat investors subtly.  There's no reason why this one should be any different.

[1715624612]

1715624612

[1715624612]

1715624612

[nimda]

Besides it's totaly stupid for dooglus to cheat this much at a time. If he wanted to he'd do it slowly over time, not like this.

That depends on which level you think. Maybe he's one level higher than you, and he did it this obviously precisely because people think like that

[sgravina]

...
[So what would be needed to remove the possiblity for the site operator to defraud the investors, would be an verifiable external source of entropy over which the site operator has no control and that all participants can verify independently.
..

The way other gambling houses do this is have a random number generator that can be observed by the investor and gambler simultaneously.  Like a roulette wheel, roll of actual dice, lottery tumbler or even a horse race.  If both parties see the number generation simultaneously and agree on it's fairness then neither can know the result before the other.  So the problem with just-dice's number generator is that the house and player can't observe the generation simultaneously.  The house controlling the generator mechanics always has a way to know the outcome before the player.

I can't think of a simultaneously observable generator that can do 20 bets a second.  The lottery tumbler on a live video feed is the best I can think of.

[sgravina]

...
[So what would be needed to remove the possiblity for the site operator to defraud the investors, would be an verifiable external source of entropy over which the site operator has no control and that all participants can verify independently.
..

The way other gambling houses do this is have a random number generator that can be observed by the investor and gambler simultaneously.  Like a roulette wheel, roll of actual dice, lottery tumbler or even a horse race.  If both parties see the number generation simultaneously and agree on it's fairness then neither can know the result before the other.  So the problem with just-dice's number generator is that the house and player can't observe the generation simultaneously.  The house controlling the generator mechanics always has a way to know the outcome before the player.

I can't think of a simultaneously observable generator that can do 20 bets a second.  The lottery tumbler on a live video feed is the best I can think of.

Maybe if the actual time can be used to seed or hashed with the number generator?  Can everyone agree on what time something happens?  Does this help?  Not if it creates a predictable generator.  Just thinking out loud here.  I don't really know.

[bitfair]

So what would be needed to remove the possiblity for the site operator to defraud the investors, would be an verifiable external source of entropy over which the site operator has no control and that all participants can verify independently.

You actually need a LOT more than that.  Getting a provable source of entropy isn't actually the real difficult part.  The hard part is means by which dooglus can use that source to process rolls AND can prove that the details of the bet weren't changed after he obtained the random number.  What you seem to miss is that distinction - and it's massive.

Here's the rough flow of what should happen :

Player makes a bet
Dooglus obtains verifiable random number
Result of bet is calculated.

How do you ensure that the right random number is applied to an unchanged bet?  Without massively slowing down the system it's very hard to do.  But if you can't guarantee that the bet processed is the one intended before the result was calculated then suddenly NOTHING is secure any more.  Dooglus could cheat players by getting 10 random numbers then working out which combination of applying them to 10 pending bets gave the house the most.  Or he could cheat investors by betting himself, working out the result then changing the bet size (or even odds) dependent on what the result was.  We'd be worse off than we already are.

Conceptually the solution is easy - bets are logged in public first then some combination of a hash of the bet details + a timestamp used to generate the seed for a random number.  But putting that concept into practice is harder than it might sound - you have to deal with things like what if the external source becomes unavailable (do bets hang or are they cancelled?  can he selectly choose not to receive results if he doesn't like them?).  And you also then have to find a random source where it's verifiable which output is produced from which input - but where such results can't be obtained in advance (which means real-time sampling of entropy based on the time-stamp element).

It's using a sledgehammer to crack a walnut.  The solution already exists - if you don't believe he'll act in good faith then don't invest.  Every investment without a fixed rate of return has the potential for the issuer to act in bad faith and cheat investors subtly.  There's no reason why this one should be any different.

I read your post a several times, and it seems you are talking about being provably fair for the bettors. And I have a certain understanding of that concept: apply a hash function on the server-side secret and send to the client, combine the server-side secret with some client-side input then process the bet according to commonly agreed rules. When the server-side secret is revealed, the client can verify that the rules were followed. I find that quite straight-forward.

My problem is a slightly different one, since JD has three parties: player, investor and operator. The operator is in this case the site/dooglus and acts as a mediator between the bank (investors) and the player. The player gets to have "provably fair" gaming. But what would it take to give the investors the same "provably fair" investing? The operator, who knows the server-side secret, can pretend he is a player and make bets against the investors -- and win every time! How can that, theoretically, be prevented?

And the most sensible answer so far is to link the outcome of the bet to the outcome of an unpredictable future event which is not known or knowable by any of the three parties involved. The more I think about it, linking the outcomes to future blocks in the bitcoin blockchain actually solves the problem -- but would simply be way too slow for the players!

Edit: By the way, I'm not saying that I don't trust dooglus (because I believe dooglus is one of the most honorable members of the forum). I'm saying that *proof* is better than *trust*.

[drawingthesun]

I think in the long run creating a system that is fair for the investors will be necessary, I say this not because I don't trust Dooglus but because every time something unusual happens people may always suspect Dooglus and this will cause rumours in the community and eventually people may move to another site.

I'm not sure what could be done. Maybe add a hash of the mouse movements to the seed or the time or something, There must be a way..... hmmm.

[Dabs]

I have actually emailed the operator / webmaster of random.org. It's possible he might offer a live-stream of random numbers that are archived, but I'm guessing that might be a paid service.

I'm not sure dooglus "invented" provably fair, but I'm sure satoshidice was one of the first to use such a system.

As a topic of interest but not directly related to dice games, I run a lotto. It is provably fair, such that even the operator can not cheat. However, the time frame is in 7 days. There used to be (or still is?) a lotto game that runs on a per block basis.

Are players willing to wait 10 minutes to find out if their roll won or lost? I don't think so. (Well, SD works this way, hehe, 1 confirmation game) For the lotto, players wait until the draw date. For instant games, it's a much harder thing to implement.

[drawingthesun]

I have actually emailed the operator / webmaster of random.org. It's possible he might offer a live-stream of random numbers that are archived, but I'm guessing that might be a paid service.

I'm not sure dooglus "invented" provably fair, but I'm sure satoshidice was one of the first to use such a system.

As a topic of interest but not directly related to dice games, I run a lotto. It is provably fair, such that even the operator can not cheat. However, the time frame is in 7 days. There used to be (or still is?) a lotto game that runs on a per block basis.

Are players willing to wait 10 minutes to find out if their roll won or lost? I don't think so. (Well, SD works this way, hehe, 1 confirmation game) For the lotto, players wait until the draw date. For instant games, it's a much harder thing to implement.

Keeping the game instant is important, it gives us an edge over S.Dice and the more bets per second happening the faster the house edge will become apparent.

(If we slow the bets down variance will be higher per same time frame)

Also if millionaire whales were playing on the site all the time we would eventually see the house win, but so far we have had 1 whale of that size and he had enough to keep playing. Its not about the min max so much as how much money he had. My simulations how losing streaks of 29 in a row are common. In the long run the house will win but we need several orders of magnitude more bets moving through the site everyday, even now volume is too low and variance wins the day.

[Dabs]

I think in the long run creating a system that is fair for the investors will be necessary, I say this not because I don't trust Dooglus but because every time something unusual happens people may always suspect Dooglus and this will cause rumours in the community and eventually people may move to another site.

I'm not sure what could be done. Maybe add a hash of the mouse movements to the seed or the time or something, There must be a way..... hmmm.

No other site that is an instant dice game has anything more provably fair than all the other dice sites. Time can be exploited by timing attacks. Mouse movements is just another way of making client seeds.

The solution, so far, are third party high speed servers. That's added cost and no matter what, added time. JD is fun because you can bet very fast. Make it slower, and it loses that appeal. Any slower, then you might as well play a different game.

The game is fair for players. The game is also fair to investors as long as the operator doesn't cheat. This is what it boils down to.

Escrow has a similar problem, but so far, there are not too many 2-of-3 multi-sig transactions, and people have no problem trusting escrow providers with thousands of bitcoins.

[romerun]

I read the provable fair page, and don't get why it has to be so many steps.

What's wrong with just,

server calls a random function to generate a number and a secret string, combines them and returns the hash of it,

the number is released along with the secret string.

what's the benefit of the client seed other than "to further randomize the rolls." ? the randomness from server is not enough ?

The benefit of the client seed is to keep the server from cheating. Imagine if you were betting on 10%, and the server gave you a secret which had been pre-tested, and the first 1000 rolls were between 10 and 90.

a house might not want to pre generate that kind of pattern because if player can guess such pattern, the house is done. Or you mean that the house can use some kind of AI or statistic to guess what the player will bet next according to player pattern and release the result accordingly ? What if some players can outsmart that strategy. Wouldn't it be safer for the house to purely randomly honestly generate the result and use the house edge to defeat players. I still don't get the point of client seed.

[Deprived]

So what would be needed to remove the possiblity for the site operator to defraud the investors, would be an verifiable external source of entropy over which the site operator has no control and that all participants can verify independently.

You actually need a LOT more than that.  Getting a provable source of entropy isn't actually the real difficult part.  The hard part is means by which dooglus can use that source to process rolls AND can prove that the details of the bet weren't changed after he obtained the random number.  What you seem to miss is that distinction - and it's massive.

Here's the rough flow of what should happen :

Player makes a bet
Dooglus obtains verifiable random number
Result of bet is calculated.

How do you ensure that the right random number is applied to an unchanged bet?  Without massively slowing down the system it's very hard to do.  But if you can't guarantee that the bet processed is the one intended before the result was calculated then suddenly NOTHING is secure any more.  Dooglus could cheat players by getting 10 random numbers then working out which combination of applying them to 10 pending bets gave the house the most.  Or he could cheat investors by betting himself, working out the result then changing the bet size (or even odds) dependent on what the result was.  We'd be worse off than we already are.

Conceptually the solution is easy - bets are logged in public first then some combination of a hash of the bet details + a timestamp used to generate the seed for a random number.  But putting that concept into practice is harder than it might sound - you have to deal with things like what if the external source becomes unavailable (do bets hang or are they cancelled?  can he selectly choose not to receive results if he doesn't like them?).  And you also then have to find a random source where it's verifiable which output is produced from which input - but where such results can't be obtained in advance (which means real-time sampling of entropy based on the time-stamp element).

It's using a sledgehammer to crack a walnut.  The solution already exists - if you don't believe he'll act in good faith then don't invest.  Every investment without a fixed rate of return has the potential for the issuer to act in bad faith and cheat investors subtly.  There's no reason why this one should be any different.

I read your post a several times, and it seems you are talking about being provably fair for the bettors. And I have a certain understanding of that concept: apply a hash function on the server-side secret and send to the client, combine the server-side secret with some client-side input then process the bet according to commonly agreed rules. When the server-side secret is revealed, the client can verify that the rules were followed. I find that quite straight-forward.

My problem is a slightly different one, since JD has three parties: player, investor and operator. The operator is in this case the site/dooglus and acts as a mediator between the bank (investors) and the player. The player gets to have "provably fair" gaming. But what would it take to give the investors the same "provably fair" investing? The operator, who knows the server-side secret, can pretend he is a player and make bets against the investors -- and win every time! How can that, theoretically, be prevented?

And the most sensible answer so far is to link the outcome of the bet to the outcome of an unpredictable future event which is not known or knowable by any of the three parties involved. The more I think about it, linking the outcomes to future blocks in the bitcoin blockchain actually solves the problem -- but would simply be way too slow for the players!

Edit: By the way, I'm not saying that I don't trust dooglus (because I believe dooglus is one of the most honorable members of the forum). I'm saying that *proof* is better than *trust*.

I obviously didn't make myself clear as I WAS talking mainly about proving fairness to investors.

It's all fine and well having a provable random string of numbers but you STILL have to somehow ensure dooglus applies them correctly.  Otherwise he can just get the stream of numbers, see whether bets using them win and, if those bets win, make a big bet on an alt account.  Just getting random numbers doesn't help unless how they're used is fully auditted - which puts us back to square one of trusting activity carried out on dooglus' server.

One solution for this sort of problem is fully auditted code running on a server hosted by a third-party in a controlled and monitored environment (where server-side seeds would be generated from entropy and not revealed to ANYONE until after they'd expired).  But there's a very significant cost to that sort of setup - and with it being a gambling site there's reasons why a formal, public, legally contracted system such as that may not be too attractive (as every aspect of the hosting has to be publicised to ensure the third-party really is a third-party).

There's also a seperate very good reason why this sort of thing is unlikely to happen.  Any solution is going to add cost and non-zero CP risk for dooglus - so there's no reason for him to even consider it unless he can't get however much investment he wants anyway.  And looks like he CAN get the investment he needs - so run by me again why he should even consider it?

[dooglus]

Imagine if you were betting on 10%, [...] and the first 1000 rolls were between 10 and 90.

What if some players can outsmart that strategy.

When you play the 10% game, 'lo' wins if the number is <10.x and 'hi' wins if the number is >= 90.x.  If the number is between 10 and 90 you lose whether you play hi or lo.

The house can make 85% of your rolls be between 10 and 90, and force you to lose those games.  Of the rest you'll win about half, meaning you'll lose a lot quicker than you should.

The client seed means the house isn't able to decide what number to roll, since you pick the client seed after the house has picked the server seed.  Without it, the house can roll any number they like, including numbers which are guaranteed to make you lose.

[dooglus]

One solution for this sort of problem is fully auditted code running on a server hosted by a third-party in a controlled and monitored environment

What third-party sets that up?  Do you trust that they didn't install a back door?  Who audits it?  Do you trust them?

You're still left trusting somebody not to cheat.

[Deprived]

One solution for this sort of problem is fully auditted code running on a server hosted by a third-party in a controlled and monitored environment

What third-party sets that up?  Do you trust that they didn't install a back door?  Who audits it?  Do you trust them?

You're still left trusting somebody not to cheat.

Indeed - to do it securely would cost a load.  You're having to look at a reputable large company hosting with live video feed of the hosting area, secured and logged access, insurance in place for security breeches etc.  End result being greatly enhanced confidence for investors of fair-play (but not zero risk) with new CP for yourself at a massive cost and with serious delays any time an update is needed (delays both to get access and for changes to be audited).

Auditing would have to be done live on-site by multiple independent parties etc.

A whole lot of effort when there's zero reason for you to do it - but without the servers in a controlled environment there's essentially no way to do it.  Which is why I think the idea is just a waste of time.

[atrax1978]

I think a real cheater won't gamble like what happened in this morning（ https://just-dice.com/biggest.txt ）, it is too obvious. The clever cheater would change id frequently like there were many different winners and drain the bankroll slowly that no one will notice and doubt.

[001sonkit]

The most recent big win is another reason we need graphs!

http://chromaticcreative.net/bitcoin/pcalc/jd.php (Only update when i launches justdice.com, see the top left word for the last update
)

[Bugpowder]

Distribution of outcomes of a whale hammering the max bet for 10,000 trials.

Max profit as percentage of bankroll in upper right.

Geometric mean as circles.  0.5% circle is buried under the 1.5% circle.

[TheFuneral]

wow this is getting nasty. I put 35BTC in last week and now it's down 5BTC and sitting at 30BTC. come on variance!

[mechs]

I think Dooglas needs to make some changes to the system.  It is too high risk to the investors.  Currently we have a 1% edge with a 1% of bankroll max payout per bet.  Compared to competitors such as satoshi dice, primedice and coinroll.it we are superior in everyway, too much so actually and we should make some parameters more conservative. We are amazing for gamblers but not a good deal for investors currently.

The current setup would be fine over infinite time with infinite bankroll, but at the far more finite #s involved, the system breaks down for investors:

Primedice: 1% edge, 5 BTC max payout, very slow betting (since done via deposit addresses) and spams the blockchain, less provably fair than Just-Dice since server seed changes only daily and client seed chosen from deposit tx ID

Satoshi Dice: 1.9% edge, 500BTX max payout (though at 50% is only 463), very slow betting (since done via deposit addresses) and spams the blockchain, less provably fair than Just-Dice since seed changes only daily and unclear where client seed chosen from

Coinroll.it: 1% edge, Not sure what is the max payout, fast betting similar to Just-Dice, less provably fair than J-D since since uses the last depost tx ID as client seed

Just-Dice: 1% Edge, Max Payout per Bet is 1% of bankroll (now down to 254BTC), Very Fast Betting - bots galore here with 20 bets/second), most provably fair system put there.  Can re-randomize both the client and server seed at will (every bet if wish).  Can actually enter your own client seed if you do not want to use the one generated by the server.  Plus, I would argue the OP is one of the most reputable people on bitcointalk.  An additional plus is it allows open investing.  The negative is it is not provably fair to investors at all - need to simply trust the OP who knows both the client and server seed and could use shill accounts to steal from investors.

From a gamblers perspective, the investor risks in Just-Dice are a non-issue other than if they lose enough investors the bankroll will be so low that betting will be restricted and site may eventually fail. 

I do not think we need to be as far ahead in fairness to players in relation to the other sites that we current are.  We should either increase the House Edge or decrease the Max Payout.  If the bankroll were much larger (say 1million bitcoin) we could continue as is, but with the current size bankroll, having no max payout with a 1% edge at 20 bets/second is very risky for investors.

[Dabs]

PrimeDice does not use deposit transaction IDs. Play is also fast, but not as fast as just-dice. Max payout has also increased to 20. I'm not for or against any of these dice sites, but you need to get the correct facts.