Quote from: kano on August 18, 2012, 09:55:58 PM

The nonce size in bitcoin is too small - it is 32bits (sorta like MS-DOS saying 640K will always be big enough)
Each piece of work you get from a pool allows you to attempt 2^32 (~4 billion) hashes - i.e. one for each nonce value.

For a single MiniRig, this means that you need to get over 350 pieces of work from the pool per minute.

The hack solution to this, that someone come up with in the past, was to instead edit the time field (roll it forward)
Thus if you add 1 second to the time field, you can then do another 4 billion hashes on the same piece of work you got from the pool (without having to ask for and wait for more work from the pool) since you are now hashing something different.

Thus most pools now support this.
If they don't - get a new pool.

It means you get less work from the pool to do the same amount of hashing.
The E: % value will tell you how much less.
e.g. if you have an E: of 200% that means you are rolling each piece of work you get, on average, once
Thus you are getting half as much work from the pool to do the same amount of hashing.

If a pool doesn't support roll-n-time then perfect "no rolling" E: is 100%

It doesn't reduce the number of shares you have to send back to the pool however.
The pool would have to support high difficulty shares to reduce that also.
But it does reduce the amount of work you request from the pool.

You can add up to 7200 seconds to the time field and bitcoind will still accept it as a valid block solution if you find a block
... thus why the timestamps in the bitcoin blockchain are not to be taken too seriously.

A larger nonce range in bitcoin would solve this correctly, rather than a time hack, however that would require a hard fork, and the bitcoin devs are scared of hard forks coz they do soft forks so badly.

https://bitcointalk.org/index.php?topic=89278.0

Edit:
The other solution (that no doubt, one of which will be used) that are being bandied about are to move the pools work to the miner.
Thus pretty much all the pool will be doing is counting shares.
The miner (or some other program run by the miner) will be doing the work of dealing with longpolls, transaction selection and everything related to that.

If this were to take place, then I would suggest anyone who implements such a solution, also put a fee in the coinbase to cover the work you are doing for the pool .........

Sort of related, I had a different question - is it possible for you guys to do the opposite of how you will grab long poll from a different pool that you have set up if the primary pool does not support it, so that you could add a local bitcoin client to check for blocks that could possibly find a new one before long poll does?

There's no way I'd be the first to think of this, so I just assumed it's not doable, or perhaps not worth doing? Just curious I guess.

edit: typo