Quote from: crudpuppy on November 06, 2013, 08:57:12 PM

Ok, now its provable fair as I use my random plus the transaction ID as the seed. I wont know the transaction ID and you wont know the rand until after so fair to both sides...hehe

This is NOT provably fair. If I send a transaction now you can select a random seed which makes me lose quite easily. This is bad. You don't need to change it for me but don't claim it's provably fair if it's not. Look into what the others are doing. A solution that works for on-chain games like yours is to have a secret of the day that doesn't change and have the SHA-256 (or whatever) hash of that secret known, the secret should be at least 16 bytes so it's hard to find by brute force searching (feel free to use longer secrets). When calculating the result you combine the secret of the day with the transaction id in same way and then find a card from the deck in some way.

For example you could: card = (HMAC_SHA256(secret,txid)/2^256)/52, the result is an index in a deck of 52 cards (note: this uses big integer arithmetic)

After the day is over you publish the secret. Now everyone can verify that the SHA-256 of the secret (which was known to players beforehand) is the same as calculating SHA-256(secret) when the secret is known.

Yes you can screw up implementing provably fair and leak your bet results beforehand but you can also do it correctly and the game becomes provably fair for everyone.