# nTime rolling is just an optimization for large/fast pools, correct?

Need to confirm my understanding of nTime rolling...

It's used to give the miner more options to mine without needing to request more work from the pool, by incrementing the timestamp. However, given a sufficiently small pool, where the nonce space isn't even covered for any given block, nTime rolling has no significant advantage. You can scale the miners nonce range so that each miner is efficiently using bandwidth and time. And Because you're not covering the entire nonce space anyway, the scaling of a miners nonce range is all that is necessary to optimize efficiency.

As a follow-up, I guess it's perfectly possible that the entire nonce space produces zero valid nonces, and therefore you must increment the timestamp to ensure you have a chance, but just as before - for sufficiently small pools this doesn't come into play.

Is this understanding correct?

Is this understanding correct?

Basically, but you've failed to account for the small size of the header nonce space (32 bits) and the speed of modern hardware (on the order of 10 terrahashes per second per miner).

A 32 bit nonce can only provide 2 ** 32 = ~4 billion combinations. That corresponds to 4 gigahashes. A single modern miner can do more than a thousand times in half a second, so the nonce space is almost always exhausted without finding a block.

When Bitcoin hash rate was first increasing through the FPGA and early ASIC eras, nTime rolling was implemented so that miners didn't have to make significant changes to their hardware and software to deal with the problem of nonce space exhaustion. However, that hack of a solution was increasingly less useful the faster hardware got, as a typical block can only move time around in a range of about two hours (3,600 one-second increments) and sometimes much less than that (this is especially the case when other miners are using nRollTime as they can use up the acceptable time values available to subsequent miners).

The correct solution was to put an extra nonce in the coinbase field of the generation transaction[1], something that was actually implemented in the original Bitcoin 0.1 software. Changing any transaction in the block also changes the 256-bit merkle root in the block header, eliminating the risk of nonce space exhaustion. This technique is now universally used by Bitcoin miners and usually implemented directly in the hardware (I think usually using a small FPGA for the extra nonce updates and merkle root regeneration).

[1] The coinbase field currently allows miners to add up to 96 arbitrary bytes without affecting any protocol features. The company Coinbase is named after this field but has no other relationship to it.

• Excellent answer. Extra props for the additional info about the proper coinbase field solution. FWIW, the hashing algorithm I'm mainly focused on is cryptonight, which contains these same concepts, but per my understanding the potential hashing rate of modern hardware is slightly lower. I know the nTime rolling feature is already implemented for CN mining pools, but it's not quite as critical as for ASIC mine-able coins. Theory applies to both though. Thanks! – The Shoe Shiner Jun 5 '18 at 16:43