<p>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.</p>

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

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.  </p>

<p>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.</p>

CC BY-SA 3.0
2013-10-23T17:58:07.163Z
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.
Nate Eldredge
CC BY-SA 3.0
2013-10-23T11:35:34.600Z
2013-10-23T11:35:34.600Z
RLH
<p>Miners could cheat this game, by withholding blocks that would cause them to lose.</p>

<p>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)).</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>"Provably fair" can be counterintuitive.  The way to make a provably fair game is <em>not</em> 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 <em>determined</em> 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.</p>

CC BY-SA 3.0
2013-10-23T18:02:17.980Z
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
CC BY-SA 3.0
2013-10-23T18:04:21.923Z
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
CC BY-SA 3.0
2013-10-23T18:04:23.950Z
@bvpx: Yes.  I'm assuming that their bet is substantially larger than the block reward.
Nate Eldredge
CC BY-SA 3.0
2013-10-23T18:05:15.430Z
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
CC BY-SA 3.0
2013-10-23T18:09:27.673Z
@bvpx: First, you'd have to limit the *total* bets (among all players) to 24 BTC every 10 minutes (otherwise one player or cartel could just make lots of small bets from separate accounts).  That would drastically limit the size of your casino.
Nate Eldredge
CC BY-SA 3.0
2013-10-23T18:10:41.857Z
@bvpx: Or, a cartel could decide that they will not throw away all losing blocks, but only some fraction.  They will lose less in rewards, and still get to play a game biased in their favor.  And of course, if most of the network is participating in the cartel, then difficulties will drop to reflect the effective halving of the hash rate.
Nate Eldredge
CC BY-SA 3.0
2013-10-23T18:12:51.070Z
@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.
Nate Eldredge
CC BY-SA 3.0
2013-10-23T17:56:52.220Z
2013-10-23T17:56:52.220Z
Nate Eldredge
<p>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.</p>

<blockquote>
  <p>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.</p>
</blockquote>

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

<p>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?</p>

<p>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.</p>

<p>What is the exploit that prevents sites from using such a simple means of calculating the win/loss conditions?</p>

CC BY-SA 3.0
2013-10-23T04:36:29.510Z
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
<hash><gambling><provably-fair>
What is wrong with using hmac_sha512(block_hash, trans_id) as the resulting hash for a provably fair game?
RLH
# What is wrong with using hmac_sha512(block_hash, trans_id) as the resulting hash for a provably fair game?

(Asked by: username_0 on 2013-10-23)

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?

**Tags:** hash, gambling, provably-fair

> **Comments:**
> **username_1**: 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?  

---

## 2 answers

### Answer by username_2 on 2013-10-23. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_0**: Thanks username_2.  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.  
> **username_3**: 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?  
> **username_2**: @username_3: Yes.  I'm assuming that their bet is substantially larger than the block reward.  
> **username_3**: 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.  
> **username_2**: @username_3: First, you'd have to limit the *total* bets (among all players) to 24 BTC every 10 minutes (otherwise one player or cartel could just make lots of small bets from separate accounts).  That would drastically limit the size of your casino.  
> **username_2**: @username_3: Or, a cartel could decide that they will not throw away all losing blocks, but only some fraction.  They will lose less in rewards, and still get to play a game biased in their favor.  And of course, if most of the network is participating in the cartel, then difficulties will drop to reflect the effective halving of the hash rate.  
> **username_2**: @username_3: 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.  

---

### Answer by username_0 on 2013-10-23. Score: 0

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 username_1 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.

> **Comments:**
> **username_2**: 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.  

---

