And yet Ian Coleman's method generates a string of 32*5 + 16*4 + 4*2 = 232 bits if you draw the entire deck once, which is above this upper limit of entropy.
it may pump out a 232 bit string but that doesn't mean 232 bits of entropy. and therein lies the problem with his little scheme. i call it a scheme because i don't take it seriously.
But still, how are you going to convert a string of cards to bits?
I am sure there must be a way of doing that but it has to be lossless encoding. Unlike Coleman's scheme.
Are you going to use Ian Coleman's method, which as discussed I don't like. Or do you just write your cards out as a string of 7h9sKdAc and so on and hash it? Some other method?
I wouldn't use his method under any circumstances. As for hashing the string, that's better than how he handles it but still not ideal. I like to think hashing is unnecessary.
How has your method been analyzed and tested? As I said, it is not a trivial problem.
Taking the Sha256 hash of the cards as a string is kind of like pushing the problem into the hash function. It's not really solving anything at a very fundamental level. What do you think makes this a non-trivial problem exactly? A deck of cards has 225 real bits of entropy. No more no less. They should be able to be used directly as is. Now you ask me about my method. I don't have a method yet.
The better way is to develop a true mapping of the 225 bits of entropy 1-1 into bitcoin private keys. simple as that.
Rounding errors aside, there are 2
31 more private keys than card orders, so
by doing this you are excluding 99.99999995% of all possible private keys.There are 2^96 more bitcoin private keys than addresses. That never bothered anyone...