<p>Only sort of. The transaction hash is specifically chosen <em>because</em> it is smaller than some number X (--> difficulty factor), so it isn't fully random. However, it has a lot of entropy in the sense that it contains input from a lot of different, not predictable transactions. So you could use this hash as a seed for your RNG.</p>

<p>If you just want to generate lotto numbers and dice rolls, I'd say it's more important that you find a good random number generator (RNG) - you won't reseed that often anyway.</p>

<p>If you wanted to use the hash as the random number directly, there's a problem: you only get one hash every ~10 minutes. Not all that many random numbers.</p>

CC BY-SA 3.0
2017-11-29T19:20:51.043Z
See my [**Python implementation**](https://gist.github.com/dhimmel/809c3e3a3bd4d6d637a0b4aa1a062dae) to derive a random probability from a predetermined block height. This enables untrusted parties to use the Bitcoin blockchain as a cryptographic beacon, by just agreeing to a future block height.

See also [On Bitcoin as a public randomness source](https://eprint.iacr.org/2015/1015.pdf) and this [related video](https://www.coursera.org/learn/cryptocurrency/lecture/0IDbs/bitcoin-as-randomness-source).
Daniel Himmelstein
CC BY-SA 4.0
2022-04-16T05:39:53.930Z
With Bitcoin Core, you only get one block hash every 10 minutes, but a block is composed of - with block height prefix - *unique* transaction hashes. SHA256 sliding ngrams on this data do appear to be uniformly frequent.
Wes Turner
CC BY-SA 3.0
2011-08-30T21:57:30.917Z
2011-08-30T21:57:30.917Z
Mononofu
<p>If I may answer with my stack overflow hat on...</p>

<p>Here's how I'd draw a random number in way that no participant can influence the result of. </p>

<p>Invite each player to pick a random number, x, and publish the hash(x). Once each hash has been published, each player should then reveal their x. With those x's, add them all together and hash the result. Use that final hash as the random value.</p>

<p>UPDATE: To work around the attack described in the comment below, use two rounds.</p>

<ol>
<li>Each player selects a randon number, x, and reveals hash(x).</li>
<li>When all hashes have been revealed, each player reveals x.</li>
<li>All x's are combined and hashed. y=hash(all x)</li>
<li>Each player selects a new random number, z, and reveals hash(y+z).</li>
<li>When all of the second round of hashes have been revealed, each player reveals z.</li>
<li>All z's are combined and hashed. The result is used as the random value.</li>
</ol>

<p>If the player has a prepared hash collision, they could only use it to select their prefered y value. This doesn't help because they would now need a way to find a collision where both inputs have the same prefix (y) which won't be known in advance. If you can do that in a timely manner, we all need a new hash function.</p>

<p>(I welcome comments. Its possible I've missed something else.)</p>

CC BY-SA 3.0
2011-09-16T22:26:19.490Z
An attacker could find a hash collision where hash(a) = hash(b), publish the common hash value, and then observe the other players' revealed numbers before choosing whether to reveal a or b.
JGWeissman
CC BY-SA 3.0
2011-09-22T18:37:08.250Z
@JGWeissman - I missed that. Thank you. I've updated the protocol to work around that issue. (Or maybe I've made it worse.)
billpg
CC BY-SA 3.0
2011-09-22T19:51:27.233Z
Now an attacker with a hash collision on a and b can reveal in step 4 that hash(y+z) is the common hash of a and b, and then in step 5 choose to reveal either that z = a-y or that z = b-y.
JGWeissman
CC BY-SA 3.0
2011-09-22T19:52:24.343Z
So, in step 4, require also that each player reveals hash(z).
JGWeissman
CC BY-SA 3.0
2011-09-23T23:47:32.730Z
Ah, by + I meant concatenation, rather than addition. Anyway, I suggest we move this discussion to a different SE. I've taken the liberty of opening this Q. 
http://crypto.stackexchange.com/questions/767/how-to-fairly-produce-a-random-number-between-game-players-wihout-trusted-third-p
billpg
CC BY-SA 3.0
2011-10-09T03:15:08.183Z
@JFWeissman.  There is no known collision attack for SHA-256.  As long as a cryptographically secure hash is being used your attack is theoretical only.
DeathAndTaxes
CC BY-SA 3.0
2011-09-16T20:57:21.623Z
2011-09-22T18:36:23.430Z
2011-09-22T18:36:23.430Z
billpg
<p>You could scrape data from <a href="http://bitcoincharts.com/bitcoin/" rel="nofollow">http://bitcoincharts.com/bitcoin/</a> to get the hashes of transactions that had just been submitted.  It wouldn't super easy to do, but it'd be a constant source of fairly random data.</p>

CC BY-SA 3.0
2011-08-30T21:57:53.247Z
2011-08-30T21:57:53.247Z
tysat
<p>The <a href="https://bitcointalk.org/index.php?topic=9812.0" rel="noreferrer">Bitcoin Lottery</a> used an SHA256 hash of the two most recent blocks to generate random data and to my recollection there were not too many complaints about that method they chose. In any case it's only good for 256 bits of questionably random data every 10 minutes (20 if you don't reuse blocks) so there are probably better entropy sources, such as the setup they've built over at <a href="http://www.random.org/" rel="noreferrer">random.org</a></p>

CC BY-SA 3.0
2012-10-25T08:39:48.253Z
Actually a correct random implementation with Mersenne Twister would suffice. If people get paid, they don't care much about how do you generate the numbers. Joe Six Pack wants his price, not to know.
flaab
CC BY-SA 3.0
2011-09-06T20:25:38.097Z
And here, "questionably random" means that given a suitably large reward and a suitably motivated miner this would **absolutely** be gamed.
eMansipater
CC BY-SA 3.0
2011-08-30T22:04:03.027Z
2011-08-30T22:04:03.027Z
David Perry
<p>I want to create a transparent gambling/lotto site and use the block chain as entropy for lotto numbers, dice rolls, that kind of thing.  Would the transaction hash of the latest transaction be the best way to do this?  How often are transaction hashes created?  How would you, programmatically, access them?  </p>

CC BY-SA 3.0
2011-09-02T21:08:15.227Z
wouldn't "impractical" be up to me?  The question is not about how to implement a gambling site, it's about using the blockchain as entropy.  The use of it is irrelevant, it's still a valid question.    And random.org doesn't solve all my problems.
browep
CC BY-SA 3.0
2011-09-06T20:23:10.237Z
It may be a valid question, but it's not a particularly bitcoinish one--smells more like programming technique to me, which should go on [Stack Overflow](http://stackoverflow.com/).
eMansipater
CC BY-SA 3.0
2011-08-30T23:06:10.250Z
This feels slightly off topic.
ripper234
CC BY-SA 3.0
2011-09-01T21:01:37.980Z
why off-topic? from the FAQ: " practical, answerable questions based on actual problems that you face".  Seems pretty on-topic unless I am missing something.
browep
CC BY-SA 3.0
2011-09-02T06:55:24.667Z
because it would be impractical to use Bitcoin for entropy in a gambling site. There are other easier ways to do this today. http://www.random.org/
ripper234
<block-header><blockchain>
Is there a way to use the block chain as entropy in random number generator?
browep
# Is there a way to use the block chain as entropy in random number generator?

(Asked by: username_0 on 2011-08-30)

I want to create a transparent gambling/lotto site and use the block chain as entropy for lotto numbers, dice rolls, that kind of thing. Would the transaction hash of the latest transaction be the best way to do this? How often are transaction hashes created? How would you, programmatically, access them?

**Tags:** block-header, blockchain

> **Comments:**
> **username_2**: This feels slightly off topic.  
> **username_0**: why off-topic? from the FAQ: " practical, answerable questions based on actual problems that you face".  Seems pretty on-topic unless I am missing something.  
> **username_2**: because it would be impractical to use Bitcoin for entropy in a gambling site. There are other easier ways to do this today. http://www.random.org/  
> **username_0**: wouldn't "impractical" be up to me?  The question is not about how to implement a gambling site, it's about using the blockchain as entropy.  The use of it is irrelevant, it's still a valid question.    And random.org doesn't solve all my problems.  
> **username_1**: It may be a valid question, but it's not a particularly bitcoinish one--smells more like programming technique to me, which should go on [Stack Overflow](http://stackoverflow.com/).  

---

## 4 answers

### Answer by username_10 on 2011-08-30. Score: 8 | Accepted answer

The [Bitcoin Lottery](https://bitcointalk.org/index.php?topic=9812.0) used an SHA256 hash of the two most recent blocks to generate random data and to my recollection there were not too many complaints about that method they chose. In any case it's only good for 256 bits of questionably random data every 10 minutes (20 if you don't reuse blocks) so there are probably better entropy sources, such as the setup they've built over at [random.org](http://www.random.org/)

> **Comments:**
> **username_1**: And here, "questionably random" means that given a suitably large reward and a suitably motivated miner this would **absolutely** be gamed.  
> **username_11**: Actually a correct random implementation with Mersenne Twister would suffice. If people get paid, they don't care much about how do you generate the numbers. Joe Six Pack wants his price, not to know.  

---

### Answer by username_3 on 2011-08-30. Score: 2

Only sort of. The transaction hash is specifically chosen *because* it is smaller than some number X (--> difficulty factor), so it isn't fully random. However, it has a lot of entropy in the sense that it contains input from a lot of different, not predictable transactions. So you could use this hash as a seed for your RNG.

If you just want to generate lotto numbers and dice rolls, I'd say it's more important that you find a good random number generator (RNG) - you won't reseed that often anyway.

If you wanted to use the hash as the random number directly, there's a problem: you only get one hash every ~10 minutes. Not all that many random numbers.

> **Comments:**
> **username_4**: See my [**Python implementation**](https://gist.github.com/dhimmel/809c3e3a3bd4d6d637a0b4aa1a062dae) to derive a random probability from a predetermined block height. This enables untrusted parties to use the Bitcoin blockchain as a cryptographic beacon, by just agreeing to a future block height.  See also [On Bitcoin as a public randomness source](https://eprint.iacr.org/2015/1015.pdf) and this [related video](https://www.coursera.org/learn/cryptocurrency/lecture/0IDbs/bitcoin-as-randomness-source).  
> **username_5**: With Bitcoin Core, you only get one block hash every 10 minutes, but a block is composed of - with block height prefix - *unique* transaction hashes. SHA256 sliding ngrams on this data do appear to be uniformly frequent.  

---

### Answer by username_6 on 2011-09-16. Score: 1

If I may answer with my stack overflow hat on...

Here's how I'd draw a random number in way that no participant can influence the result of.

Invite each player to pick a random number, x, and publish the hash(x). Once each hash has been published, each player should then reveal their x. With those x's, add them all together and hash the result. Use that final hash as the random value.

UPDATE: To work around the attack described in the comment below, use two rounds.

1. Each player selects a randon number, x, and reveals hash(x).
2. When all hashes have been revealed, each player reveals x.
3. All x's are combined and hashed. y=hash(all x)
4. Each player selects a new random number, z, and reveals hash(y+z).
5. When all of the second round of hashes have been revealed, each player reveals z.
6. All z's are combined and hashed. The result is used as the random value.

If the player has a prepared hash collision, they could only use it to select their prefered y value. This doesn't help because they would now need a way to find a collision where both inputs have the same prefix (y) which won't be known in advance. If you can do that in a timely manner, we all need a new hash function.

(I welcome comments. Its possible I've missed something else.)

> **Comments:**
> **username_7**: An attacker could find a hash collision where hash(a) = hash(b), publish the common hash value, and then observe the other players' revealed numbers before choosing whether to reveal a or b.  
> **username_6**: @username_7 - I missed that. Thank you. I've updated the protocol to work around that issue. (Or maybe I've made it worse.)  
> **username_7**: Now an attacker with a hash collision on a and b can reveal in step 4 that hash(y+z) is the common hash of a and b, and then in step 5 choose to reveal either that z = a-y or that z = b-y.  
> **username_7**: So, in step 4, require also that each player reveals hash(z).  
> **username_6**: Ah, by + I meant concatenation, rather than addition. Anyway, I suggest we move this discussion to a different SE. I've taken the liberty of opening this Q.  http://crypto.stackexchange.com/questions/767/how-to-fairly-produce-a-random-number-between-game-players-wihout-trusted-third-p  
> **username_8**: @JFWeissman.  There is no known collision attack for SHA-256.  As long as a cryptographically secure hash is being used your attack is theoretical only.  

---

### Answer by username_9 on 2011-08-30. Score: 0

You could scrape data from <http://bitcoincharts.com/bitcoin/> to get the hashes of transactions that had just been submitted. It wouldn't super easy to do, but it'd be a constant source of fairly random data.


---

