<p>You could leverage the blockchain itself and use something based on the hash of the current block. For example, the block hash will end in a 0 bit roughly half the time. It will end in 00 bits roughly 25% of the time, etc. This is exactly the same idea as the bitcoin "difficulty" parameter, you would be using the hashes as a roughly constant rate stream of unpredictable random bits.</p>

<p>I think everybody who participates would agree that the block hashes are not predictable in advance.</p>

CC BY-SA 3.0
2014-02-24T02:41:10.577Z
I disagree.  Every miner has the ability to bias the block hash, by discarding proofs-of-work that don't have the desired bits.  Granted, they would give up the block rewards, and it's hard to imagine a situation where it would be worth their while to do that.  And you would need a lot of miners involved in this conspiracy to change the odds substantially.  But "provably fair" is a high bar: you need to ensure that nobody has the ability to bias the outcome in any way, no matter how slight, and regardless of whether or not they have a clear incentive to do so.
Nate Eldredge
CC BY-SA 3.0
2014-02-24T02:54:07.237Z
@NateEldredge: That's a good point. However, that would have to be a pretty big lottery to justify throwing away even one coinbase reward. Perhaps such a bias would become more pronounced as the block reward diminishes in value in the future.
Greg Hewgill
CC BY-SA 3.0
2014-02-23T19:07:49.080Z
2014-02-23T19:07:49.080Z
Greg Hewgill
<p>Usually the house just needs to commit to a random piece of data ahead of the game by publishing a hash of the data (possibly concatenated with some additional salt), then later it can prove that the data is not changed based on players' bets.</p>

<p>Example: let's consider a basic game where the house picks a card between 2 to 9 and the player tries to guess the card. To prove that the house indeed picks card at random, it needs to commit to the card ahead by publishing a hash of the card concatenated with some random nonce. After player picks his guess, house can reveal the nonce and show that the card was indeed picked before player made his bet.</p>

CC BY-SA 3.0
2014-02-24T02:57:31.453Z
I don't see how that solves this problem.  Using your suggestion, the house can commit to the time of the draw, and prove they didn't change it.  But they still know when the draw will occur.  The goal here is that nobody should know when the draw will occur until just before it does.
Nate Eldredge
CC BY-SA 3.0
2014-02-24T03:15:49.673Z
I probably did not understand the problem then, or it is not exactly clear how this lottery operates. I assumed the "when" in "when pot will be split" refers to the condition for winning the pot, not a specific point in time.
uminatsu
CC BY-SA 3.0
2014-02-24T02:33:06.553Z
2014-02-24T02:43:22.130Z
2014-02-24T02:43:22.130Z
uminatsu
<p>I have a bitcoin lottery that is still in the prototype stage (bitsplit.it).</p>

<p>I believe that the game will be much more appealing, for certain reasons, if players (and the house) both don't know when the next winner will be chosen.</p>

<p>However, I am having a hard time with coming up with a (feasible) way to prove that the house doesn't know when the pot will split.</p>

<p>Any ideas are greatly appreciated.</p>

CC BY-SA 3.0
2014-02-24T02:58:03.047Z
As your question doesn't really relate to Bitcoin per se, maybe it would be better at http://crypto.stackexchange.com?
Nate Eldredge
<gambling><provably-fair>
Provably fair unknown event time for Bitcoin gambling
Nathan Lippi
# Provably fair unknown event time for Bitcoin gambling

(Asked by: username_0 on 2014-02-23)

I have a bitcoin lottery that is still in the prototype stage (bitsplit.it).

I believe that the game will be much more appealing, for certain reasons, if players (and the house) both don't know when the next winner will be chosen.

However, I am having a hard time with coming up with a (feasible) way to prove that the house doesn't know when the pot will split.

Any ideas are greatly appreciated.

**Tags:** gambling, provably-fair

> **Comments:**
> **username_1**: As your question doesn't really relate to Bitcoin per se, maybe it would be better at http://crypto.stackexchange.com?  

---

## 2 answers

### Answer by username_2 on 2014-02-23. Score: 3 | Accepted answer

You could leverage the blockchain itself and use something based on the hash of the current block. For example, the block hash will end in a 0 bit roughly half the time. It will end in 00 bits roughly 25% of the time, etc. This is exactly the same idea as the bitcoin "difficulty" parameter, you would be using the hashes as a roughly constant rate stream of unpredictable random bits.

I think everybody who participates would agree that the block hashes are not predictable in advance.

> **Comments:**
> **username_1**: I disagree.  Every miner has the ability to bias the block hash, by discarding proofs-of-work that don't have the desired bits.  Granted, they would give up the block rewards, and it's hard to imagine a situation where it would be worth their while to do that.  And you would need a lot of miners involved in this conspiracy to change the odds substantially.  But "provably fair" is a high bar: you need to ensure that nobody has the ability to bias the outcome in any way, no matter how slight, and regardless of whether or not they have a clear incentive to do so.  
> **username_2**: @username_1: That's a good point. However, that would have to be a pretty big lottery to justify throwing away even one coinbase reward. Perhaps such a bias would become more pronounced as the block reward diminishes in value in the future.  

---

### Answer by username_3 on 2014-02-24. Score: 0

Usually the house just needs to commit to a random piece of data ahead of the game by publishing a hash of the data (possibly concatenated with some additional salt), then later it can prove that the data is not changed based on players' bets.

Example: let's consider a basic game where the house picks a card between 2 to 9 and the player tries to guess the card. To prove that the house indeed picks card at random, it needs to commit to the card ahead by publishing a hash of the card concatenated with some random nonce. After player picks his guess, house can reveal the nonce and show that the card was indeed picked before player made his bet.

> **Comments:**
> **username_1**: I don't see how that solves this problem.  Using your suggestion, the house can commit to the time of the draw, and prove they didn't change it.  But they still know when the draw will occur.  The goal here is that nobody should know when the draw will occur until just before it does.  
> **username_3**: I probably did not understand the problem then, or it is not exactly clear how this lottery operates. I assumed the "when" in "when pot will be split" refers to the condition for winning the pot, not a specific point in time.  

---

