Quote:
Originally Posted by speedle
Thanks for the explanation, guess I was mislead by someone on 2p2. I shouldn't say stuff I'm not 100% sure about, I apologize about that.
Good heavens, nothing to apologise.
The constant shuffle is (apparently) so commonly used that everyone who even thinks about it automatically assumes it's true for Stars as well. It really shouldn't make any difference as I would be willing to bet a
lot that nothing in the current hand can affect even the constant shuffle.
Warning: 15+ years of information security background coming up.
Some, or even all poker clients collect some seed data from players and feed that to the server to generate better random data. This data includes, but is not limited to
- mouse movement timing
- click timing
- CPU interrupt timing
- CPU utilization
- network packet frequency
- and so on...
The data collected is from the extreme end of resolution. For example, if click timing is collected, the software records the timestamps from two consecutive clicks and uses the highest precision available. Say it takes you approximately 1.3s between clicks. On this particular occasion the time between these two was measured to be 1.31074476 seconds. The randomness collector uses only 3-4 least significant bits. These bits are then sent back to server, which uses them as input data for seeding.
In order to prevent recently collected data from having an effect on current hands, the random number pool is very likely two-fold. There is a larger pool, into which random data is fed, from clients and external hardware resources alike. This pool is constantly being "stirred", which usually means running a cryptographic operation over some or all parts of the large pool.
This pool is the "primary" source of entropy. Deck shufflers probably do not use it directly. Instead a smaller pool (or even several such pools) is/are constantly fed with data from larger pool, and from such smaller pool the shufflers get their random seeds. The smaller pools are also stirred after getting new data.
Then, when generating deck shuffles, a smaller amount of entropy (random bits) is taken from the small pool and used to shuffle a deck. Some bits may be left over if constant shuffle is used, and fed to the shuffler as extra seed after deal.
To make it absolutely impossible for "active" clients to have any effect on the current deal, the primary pool does not feed the smaller pool until the hands that were shuffled and dealt with the data are over.
....At least, that's how I would do it to prevent even the remotest chance of clients (players) on a table from affecting their deck shuffle when constant shuffle is used.
(Yes, I have some minor experience with applied cryptography.)
