Why is the block nonce only 32 bits?

gentakin

member

Activity: 98

Merit: 10

Quote from: vector76 on July 15, 2011, 08:33:42 AM

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.

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: vector76 on July 15, 2011, 08:33:42 AM

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.

vector76

member

Activity: 70

Merit: 18

Quote from: ribuck on July 15, 2011, 07:06:06 AM

Quote from: Meni Rosenfeld on July 15, 2011, 06:32:22 AM

... 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

donator

Activity: 2058

Merit: 1054

Quote from: ribuck on July 15, 2011, 07:06:06 AM

Quote from: Meni Rosenfeld on July 15, 2011, 06:32:22 AM

... 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.

Quote from: wumpus on July 15, 2011, 07:20:36 AM

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".

Pieter Wuille

legendary

Activity: 1072

Merit: 1181

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.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

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...

ribuck

donator

Activity: 826

Merit: 1060

Quote from: Meni Rosenfeld on July 15, 2011, 06:32:22 AM

... 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.

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

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.

vector76

member

Activity: 70

Merit: 18

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?

Topic: Why is the block nonce only 32 bits? (Read 1729 times)