Is it known that every block CAN produce a hash under target?

[rayt5]

I'm not super knowledgeable about Bitcoin's internal workings, so sorry if this is a silly question:

Could there exist a block whose hash is above the target for every possible value of the nonce? If so, what would happen? Would mining of new blocks just halt for 2 weeks until the difficulty adjusts the target to something above what is possible?

[1714639281]

1714639281

[1714639281]

1714639281

[1714639281]

1714639281

[gmaxwell]

for every possible value of the nonce? If so, what would happen?

Only there is only about one valid nonce in 8,974,296 candidate blocks now. Meditate on this and you will be enlightened.

[Schleicher]

Would mining of new blocks just halt for 2 weeks until the difficulty adjusts the target to something above what is possible?

Since not only the nonce but also the timestamp and the transactions could be changed it's almost impossible that there is no hash smaller than the target.

[DannyHamilton]

I'm not super knowledgeable about Bitcoin's internal workings, so sorry if this is a silly question:

Could there exist a block whose hash is above the target for every possible value of the nonce? If so, what would happen? Would mining of new blocks just halt for 2 weeks until the difficulty adjusts the target to something above what is possible?

The merkle root changes everytime the transaction selection changes (or transaction order).  The timestamp changes. The coinbase transaction changes the address(es) that is pays out to.

All the miners in the entire network aren't all working on the exact same block.

[Etlase2]

The merkle root changes everytime the transaction selection changes (or transaction order).  The timestamp changes. The coinbase transaction changes the address(es) that is pays out to.

All the miners in the entire network aren't all working on the exact same block.

As gmax alluded to, this is all irrelevant. The nonce itself is part of the block. If the block's hash does not fall under the target difficulty, a new hash (read: block) is created by changing the nonce. I think the OPs question is more "given a set of transactions and a single timestamp, is it possible that all 64-bit nonce values could be exhausted without finding a hash that beats the difficulty?" and the answer has to be yes, or the hashing algorithm is suspect. But the odds of this are definitely related to the difficulty, somebody better with math than me would have to work that out.

[Zeilap]

Greg's point is this:

At the minimum difficulty, the average number of hashes required to find a block is 2³². The nonce field is 32 bits (surprise!) , so on average, each candidate block will have exactly 1 nonce to make it under the target.

The current difficulty is 8,974,296, which means that on average 8,974,296 times more hashes are required to find a block than at the minimum difficulty, so for each block there is a 1 in 8,974,296 chance of there existing a nonce making it under the target.  Put another way, we have to try all 2³² nonces for 8,974,296 different blocks on average to find a valid block.

This number is about 2²³, so we only need to have 23 or so more bits other than the nonce that we can change in order to find a valid block.

[wheatstone]

At the minimum difficulty, the average number of hashes required to find a block is 2³². The nonce field is 32 bits (surprise!) , so on average, each candidate block will have exactly 1 nonce to make it under the target.

The nonce overflows all the time, hence the use of the ExtraNonce field in the coinbase.

[TierNolan]

I think the OPs question is more "given a set of transactions and a single timestamp, is it possible that all 64-bit nonce values could be exhausted without finding a hash that beats the difficulty?"

The nonce is actually only 32 bits, so the difficulty is the number of times you need to update the extra nonce.

In the coinbase there is a 100 byte nonce, so you have  2^832 options.  However, some of those bytes have been assigned.  The first few encode the distance from the block to the root, so the options is slightly reduced.

Every 4 billion hashes, you need to update the extra nonce, which requires rehashing the merkle tree from coinbase to root.

[wheatstone]

Every 4 billion hashes, you need to update the extra nonce, which requires rehashing the merkle tree from coinbase to root.

There's also the timestamp field in the header, which can also be updated (and doesn't change the merkle root).

[TierNolan]

There's also the timestamp field in the header, which can also be updated (and doesn't change the merkle root).

True, unless you have better than 4 GH/s, updating the time-stamp allows the nonce to be reset faster than it is used up.