Our servers also generate a random string, called the server_seed. We combine the initial_shuffle and the server_seed strings into a single JSON encoded string. We call this JSON string the secret.
Response: "WTF is a JSON string?"
"JSON, or JavaScript Object Notation, is a text-based open standard designed for human-readable data interchange" --
http://en.wikipedia.org/wiki/JSONIt's just a way of formatting strings. Since the server has two things it wants to keep secret, but doesn't want to flood you with too much information, it combines the two things into a single string of text before hashing it. JSON is just a convenient way of doing it. So if the server_seed is "xxx1" and the initial_shuffle is "yyy2", the secret formed by combining these two pieces of information would be:
{"server_seed":"xxx1","initial_shuffle":"yyy2"}
and that's what ends up getting hashed and displayed before the game starts.
Finally, we hash the secret using the SHA256 one-way hashing algorithm. This is called the Hash(secret). We show you this value to you before the hand starts, so you can independently verify that we didn't manipulate the server_seed or the initial_shuffle.
Response: This I understand, but only because a few months ago a bitcoin/cryptogeek friend of mine explained what a SHA256 is and how it worked to verify the bitcoin kamikaze game, if you remember that one. Without that lesson, this would make no sense to me.
That's the part I guessed would be a stumbling block.
Our servers then hash the combination of the server_seed and the client_seed (using SHA256 again). We use this hash to seed the Mersenne Twister pseudorandom number generator. We then fully reshuffle the deck using this random number generator
Response: "Huh? Seed? Mersene Twisters?"
Mersenne Twister is an algorithm for shuffling a list into an apparently random order. It's not really random; it takes a list that you want shuffled and a number (called the seed) that determines how the shuffle will happen, exactly. If you always use the same seed, you'll always get the same shuffle, but use a slightly different seed and you'll get a completely different shuffle. It's a little like hashing in that respect.
Anyways, even if I personally were to understand it, it would be valuable to explain it so normal people understood. Sort of like how my friend taught me how Bitcoin Kamikaze was provably fair as well. This may entice more traditional online gaming aficionados to adopt Bitcoin, thus bolstering our economy.
For instance, the Wizard of Odds runs a popular gambling forum. He endorses Bodog gaming because he says that there have been too many sites that were rigged and he trusts Bodog (plus he probably makes a bunch on affiliate deals, but that's neither here nor there). If Bitzino can explain to normal people how their games are "provably fair" via mathematics, then their system should carry as much weight as a Wizard endorsement, if not more so.
Understood. I guess it's hard to know how far back to basics to go when giving such an explanation. I notice Mersenne Twister is linked to a page that explains it, but SHA256 isn't, for example. I've gone through the process of explaining all this to someone with no relevant knowledge myself, and it can take a while to get through to them, even when you have immediate feedback of which bits they're struggling with.
I think those are very good points. Non-geeks have no idea, and it really doesn't matter, about JSON or SHA256 specifics.
So I guess a separate explanation for 'non-geeks' would be useful. The specifics are important, otherwise there's no point in having it "provably fair". The method used needs to be explained fully enough that though who care and technically able can go through the motions themselves and verify a few hands.