Using Bitcoin Block Hashes For Random Numbers

[BitFanatic]

When a new Bitcoin block is mined, a hash of the solution is released.

E.g. Latest block hash: 000000000000007f27d49d588367eee58184bc720e8fcf653b415e808dbe6450

How possible/safe would it be to use these numbers as a secure/verifiable random result?

For example in a raffle type game, could the numbers quite safely be taken from the block hash and be considered random?

Surely unless the SHA-256 hash function broke this would be fine?

Thanks

[grue]

You might want to take the hash of the block and concatenate it with some arbitrary string, then hash it once more to get more randomness. A block hash alone has a bias towards lower numbers.

[BitFanatic]

You might want to take the hash of the block and concatenate it with some arbitrary string, then hash it once more to get more randomness. A block hash alone has a bias towards lower numbers.

What's the reason behind the bias to lower numbers with a block hash?

[grue]

What's the reason behind the bias to lower numbers with a block hash?

For the block to be accepted, the block hash has to lower than a certain number (varies by difficulty). That is the principle behind mining. If you check the previous block hashes on blockexplorer, you will see all blocks have plenty of leading zeros.

[maaku]

Well that's simple enough, just take the low-order bits. For your application you may or may not require a salt.

The idea works; whether it is a good idea or not depends on your application.

[BitFanatic]

Well that's simple enough, just take the low-order bits. For your application you may or may not require a salt.

The idea works; whether it is a good idea or not depends on your application.

It will be coming soon!

It's a gambling based game that I want to be as fair and transparent as possible.

[Remember remember the 5th of November]

Hashes are NOT random.... nor do they contain 'random' bits.

I have collected significant meta data examples of them coalescing into 'groups' , Iv'e not had any luck on generating a formula, but there ARE definite semi-predictable patterns.

It's not really useful from the point of reducing nonce search ranges (because by the time you have run the calculations to do an exclusion, you could have just searched the range)

Also since you would be using data that is publicly available to generate random numbers.......... need I say more...

If you want random numbers, then there are better systems.

I knew they were predictable, I just knew it. Would you be able to share some more information on this as well?

[razorfishsl]

Damn....
Should not of given that away..... you read it before I deleted it.......

[Killdozer]

There isn't really any practical reason for this. Even if the unpredictability of block hashes is probably very high, the random bits are just produced very slowly from it. It depends on how fast you need the bits, but for any real cryptographic applications it will surely be to slow. And most OS provide faster facilities for this, like recording exact times of hardware interrupts or using specialized hardware which is built into some newer computers. Your solution would require a constant internet connection for a very slow stream of random bits which are not available on demand, but depend on when the network produces a new block. For what advantage?

Hashes are NOT random.... nor do they contain 'random' bits.

Hash functions are NOT random. Hash values of each block of bitcoin are because they are based on the block data which depends on the behavior of the whole network.
Your "research" about hypothetical prediction of hashes is just nonsense, it would mean that the hash function has a vulnerability, and finding a vulnerability in a known trusted cryptographic hash is VERY big news. It's like you were saying you found a way to break RSA (not as big, but you get the magnitude). So either provide proof or I call bullshit.

because by the time you have run the calculations to do an exclusion, you could have just searched the range

That basically means that your coalescing groups don't provide any useful information.

Also since you would be using data that is publicly available to generate random numbers.......... need I say more...

It's just a matter of hashing those values with a salt. It would not provide anyone any possibility to predict the effect of those random values in his application. And since the values are still random, it would work. It's just not practical, there are too few bits generated...

[cp1]

It's better to just take a random number if you want a random number.  You can release the hash ala satoshi dice before hand.

[grue]

It's better to just take a random number if you want a random number.  You can release the hash ala satoshi dice before hand.

read the fucking post. he says he wants it to be provably fair. A black box RNG is not.

[Killdozer]

read the fucking post. he says he wants it to be provably fair. A black box RNG is not.

"release the hash ala satoshi dice before hand" IS provably fair. You are the ingnorant one here, not him

[DannyHamilton]

read the fucking post. he says he wants it to be provably fair. A black box RNG is not.

"release the hash ala satoshi dice before hand" IS provably fair. You are the ingnorant one here, not him

No. It's not.

I could create a raffle where I know what the result will be ahead of time.  I could tell the result to my friends so that we would win every round.  I could then hash the pre-determined result and "release the hash".  After play was over, I could release the result to prove by way of the hash that the result wasn't modified after the beginning of the game.  Unfortunately, this would not be a "fair" game.

Releasing the hash is only one part of a provably fair game.  It prevents the game operator from changing the result after the game begins, but it does not prevent the game operator from knowing the result before the beginning of the game and taking advantage of that result.  This is why Satoshi Dice uses a hashed secret combined with the transactionID.  Satoshi Dice cannot know the transactionID before the transaction is submittted, and the player cannot know the secret before the day is over.

[cp1]

read the fucking post. he says he wants it to be provably fair. A black box RNG is not.

"release the hash ala satoshi dice before hand" IS provably fair. You are the ingnorant one here, not him

No. It's not.

I could create a raffle where I know what the result will be ahead of time.  I could tell the result to my friends so that we would win every round.  I could then hash the pre-determined result and "release the hash".  After play was over, I could release the result to prove by way of the hash that the result wasn't modified after the beginning of the game.  Unfortunately, this would not be a "fair" game.

Releasing the hash is only one part of a provably fair game.  It prevents the game operator from changing the result after the game begins, but it does not prevent the game operator from knowing the result before the beginning of the game and taking advantage of that result.  This is why Satoshi Dice uses a hashed secret combined with the transactionID.  Satoshi Dice cannot know the transactionID before the transaction is submittted, and the player cannot know the secret before the day is over.

I assumed you would combine your secret hash with the entrant's transaction ID as well to determine the winner -- what else would you do?

[DannyHamilton]

I assumed you would combine your secret hash with the entrant's transaction ID as well to determine the winner -- what else would you do?

That's not what you said.

You said, "It's better to just take a random number if you want a random number."

Without specifying where you would get that random number, you implied that the OP should just use a RNG such as openssl RAND_SSLeay(void);

If you had meant that the OP should use a hash of a combination of transactionID and a secret, and that the hash of the secret should be released prior to the beginning of the game, you'd have avoided a lot of confusion and people correcting you by just saying so in the first place.

[Shevek]

It's a gambling based game that I want to be as fair and transparent as possible.

Why the words "bitcoin" and "gambling" are closed one to the other so often?

[leijurv]

It's a gambling based game that I want to be as fair and transparent as possible.

Why the words "bitcoin" and "gambling" are closed one to the other so often?

Because SatoshiDice. 

[Shevek]

It's a gambling based game that I want to be as fair and transparent as possible.

Why the words "bitcoin" and "gambling" are closed one to the other so often?

Because SatoshiDice. 

Because propaganda says bitcoin is for commerce, but evidence says bitcoin is for gambling.