Problem: I can still brute force a combination of client hash and server secret that will allow myself to win the progressive jackpot (royal flush)
Oh, ya, the progressive jackpot means you are not just playing against the house but against other players.
BitLotto handles that by using an external event (results of the state-run lottery) which isn't known until after the betting window closes.
What isn't known at the time of the wager is the hash of the next couple blocks. That would prevent that immediate positive reinforcement that keeps people playing though since you wouldn't know if you won for ten or twenty minutes after betting.
If your service uses the blockchain, maybe you could include a hash of the timestamp that blockchain.info.com shows for the transaction (e.g., epoch/unix time) to give something that is not known at the time of the bet, is not really controllable (not to the second) and becomes expensive if brute forced (due to part of the losses getting added to the progressive jackpot that potentially go to a winner other than the house). Of course, this assumes that there is no collusion between the house and blockchain.info.
Here's something along the same lines, using the Twitter public timeline:
-
http://pyevolve.sourceforge.net/wordpress/?p=631Where you use the timestamp to determine a tweet from the public timeline that occurs after the wager is placed, and the hash of that tweet is used. Gah, that's crazy and still not provably fair.
