Why is the block nonce only 32 bits?

[vector76]

Wouldn't it make more sense for the nonce to be bigger, since 32 bits can be exhausted much faster than the average block time?

[1715266909]

1715266909

[1715266909]

1715266909

[1715266909]

1715266909

[1715266909]

1715266909

[1715266909]

1715266909

[1715266909]

1715266909

[Meni Rosenfeld]

Doesn't matter much, after the nonce is exhausted the merkle root is changed (via the extranonce). But I agree it would make more sense to have it longer, it could decrease the overhead and doesn't seem to have serious disadvantages.

[ribuck]

... it would make more sense to have it longer, it could decrease the overhead ...

Surely a longer nonce would increase the overhead, because more bytes must be processed on every hashing attempt.

[wumpus]

I might be wrong here, but I don't think it makes much difference either way. Either you have to hash 4 bytes extra per try, or you have to do an entire block re-hash every 2^32 tries.

Also, as it is a proof of work, there is no real reason to make it easier / reduce the overhead per try...

[Pieter Wuille]

The block header is 80 bytes, which is padded to 128 bytes. The first 64 bytes of these are processed outside of the nonce-iteration loop. Whether there are 4 or 8 variable bytes in the second 64 bytes makes hardly any difference,  i believe. Maybe a few % on very optimized implementations.

[Meni Rosenfeld]

... it would make more sense to have it longer, it could decrease the overhead ...

Surely a longer nonce would increase the overhead, because more bytes must be processed on every hashing attempt.

That's not overhead, that's just a uniform increase in hashing difficulty which has no effect.

I'm thinking mostly about the communication complexity between mining pools and participants. Bigger nonce = less getwork requests.

Also, as it is a proof of work, there is no real reason to make it easier / reduce the overhead per try...

There is a reason to make it not harder for honest miners than for attackers.

Anything which improves the efficiency in practice, without changing the theoretical maximum an attacker can achieve, is welcome. Attackers will probably run large datacenters and not be effected much by the things I refer to as "overhead".

[vector76]

... it would make more sense to have it longer, it could decrease the overhead ...

Surely a longer nonce would increase the overhead, because more bytes must be processed on every hashing attempt.

From my understanding, getwork has to be called more frequently because of the small nonce.

Perhaps a modified getwork2 could send part of the merkle tree with a blank extranonce.  Then the worker could fill in the extranonce with a random value, to generate their own work units.  Then they wouldn't have to hit the server every 4GH.  If collisions were a problem, each worker could be given a range for extranonce.

Having the workers increment the timestamp is also an option, but above 4GH/s this is not enough by itself.

A pool could use a higher share difficulty to reduce the rate that shares are generated, but I don't think it would decrease the load on the pool server much, because the getwork requests occur at least once per 4GH regardless of the share difficulty.

It would be nice if pool operators could tune the share difficulty to be higher with more variance and lower server load, vs lower share difficulty for less variance and higher server load.

[Meni Rosenfeld]

It would be nice if pool operators could tune the share difficulty to be higher with more variance and lower server load, vs lower share difficulty for less variance and higher server load.

I'd say we're nowhere near the point where this is worth the additional complexity and confusion, in particular with regards to scoring. People have a hard enough time understanding how shares should be scored as it is.

[gentakin]

Having the workers increment the timestamp is also an option, but above 4GH/s this is not enough by itself.

There's X-Roll-NTime for that, if my understanding is correct. (Some pools refuse to use it, because it apparently opens up a cheating possibility or causes stale shares...?)

For more than 4ghash/s, you would usually have multiple workers anyway.