Author

Topic: Using Bitcoin Block Hashes For Random Numbers (Read 1590 times)

sr. member
Activity: 252
Merit: 250

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

Because propaganda says bitcoin is for commerce, but evidence says bitcoin is for gambling.
member
Activity: 63
Merit: 10
Vires in Numeris

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.  Wink
sr. member
Activity: 252
Merit: 250

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?
legendary
Activity: 3472
Merit: 4801
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.
cp1
hero member
Activity: 616
Merit: 500
Stop using branwallets
Quote
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 Tongue

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?
legendary
Activity: 3472
Merit: 4801
Quote
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 Tongue

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.
full member
Activity: 203
Merit: 100
Quote
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 Tongue
legendary
Activity: 2058
Merit: 1452
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.
cp1
hero member
Activity: 616
Merit: 500
Stop using branwallets
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.
full member
Activity: 203
Merit: 100
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?

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

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

Quote
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...
sr. member
Activity: 399
Merit: 250
Damn....
Should not of given that away..... you read it before I deleted it.......
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
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?
newbie
Activity: 17
Merit: 0
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! Smiley

It's a gambling based game that I want to be as fair and transparent as possible.
legendary
Activity: 905
Merit: 1012
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.
legendary
Activity: 2058
Merit: 1452
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.
newbie
Activity: 17
Merit: 0
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?
legendary
Activity: 2058
Merit: 1452
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.
newbie
Activity: 17
Merit: 0
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
Jump to: