True, though the delay only about 1 second below that. Hopefully the server can be optimized and eventually those delays for bets less than .0001 reduced.
The delay is up to 3 seconds. Prior to the recent update, it was as high as 6 seconds.
OK, thanks for the definition of "mutually exclusive" but that doesn't answer my question.
What's your point?
While I can't (and no one can) predict with any certainty the future rolls without knowing the server seed, we can estimate with high probability, the future rolls, in terms of how often certain events occur, particularly the consecutive wins or losses.
That's not really the point, that's just a simplified view of things, and it just merely agrees with the Gambler's Fallacy, which many believe to be just that, a fallacy; therefore it can not be true.
But more to the point is that the lucky numbers are not truly random, they are determined. Yes, they are unpredictable. That is also why pseudorandom number generators (PRNG) are also known as deterministic random bit generators (DRBG).
In practice, the output from many common PRNGs exhibit artifacts which cause them to fail statistical pattern detection tests. These include:
Shorter than expected periods for some seed states (such seed states may be called 'weak' in this context);
Lack of uniformity of distribution for large amounts of generated numbers;
Correlation of successive values;
Poor dimensional distribution of the output sequence;
The distances between where certain values occur are distributed differently from those in a random sequence distribution.
Whether or not my "magic seeds" are one of those "weak" seeds is not known at this point. Or I'm just lucky? I think the output using the current set up is actually uniformly distributed.
But wikipedia has this to say about the particular generation method of making lucky numbers.
http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generatorA cryptographically secure hash of a counter might also act as a good CSPRNG in some cases. In this case, it is also necessary that the initial value of this counter is random and secret. However, there has been little study of these algorithms for use in this manner, and at least some authors warn against this use.
Yours, (JD), as well as CR and PD and maybe other gambling sites will be the first to extensively (or exclusively) use this in a "real" application (as far as real as we are concerned with bitcoins anyway).
But, this is all gambling. The site is gambling that they get their 1%. The gamblers are gambling that they win double their money back or nothing, or whatever chance to play they choose.
In the end, we can't really know or prove anything: whales can come and upset the whole operation in 30 seconds. Little fish can and will martingale and not go bust for a long time. Both do not prove anything.
I say, it's all magic and voodoo. Or faith... science nor math can prove the existence of deities, you just have to take that leap. There is a god of gambling. Or a goddess of dice. I dunno.
So, yah, maybe I don't know anything and maybe I don't have a point. But I like playing.
The solution to the delay issue is and should be temporary. You need a better solution to that problem. (Server side martingale might be one of them.)
