Quote from: o_e_l_e_o on October 25, 2022, 08:48:18 AM

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.

Quote

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.

Quote

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.

Quote

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.

Quote

Quote from: larry_vw_1955 on October 25, 2022, 01:35:47 AM

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³¹ 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...