Just how difficult is mining (indie miners please give us data)

[99bitcoins]

This is a question for those hardcore miners. We hear about GPUs becoming less and less useful for mining and considering they can easily do around a billion hashes per second, this raises a few questions for me:

• How many hashes does it take on average to find a block with current (or recent) difficulty?
• What percent of the time do you reach max nounce and have to alter something else?
• Which part of the block do you alter most often?

[DeathAndTaxes]

1)
Avg hashes per block = (difficulty ) * (2^32)
right now difficulty = 3,304,356 so that is ~14.192 quadrillion hashes per block.

2)
100% of time.  The nonce field is only 32 bit (why Satoshi?  64 bit nonce would have made things so much more elegant).
32 bit = 4 billion values = an average GPU will complete a nonce range in about 10-30 seconds.  A major pool (~1TH/s) will collectively attempt 232 nonce ranges per second.

3)
There is an extra nonce field in the coinbase.  It is simply arbitrary data.  It can be incremented to produce an infinite number of block headers with otherwise identical information.  All of this is handled internally by either bitcoind (solo mining) or the pool server (pool mining).

[BurtW]

I have heard that the new ASIC miners will go through the nonce field in about 70 milliseconds.  Did not do the calculation myself but that is pretty darn fast.

[99bitcoins]

Some BIG numbers there. I just came accross this bit of info about what a simple hashing procedure would look like here and it goes like...

1.Request a new Getwork from a given pool/bitcoind with specified credentials
2.For nonce=0;nonce<0xFFFFFFFF;nonce++
   • Set Getwork Data nonce
   • SHA-256 hash the Getwork Data (block header)
   • Check if hash result is smaller than Getwork Target, if so, submit a share
   • If more than 1 second passed since you received Getwork, stop the loop
3.GOTO: 1


Why is he saying "If more than 1 second passed since you received Getwork, stop the loop?"

[99bitcoins]

I realized I just derailed my own thread 

[DeathAndTaxes]

Some BIG numbers there. I just came accross this bit of info about what a simple hashing procedure would look like here and it goes like...

1.Request a new Getwork from a given pool/bitcoind with specified credentials
2.For nonce=0;nonce<0xFFFFFFFF;nonce++
   • Set Getwork Data nonce
   • SHA-256 hash the Getwork Data (block header)
   • Check if hash result is smaller than Getwork Target, if so, submit a share
   • If more than 1 second passed since you received Getwork, stop the loop
3.GOTO: 1


Why is he saying "If more than 1 second passed since you received Getwork, stop the loop?"

Well that is a "simple" hashing procedure, no current mining software works that way.  Part of the blockheader include the timestamp.  The timestamp doesn't need to be exact so there is no reason to not run the entire nonce range and return any found shares.

With X-Roll-NTime the local miner software can increment the timestamp for a period of time further reducing the number of getworks needed.  In theory if X-Roll-NTime was set to say 300 sec, the local miner could continually update the block header until it gets a longpoll (notification of change in blockheader -usually because new block is found).  IIRC most pools use a more conservative n-time-rolling value of say 10-30 sec.

[99bitcoins]

Well that is a "simple" hashing procedure, no current mining software works that way.  Part of the blockheader include the timestamp.  The timestamp doesn't need to be exact so there is no reason to not run the entire nonce range and return any found shares.

With X-Roll-NTime the local miner software can increment the timestamp for a period of time further reducing the number of getworks needed.  In theory if X-Roll-NTime was set to say 300 sec, the local miner could continually update the block header until it gets a longpoll (notification of change in blockheader -usually because new block is found).  IIRC most pools use a more conservative n-time-rolling value of say 10-30 sec.

Ok so what he's talking only applies to pool mining then.

[DeathAndTaxes]

Well that is a "simple" hashing procedure, no current mining software works that way.  Part of the blockheader include the timestamp.  The timestamp doesn't need to be exact so there is no reason to not run the entire nonce range and return any found shares.

With X-Roll-NTime the local miner software can increment the timestamp for a period of time further reducing the number of getworks needed.  In theory if X-Roll-NTime was set to say 300 sec, the local miner could continually update the block header until it gets a longpoll (notification of change in blockheader -usually because new block is found).  IIRC most pools use a more conservative n-time-rolling value of say 10-30 sec.

Ok so what he's talking only applies to pool mining then.

No what he is talking about applies to nothing.   It is a "simple" mining algorithm.  No mining software uses.   Production mining software use optimizations like being loose with timestamp, using ntime rolling, checking for more than one share per nonce, nonce-range splitting (to improve response time - GPU are non-responsive while hashing a nonce range), etc.  All of these are used regardless of if you are solomining or pool mining.

Real code is far more complex.  What as presented was just a simplified version.  It would work but it isn't optimal.

You seem to think solo-mining is different than pool mining.  They really aren't.  In solo-mining you are communicating directly to your bitcoind but you still request work and return found blocks.  In pool mining you are making the same communications but with a pool server and you also return "shares" (low difficulty hashes) which acts as proof of work in addition to any found blocks.

[99bitcoins]

You seem to think solo-mining is different than pool mining.  They really aren't.  In solo-mining you are communicating directly to your bitcoind but you still request work and return found blocks.  In pool mining you are making the same communications but with a pool server and you also return "shares" (low difficulty hashes) which acts as proof of work in addition to any found blocks.

The reason I though it would apply to poolmining only is because I assume pools need to make sure makesure the same nounces/hashes are not done by multiple workers thus wasting resources. Therefore requiring this polling every second and special steps. So there is a flaw in his example then.

PS: sorry it's hard to express yourself very well when typing this at work looking over the shoulder for boss; where we're not supposed to be on forums

[DeathAndTaxes]

You seem to think solo-mining is different than pool mining.  They really aren't.  In solo-mining you are communicating directly to your bitcoind but you still request work and return found blocks.  In pool mining you are making the same communications but with a pool server and you also return "shares" (low difficulty hashes) which acts as proof of work in addition to any found blocks.

The reason I though it would apply to poolmining only is because I assume pools need to make sure makesure the same nounces/hashes are not done by multiple workers thus wasting resources. Therefore requiring this poling and special steps.

PS: sorry it's hard to express yourself very well when doing this at work where we're not supposed to be on forums

A solo miner needs to ensure they always attempt to hash unique block headers also (no duplication of work).  However that is handled by the bitcoind (for solo mining) or the pool server (for pool mining).  The mining software is relatively dumb.  If bitcoind or pool server asks it to hash the hash block header 1000 time it will despite 999 of those being duplicated wasted work.

[hardcore-fs]

2)
100% of time.  The nonce field is only 32 bit (why Satoshi?  64 bit nonce would have made things so much more elegant).
32 bit = 4 billion values = an average GPU will complete a nonce range in about 10-30 seconds.  A major pool (~1TH/s) will collectively attempt 232 nonce ranges per second.

I would have to say this is quite frequently not  true......, just out of interest I have been running some analysis.... with a specially modified FPGA bit file

Here we have the SAME base nonce round and same initial base hash, and TWO shares very close.(take into account indian)

accepted share 2ad74038 (difficulty 1.65070)
accepted share d5c79238 (difficulty 22.59623)

These were issued within a few uS of each other. (yep... Microsecond NOT Millisecond)

I have quite a lot of these in an hour, I wanted to see just how 'random' the distributions were and to see if there were any optimizations possible......