BitFanatic (OP)
Newbie
Offline
Activity: 17
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 10:27:12 PM |
|
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
Legendary
Offline
Activity: 2058
Merit: 1434
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 10:34:42 PM |
|
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 (OP)
Newbie
Offline
Activity: 17
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 10:38:38 PM |
|
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
Legendary
Offline
Activity: 2058
Merit: 1434
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 10:41:51 PM |
|
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
Legendary
Offline
Activity: 905
Merit: 1012
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 11:36:07 PM |
|
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.
|
I'm an independent developer working on bitcoin-core, making my living off community donations. If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
|
|
|
BitFanatic (OP)
Newbie
Offline
Activity: 17
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 11:47:27 PM |
|
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](https://bitcointalk.org/Smileys/default/smiley.gif) It's a gambling based game that I want to be as fair and transparent as possible.
|
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2013, 01:12:25 PM |
|
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?
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
razorfishsl
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2013, 01:15:43 PM |
|
Damn.... Should not of given that away..... you read it before I deleted it.......
|
|
|
|
Killdozer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2013, 03:10:39 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2013, 03:15:55 PM |
|
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
Legendary
Offline
Activity: 2058
Merit: 1434
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2013, 08:12:47 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2013, 10:49:01 PM |
|
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](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4796
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2013, 12:41:50 AM |
|
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](https://bitcointalk.org/Smileys/default/tongue.gif) 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2013, 03:54:23 AM |
|
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](https://bitcointalk.org/Smileys/default/tongue.gif) 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
Legendary
Offline
Activity: 3472
Merit: 4796
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2013, 04:40:55 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2013, 10:45:29 AM |
|
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?
|
Proposals for improving bitcoin are like asses: everybody has one 1SheveKuPHpzpLqSvPSavik9wnC51voBa
|
|
|
leijurv
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 63
Merit: 10
Vires in Numeris
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2013, 02:10:47 PM |
|
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](https://bitcointalk.org/Smileys/default/wink.gif)
|
Firstbits 1Leijurv. Or, if you like cats, Firstbits 1Kittens and 1catcat as well. If you're a chemist, also 1Helium, 1Erbium, 1Copper, 1Cerium, and 1Nickel. If you like numbers, 123four, 12234, 12three. Keybase and onename user: leijurv.
|
|
|
Shevek
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 26, 2013, 04:10:02 PM |
|
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](https://bitcointalk.org/Smileys/default/wink.gif) Because propaganda says bitcoin is for commerce, but evidence says bitcoin is for gambling.
|
Proposals for improving bitcoin are like asses: everybody has one 1SheveKuPHpzpLqSvPSavik9wnC51voBa
|
|
|
|