Hashes are random, what if?

[Artlav]

This probably belongs to development forum, but lots have changed here over the last year apparently...
Two questions about network logic.

Can anyone explain to me why this scenario cannot happen:
The hashes are practically random, for every block there is 32 bit of nonce and 32bit of timestamp.
Can it happen so that none of 18446744073709551616 hashes that would be generateable from this set of variables would be below the target?
It sounds like a freak of luck for that to happen, is this considered or is deemed too unlikely?


Second, in practical terms, does this put a limit on generation rate at roughly 4.2 Ghash/s?
Once all the nonce is tried, the timestamp must be incremented, but a second is not done yet.

With network rate of ~10Thash/s, does that mean that there is a lot of redundant tries?
With deviation in time spread about +-5 minutes that's still 600 possible sets of 4.2 Ghash/sec domains, naturally with lots of repeats.
What have i missed?

[willphase]

there is always a solution to the hash, it's a characteristic of the algorithm used.

Will

[Artlav]

Ok, then what about the times and rate limits?

[kuloch]

I have not yet received an answer to my own question thread (which would allow me to answer with more certainty).  However, I think I have a bit of a grasp on how it works.  Just take what I say with the appropriate grain of salt.

The contents of the block that you are trying to hash (below the target difficulty) is constantly changing, with every new transaction and/or block that is validated.  So even under the (highly unlikely, I think) possibility that some static block text does *not* have any hash value that would match the current difficulty, your miner will update it with the current information as it comes in through the peer network.

So it is not possible to get "stuck" forever.  It is, however, highly possible for you to never (or not for a long time, at least) be the lucky one to find a current hash and get it published before someone else does.

Regarding your second question, there is likely to be a *lot* of redundancy across the entire BitCoin network, given the nature of brute forcing hashes.  Although I would expect that mining pool servers try to minimize redundancy within their own pool.

I'm not quite sure what format BitCoin uses for its timestamps, but most computers use milliseconds (since the Unix epoch) rather than seconds.  Either way, I don't think this matters.  Even if a given mining pool some day has the computational resources to calculate all possible nonce hashes (which would be practically guaranteed to find a hit), everything suddenly changes as soon as the pool server receives a publication of a new block or transaction.

[willphase]

I have not yet received an answer to my own question thread (which would allow me to answer with more certainty).  However, I think I have a bit of a grasp on how it works.  Just take what I say with the appropriate grain of salt.

The contents of the block that you are trying to hash (below the target difficulty) is constantly changing, with every new transaction and/or block that is validated.  So even under the (highly unlikely, I think) possibility that some static block text does *not* have any hash value that would match the current difficulty, your miner will update it with the current information as it comes in through the peer network.

So it is not possible to get "stuck" forever.  It is, however, highly possible for you to never (or not for a long time, at least) be the lucky one to find a current hash and get it published before someone else does.

this is correct. I'll have a look at your question thread now...

Will

[Maged]

There's also an extraNonce in the generation transaction.

[Comepradz]

Could you explain more about extraNonce? 

[theymos]

extraNonce is a number stored in the generation transaction. Whenever it's updated, you get a new Merkle root in the header. It's incremented every time the regular nonce overflows.

[Comepradz]

So from what we discussed, the first scenario is "unlikely" to happen because there are 2^96 (or 79228162514264337593543950336) possible hash take from 32 bit Nonce + 32 bit extraNonce + 32 bit timestamp. And if bitcoin really uses unix timestamp format, it will not limit hash generation at roughly 4.2 GHash/s, it is likely be limited at (2^96)/1000 or approximately 79.23 YottaHash/s, and it is a waaay bigger than our current capacity.

Correct me if I'm wrong

[theymos]

extraNonce is variable-length, so the number of unique blocks is almost endless.