What is wrong with using hmac_sha512(block_hash, trans_id) as the resulting hash for a provably fair game?

Question

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?

Answer 1

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.

Answer 2

I was thinking about this question last night, and I think I may have discerned the problem with using the block hash as the key to SHA operation. I'm answering my own question so that some of the more knowledgeable experts can either verify my assumptions or correct me if this is wrong.

The problem with this method relies with orphaned blocks and the subsequent transactions that are added back into the mempool for reprocessing.

As an example, if player X sends a few coins to the gaming engine and it responds in the following block with a micro, loss condition payment, my payment, and the players payment, could be contained in child blocks of a small orphan chain. If the block containing the transaction for the game round becomes orphaned, all transactions within the orphan AND it's child blocks are posted back to the mempool to be reprocessed.

If the block of the original players transaction is rehashed, the win/loss conditions could be different. This would be a big problem if the player originally lost, but within the new block hash, they win.

Theoretically, one could rewrite their engine so that it would double-check whether a previous block had been orphaned. For each transaction in an orphan block, re-check the win/loss state. If, and only if, the player had previously lost, but has now one with the new hash, a second winning payment could be posted to the primary block chain.

I don't believe this is exploitable but this would be a big headache. Developing such a system would be easy, but supporting the user's could be annoying if orphaning ever became prevalent.

Also, as Ryan pointed out, this also means that you have to wait one block before you can calculate the win/loss state. This would be a rather annoying feature for a game that is intended to be fast, such as Dice.