Why is a nonce enough to be 64 bits?

Question

As far as I can understand the resulting hash should start with difficulty number of zeroes before a block can be mined. That is: H(HashOfPreviosBlock + nonce) < target but why is a 64 bit number guaranteed to generate

Answer 1

the resulting hash should start with difficulty number of zeroes before a block can be mined.

No, the hash should be less than the target for the mined block to be valid (acceptable to others).

The often repeated "number of leading zeroes" is not the reality.

The difficulty is not a count of leading zeroes and is not used in Bitcoin's assessment of block-hashes.

H(HashOfPreviosBlock + nonce) < target

The block hash is a hash of much more data than that. It includes, for example, the Merkle root and some other items in the block header.

why is a 64 bit number guaranteed to generate

The nonce is a 32 bit number and it isn't guaranteed that there exists a 32-bit value that would generate a hash less than a target. (See links under "Related" at right of web-page)

For many years it has been necessary for miners to vary much more than the nonce. There is ExtraNonce, selection and order of transactions, contents of coinbase transaction, timestamp, etc.

Answer 2

The 4-byte nonce field is not nearly enough.

However, the block hash is a hash of the full block header (80 bytes, see below for reference), not just the previous block hash & nonce.

So what do miners do? They roll other parts of the block header: version and timestamp have some more "free" bits with which they can play, and every time contents of the block template get changed the whole merkle root gets pseudo-randomly updated and effectively allows a new pass over the nonce, version & timestamp bits.

So, in order to not waste the work - the merkle root must be updated often enough, and pools can easily automate this to be independent of user-made TXs: roll some part of the coinbase TX every now and then.

Block Header Format

Field	Length	Format	Description
version	4 bytes	unsigned integer(LE)	The block format version.
previous block hash	32 bytes	block hash(LE)	The hash of the block immediately preceding this block in the blockchain.
merkle root	32 bytes	merkle root(LE)	The merkle tree root of the transactions in the block.
timestamp	4 bytes	unix timestamp(LE)	The epoch timestamp of the block in seconds.
target	4 bytes	compressed target(LE)	The target that the block hash must be below to be valid. This value is determined by the timestamps of previously mined blocks.
nonce	4 bytes	bytes(LE)	A random value that is repeatedly changed during block mining in order to achieve the block hash requirements.

Example, the Bitcoin genesis block header is:

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c

and it hashes to 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. You can get the hash using shell with:

echo '0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c' -n | xxd -r -p | sha256sum | xxd -r -p | sha256sum | cut -b 1-64 | tac -rs '..'; echo

Answer 3

The difficulty is now 1 in 2^68 chance of a correct hash. So 64 bits would not be sufficient either. The number of 0s on the output says how many bits on the input must change effectively.