What is wrong with using hmac_sha512(block_hash, trans_id) as the resulting hash for a provably fair game? Let's assume someone wants to make their own version of Satoshi Dice.  Satoshi Dice states that the winning output of the game is determined in the following manner.


  The lucky number used to determine the winner of games is simple. It
  is simply the first bytes of hmac_sha512(secret,txid:out_idx). That
  would be the secret string as the key and the transaction ID of your
  bet transaction as the data.


I've done a little bit of research, and most provably fair gaming sites use a secret key for their result hashing.

My question is, what is wrong with using the block hash as the the key for the hashing algorithm when determining the win results, instead of a secret key that's periodically updated?

I cannot see how this method could benefit the player since he has no way of knowing what the hash of the block will be until after they've submitted the transaction and the containing block is confirmed at least once.

What is the exploit that prevents sites from using such a simple means of calculating the win/loss conditions?
Miners could cheat this game, by withholding blocks that would cause them to lose.

For simplicity, let's assume the game is designed for approximately 50/50 odds (say, players are betting on the first bit of hmac_sha512(block_hash, trans_id)).

A mining cartel could do the following.  The cartel members pool their coins and place a single large bet at your casino (say BTC 1000).  If they solve the next block before anyone else on the network, they compute the hash of the block hash and transaction id, and determine whether this block hash would win their bet.  If it would, they post it, and collect their winnings (and their BTC 25 block reward).  If it wouldn't, they throw it away and keep mining (and forfeit BTC 25).  This cuts their effective hashing rate in half, but means that every time they do find a good block, they have a guaranteed win of BTC 1000.

This introduces a bias into the game, proportional to the fraction of the network's hashing power that the cartel controls.  But even a slight bias, over large bets and a long time, could let the cartel clean up at the casino's expense.

Worse, since the cartel's activities are profitable for all its members, there'd be an incentive for more miners to join the cartel, which makes the bias stronger.  In the limit, every miner on the network joins the cartel, and the cartel wins 100% of its bets.

A solo miner could mount a similar attack.  Alice creates a transaction that bets BTC 1000 at the casino, but doesn't publish it to the p2p network.  Instead, she includes it in the blocks that she hashes.  When she solves a block, she checks its hash to determine if it would win her bet.  If so, she publishes it.  (Maybe, to be a little less obvious, she will post her bet transaction on the p2p network and wait a few seconds before publishing the block, and hope that nobody solves another block in the meantime.)  If the block doesn't win her bet, she discards it.  As in the previous case, her effective hashing rate drops by half, but she wins every single bet that she makes.

"Provably fair" can be counterintuitive.  The way to make a provably fair game is not to bet on some external phenomenon that you think neither party can predict or influence; often the parties will surprise you, and in any case it's not usually easy to prove that they can't.  Provably fair systems instead bet on something that's determined by the inputs of both parties (with no external input), but determined in such a way that either party can assure a fair result by choosing their input to be truly random.