Bitcoin Forum
December 04, 2016, 04:18:21 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Why is the block nonce only 32 bits?  (Read 1509 times)
vector76
Member
**
Offline Offline

Activity: 70


View Profile
July 15, 2011, 11:09:32 AM
 #1

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?
1480825101
Hero Member
*
Offline Offline

Posts: 1480825101

View Profile Personal Message (Offline)

Ignore
1480825101
Reply with quote  #2

1480825101
Report to moderator
1480825101
Hero Member
*
Offline Offline

Posts: 1480825101

View Profile Personal Message (Offline)

Ignore
1480825101
Reply with quote  #2

1480825101
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480825101
Hero Member
*
Offline Offline

Posts: 1480825101

View Profile Personal Message (Offline)

Ignore
1480825101
Reply with quote  #2

1480825101
Report to moderator
Meni Rosenfeld
Donator
Legendary
*
expert
Offline Offline

Activity: 1890



View Profile WWW
July 15, 2011, 11:32:22 AM
 #2

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
July 15, 2011, 12:06:06 PM
 #3

... 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
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
July 15, 2011, 12:20:36 PM
 #4

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

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
July 15, 2011, 12:22:38 PM
 #5

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Meni Rosenfeld
Donator
Legendary
*
expert
Offline Offline

Activity: 1890



View Profile WWW
July 15, 2011, 01:30:55 PM
 #6

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

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
vector76
Member
**
Offline Offline

Activity: 70


View Profile
July 15, 2011, 01:33:42 PM
 #7

... 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
Legendary
*
expert
Offline Offline

Activity: 1890



View Profile WWW
July 15, 2011, 01:37:44 PM
 #8

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
gentakin
Member
**
Offline Offline

Activity: 98


View Profile
July 15, 2011, 01:48:51 PM
 #9

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.

1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!