Interesting, I wasn't aware that personal sources for true RNG existed yet. I only knew about sources available over the internet.

Still the key issues behind rig proofing are that it's more of an issue of transparency. A site may claim truly random sources but without the ability to prove it, the claim is baseless.

I don't think an application for personal use of true RNG can be trusted as part of the shuffle process for the same reason other than generating seed values for a PRNG.

Besides, even a $45 price tag would be a non-starter for those that start playing poker through micro-stakes or free-rolls which I think is a big source of new players which is a critical component in a poker economy.

I'm sorry, I don't mean to be so negative to new ideas but I'm trying to avoid anything that creates a disadvantage over current methods as much as possible since any downside could be a reason for non-acceptance. Ideally, it should be an identical playing experience to the end user, easy to implement, easy to regulate, and at least easy enough to understand for a minimum of a 20 percentile poker population.

Actually my motivation was prompted more by the method I was using. Since my goal is to find an optimal rig proofing solution, I do run into more trade off issues than without such constraints but I never expected it to be easy, though perhaps not quite this hard either.

One example was my requirement to seed every deal using a community table seed so that hands could be regenerated as a post process to compare results to a pre-existing database. Since each deal would need to be seeded, the number of possible deals would be limited directly by the number of possible seed values.

Another issue was the need for a verifiable time element so using seconds instead of milliseconds takes out any contributions for a time element as a security component.

Transparency was another factor. Since the algorithm must be transparent, the odds of code breaking go up.

Player generated codes such as players may using a single repeating number for simplicity again weakens security.

Also software limitations and the desire to use standard variable declarations such as longint can also create limitations as well as the need for streamlining to reduce the software lag from overhead.

I'm sure there are plenty of adequate methods out there. I actually think creating a dealing app that was fair is quite easy. Creating one that can be proven to be fair is quite hard.

Finding methods that would also conform to rig proofing may be a challenge. Right now I'm hoping that my random draw method holds up and it seems like a very promising solution from what I've seen, but time will tell.

We don't need P(52,9) either. Order of the 3 flop cards doesn't matter, nor does order of a player's hole cards.

The number of possible HU deals is C(52,9)*C(9,4)*C(4,2)*C(5,3)*2! = 5.563 E 13

# 3-handed deals = C(52,11)*C(11,5)*5!!*3!*C(5,3)*2! = 5.023 E 16
4-handed = C(52,13)*C(13,5)*7!!*4!*C(5,3)*2! = 4.119 E 19

Or in each of those you can just start with the permutations and divide out the unnecessary orders.

HU = P(52,9) / (2!)^2 / 3!
3-handed = P(52,11) / (2!)^3 / 3!
and so on

I think it does matter however, because those combinations occur at different frequencies. We would need the full P(52,9) to provide a correct random distribution.

We're distinguishing between suits, so each card is distinguishable. There are more permutations of AK than AA, but not more permutations of AhKs than AhAs. So it's not like a dice problem where we have to count permutations of dice (instead of multiset combos) for a probability calculation even when order doesn't matter.

If that doesn't address what you have in mind, please elaborate. I can't think of any reason to count P(52,9).