Quote from: oda.krell on October 01, 2013, 04:40:26 PM

Quote from: GOB on October 01, 2013, 04:21:20 PM

Quote from: oda.krell on October 01, 2013, 04:05:01 PM

Quote from: pascal257 on October 01, 2013, 03:56:05 PM

Quote from: oda.krell on October 01, 2013, 03:51:46 PM

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 Cheesy

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?

The only way to make fair to investors is to pull the random number from a provable RNG such as a hardware one. Services such as random.org offer this. Of course, this translate CP risk from the OP now to a different 3rd party. Also, you would not have the standard type of provable fairness, though any player could audit random.org (or any other true RNG service) to prove the #s are fair to the player in that way. I think that would satisfy most players. Not sure if more investors would prefer blinding the OP to the random numbers but transferring it to a 3rd party.