Bitcoin Forum

In a hipotetic game that uses nonces as seed I mean.. would it be OK to use nonces for this purpose?

While you can't predict which nonce is going to be the correct one (ie. a valid nonce for successfully mining a block) a miner could in theory only search for the correct nonce within a given subset of nonces and not necessarily lessen their chance for finding the correct one (eg. the chance to find a valid nonce within the subset of even numbers is as high as the chance of finding a valid nonce within the subset of odd numbers). So at least in theory a miner can manipulate which nonces hit the blockchain. Not sure how viable such an attack would be in practice though.

So making a sum with like 5 block nonces would avoid this possible attack vector I suppose.. I just want to make sure that no one can predict results in a collective game.. Just getting some thoughts

I guess given a proper mangling of the input even a single nonce should be sufficient for most purposes (eg. the SHA256 of a predetermined public server seed + nonce should be unpredictable enough for a single random outcome. A much slower cryptographic hash would likely be preferable though). I'm not sure whether including multiple nonces would up the security level that much (ie. since an attacker would know the other nonces, they could adjust their nonce-"space" accordingly). But like I said, I'm not sure whether such an attack would be viable to begin with.

Good info..

You guys could point me a better option though.. The idea behind this game is to select a winner (or more) from a list of particpants. The game would announce something like: "we are at block 568903 - result at 569000 (using nonces as seeds from block 568996 to 569000)"
Using multiple blocks would avoid nonces comming from only a miner, right?

This way we would have deterministic results from the algorithm.. The problem is the seed origin.. so I thought that nonces could be usefull..

Any thoughts?

hypothetically I could forge game results.. by using nonces, I couldn't

I think there are two commonly used approaches:  The first is to use the block hash instead of the nonce.  This way, it is way harder for a miner to manipulate it - but they still can if the game is worth really a lot of money.  Basically when they have solved a block but do not like the outcome of the game, they can decide to not publish the block and try again.  But that loses them a block reward - so is only worth it if your game is about more money than that.

The second is using a hash commitment - like what @ETFBitcoin proposed above.  You can have all participants of the game create random numbers and publish the hashes.  Then you base your game outcome on some combination of the numbers themselves (which the players have to reveal after everyone published their hash).  This ensures that noone knows the outcome (or can manipulate it) before the hashes are revealed, but also noone can change their number afterwards since that would invalidate the commitment.

I wonder if this could be a self-fulfilling prophecy? As in in the early days some large miners may have done some analysis and found that something like 60% of the nonces were even, which could totally be explained by statistical variance of course but still some large miners may have decided to just look for even nonces based on these findings. This obviously skews the statistics more in favor of even nonces, because more hashrate is only looking for those nonces now. After some time you may find that 90% of the nonces turn out to be even as more and more miners stop looking at odd nonces like some kind of perpetually reinforced superstitious bias. I mean statistics don't lie. ;)

The most probable answer is already given in the quoted StackOverflow thread, namely that most Scrypt mining back in the day was done using GPUs that are big-endian (ie. the way that the GPUs in question worked favored even numbers over odd numbers) [1]. So in theory one should be able to find a correlation between the shift from GPUs to ASICs and an increased equilibrium of odd and even nonces.

[1] https://bitcoin.stackexchange.com/a/24893

This was answered above (https://bitcointalk.org/index.php?topic=5124834.msg50325066#msg50325066)

The miner of block 569000 (in your example) could mine trying to use a nonce that results in an outcome in its favor.

If you published the hash of the block numbers, plus extra "random text" you could avoid this attack vector because only you will know which blocks will be used until you disclose the result. You must include the additional text otherwise someone could brute force the block numbers.

Given all answers, I think it will be better to use random.org :/ thanks, everyone