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?
closed as off topic by ripper234, eMansipater, Chris Acheson, Dori Sep 21 '11 at 0:51
Questions on Bitcoin Stack Exchange are expected to relate to Bitcoin within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.
The Bitcoin Lottery 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
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.
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.
- Each player selects a randon number, x, and reveals hash(x).
- When all hashes have been revealed, each player reveals x.
- All x's are combined and hashed. y=hash(all x)
- Each player selects a new random number, z, and reveals hash(y+z).
- When all of the second round of hashes have been revealed, each player reveals z.
- 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.)
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.