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?

  • I think you bring up an excellent point, the only down side is the payout will have to wait for the following block, delaying the payment slightly. no?
    – Ryan
    Oct 23, 2013 at 4:36

2 Answers 2


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.

  • Thanks Nate. I had considered this a possibility. Truth be told, I don't see this being an issue with bitcoin. However, with alts this is quite plausible.
    – RLH
    Oct 23, 2013 at 18:02
  • As long as the bet is lower than the block reward, wouldn't that be enough to deter them from throwing away a valid block?
    – bvpx
    Oct 23, 2013 at 18:04
  • @bvpx: Yes. I'm assuming that their bet is substantially larger than the block reward. Oct 23, 2013 at 18:04
  • Sorry, I deleted my previous comment. What would be the issue with designing the game to limit maximum bets to current block reward minus one BTC, or something like that? Would there be any way to game that system? Mining cartels would lose in the long run.
    – bvpx
    Oct 23, 2013 at 18:05
  • 1
    @bvpx: My point is that there is certainly a way to introduce bias into this game, and if that's possible (wherever the incentives might lie), it's not a provably fair game. Maybe there's a cartel that really hates you, and is willing to take a big hit in rewards to ensure that you lose your bets. Oct 23, 2013 at 18:12

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.

  • I don't think this is the most serious problem with this game; you can fix it by just waiting for several additional blocks to be mined, making it unlikely that the original block will be orphaned. You probably want to do this anyway before paying off the bet, to ensure that the bet itself wasn't a double-spend. Oct 23, 2013 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.