As I have stated before and will state again - that's a hack - pure and simple
The problem is (as you said) that the nonce size is too small - good old MSDOS design.
There is space to increase it - even to 128 bits which would certainly last a long way in to the future.
The problem is the bitcoin devs suck at handling soft and hard forks - or more correctly are afraid of ever doing a hard fork and suck at doing soft forks.
Changing the nonce size to correct the true problem is a hard fork.
As for rolling the time forward - the limit is 7200 seconds.
cgminer limits it to 7000 seconds just to be on the safe side ... since who knows what problems people have with their bitcoinds - windows sux at keeping the time reliable and linux has ntp that everyone should have installed but some people forget that little gem.
Edit: as for when to get new work - there's 2 reasons:
1) You ran out of work
2) Your work expired
(again cgminer pre-emptively gets new work of course so you're rigs are not sitting there twiddling their thumbs)
1) already happens very quickly on pools that don't support roll-n-time
2) Is a setting in cgminer - scantime - and other things affect it also
(well there is a 3rd reason - an LP is sent to you that contains new work for a new block)
Topic: Question about mining - (Read 2386 times)
the coinbase tx can contain arbitrary data. It is referred to as the "extra nonce". If you need a new header and no other data has changed you can simply change the arbitrary data in the coinbase field. It is never used for anything by the bitcoin network. It simply servers as a source of extra entropy (and is also used in merged mining - it is what links the bitcoin block to the alt-chain block). One pools has even used the coinbase field to send short messages.
Also the time field doesn't have to be exact. The network will accept blocks with timestamp within 3 hours of the network normal time. So once can "cheat" and simply increment the timestamp field into the future.
Still in current pool setups (except p2pool) the pool server does all the block header computation (including ensuring each miner is working on unique data by setting the coinbase field). When miners can perform 1000x as much work it is going to put 1000x as much load on the pool server. Some clever use of n-time rolling will help but the load increase is going to be large.
One solution is to change how pools talk to miners. Have the miner construct the blockheader locally. The pool simply becomes a mechansim for sharing the reward (p2pool essentially does this now). In hindsight Satoshi should have made the nonce field 64 bit and this would be a complete non-issue. That is never going to change now so we work with what we got.
Also the time field doesn't have to be exact. The network will accept blocks with timestamp within 3 hours of the network normal time. So once can "cheat" and simply increment the timestamp field into the future.
Still in current pool setups (except p2pool) the pool server does all the block header computation (including ensuring each miner is working on unique data by setting the coinbase field). When miners can perform 1000x as much work it is going to put 1000x as much load on the pool server. Some clever use of n-time rolling will help but the load increase is going to be large.
One solution is to change how pools talk to miners. Have the miner construct the blockheader locally. The pool simply becomes a mechansim for sharing the reward (p2pool essentially does this now). In hindsight Satoshi should have made the nonce field 64 bit and this would be a complete non-issue. That is never going to change now so we work with what we got.
Other things can be changed. Don't know wich but timebase and transactions aren't the only thing
Alright, so I guess that's what my question really is: what else can change, and how often. A 1TH/s miner can entire 10minutes of rollntime"s worth of nonce ranges in just over 2 seconds, but you can't calculate a block 10 minutes in advance, can you? Ill look a little more into how the merkle root works, and see if I can figure more of this out. 
Other things can be changed. Don't know wich but timebase and transactions aren't the only thing
So in my quest to understand a little more about how bitcoin hashing actually works, I had a few questions, and was wondering if someone smarter than me could answer. Looking up what rollntime is what got me into this, and I pretty well understand that concept.
I understand a little bit about what the block header contains when it's being hashed. The 3 main variables that change (while trying to find a new block) are the merkle root, timestamp, and nonce.
The merkle root changes when there's a new transaction across the network, correct? How do these changes get pushed to the miner, and how often? I'm assuming the pool does this?
The timestamp changes every second. I understand how rollNtime "moves" the timestamp around to keep the miner busy.
And lastly the nonce range. This changes with every hash.
Now from what I understand, it takes ~4GH/s to hash through the entire nonce range every second. After the first second, the miner moves the timestamp ahead one second, and starts the nonce range over, correct?
What about miners faster than 4GH/s? I'm assuming that since they move through the nonce range faster, they can start on the next timestamp even sooner.
I'm assuming that even 2 BFL MRs together can still be kept 100% busy all the time. By the time it goes through all the nonce ranges for many seconds in advance, the merkle root will have changed, and it starts over?
But doesn't this reach a certain point that makes it harder to keep a miner busy? I'm thinking forward to a 1TH/s ASIC. Lets say the network has a solid minute of no new transactions, so the merkle root stays the same for 60 seconds. A 1TH/s miner could go through the nonce ranges for all 60 seconds in less than 1 second. What does the miner do for the other 59 seconds? Rehash what it's already done? Sit idle waiting for a change to happen on the network?
I'm sorry if none of this makes sense, or if my understanding of how all this works is totally wrong. I am a little tired, and I'm going to bed. Any knowledge you could share with me would be greatly appreciated!
I understand a little bit about what the block header contains when it's being hashed. The 3 main variables that change (while trying to find a new block) are the merkle root, timestamp, and nonce.
The merkle root changes when there's a new transaction across the network, correct? How do these changes get pushed to the miner, and how often? I'm assuming the pool does this?
The timestamp changes every second. I understand how rollNtime "moves" the timestamp around to keep the miner busy.
And lastly the nonce range. This changes with every hash.
Now from what I understand, it takes ~4GH/s to hash through the entire nonce range every second. After the first second, the miner moves the timestamp ahead one second, and starts the nonce range over, correct?
What about miners faster than 4GH/s? I'm assuming that since they move through the nonce range faster, they can start on the next timestamp even sooner.
I'm assuming that even 2 BFL MRs together can still be kept 100% busy all the time. By the time it goes through all the nonce ranges for many seconds in advance, the merkle root will have changed, and it starts over?
But doesn't this reach a certain point that makes it harder to keep a miner busy? I'm thinking forward to a 1TH/s ASIC. Lets say the network has a solid minute of no new transactions, so the merkle root stays the same for 60 seconds. A 1TH/s miner could go through the nonce ranges for all 60 seconds in less than 1 second. What does the miner do for the other 59 seconds? Rehash what it's already done? Sit idle waiting for a change to happen on the network?
I'm sorry if none of this makes sense, or if my understanding of how all this works is totally wrong. I am a little tired, and I'm going to bed. Any knowledge you could share with me would be greatly appreciated!
Jump to: