Nice, so GetBlockTemplate gives the worker some decision power over the block contents, allowing him to change some details every time the nonce overflows. And as a bonus, it allows workers to be sure they're not working on something "evil" or against their interests. A decision-power decentralization in centralized pooled mining. Neat solution.
Thanks kjj.
Topic: Doubt about mining: frequent batches of work (Read 1005 times)
GBT & Stratum
Ok, I just read about the extraNonce field on the wiki. That's what's changed when the nonce overflows.
Do workers have their hands on this extraNonce?
EDIT:
Just found this:
Allowing the worker to manipulate the timestamp might help, but if the timestamp is in seconds, I'm afraid that might not be enough. According to this page, BFL claims its MiniRig will be capable of calculating 1,5*1012 h/s. Rounding 1000 to 1024 (210), that would make something close to 1,5*240 h/s. It would overflow the nonce 256 times per second! (if I haven't made any mistakes on these powers there)
It's true that if the worker can change the timestamp every second, it only needs to request the amount of work it's capable of processing in one full second. For the next second, it can change the timestamp and repeat everything again...
Or is the timestamp in milliseconds?
Anyway, how will (have?) people solve(d) this?
Do workers have their hands on this extraNonce?
EDIT:
Just found this:
So it requires at least one getwork per 2^32 hashes (1 share). To make it a little more complex there is a method called n-time-rolling which allows the miner to simply increment the time locally. This allows multiple runs through the nonce range on one getwork request.
Allowing the worker to manipulate the timestamp might help, but if the timestamp is in seconds, I'm afraid that might not be enough. According to this page, BFL claims its MiniRig will be capable of calculating 1,5*1012 h/s. Rounding 1000 to 1024 (210), that would make something close to 1,5*240 h/s. It would overflow the nonce 256 times per second! (if I haven't made any mistakes on these powers there)
It's true that if the worker can change the timestamp every second, it only needs to request the amount of work it's capable of processing in one full second. For the next second, it can change the timestamp and repeat everything again...
Or is the timestamp in milliseconds?
Anyway, how will (have?) people solve(d) this?
Please correct me on what I"m wrong.
AFAICT, a mining pool assembles a block, generate its header, and give the header to its workers. The workers will try to calculate a hash for that header that beats the current share difficulty by changing the value of the nonce. Whenever the nonce is exhausted, they attempt a different block. Pools may change the block header as much as they like simply by generating a new address for coinbase, they don't depend on waiting for new transactions nor rearranging them.
The nonce is only 32 bits long. We can assume that ASIC devices will be able to calculate 232 hashes very quickly.
Wouldn't that mean too much upload bandwith will be required from pools? Not to mention the capacity to generate lots of different headers quite fast.
I confess I'm quite ignorant on mining since I don't mine myself, so it's quite possible that this problem is already solved, and I'm not aware about it.
For example, do pools allow their workers to change the header themselves, by rearranging part of the transactions for example? That would increase the size of individual messages sent because at least some transactions plus Merkle branches would need to be sent back and forth, but it could certainly decrease the frequency that the worker needs to get new work from the pool. It could decrease the required bandwidth after all...
AFAICT, a mining pool assembles a block, generate its header, and give the header to its workers. The workers will try to calculate a hash for that header that beats the current share difficulty by changing the value of the nonce. Whenever the nonce is exhausted, they attempt a different block. Pools may change the block header as much as they like simply by generating a new address for coinbase, they don't depend on waiting for new transactions nor rearranging them.
The nonce is only 32 bits long. We can assume that ASIC devices will be able to calculate 232 hashes very quickly.
Wouldn't that mean too much upload bandwith will be required from pools? Not to mention the capacity to generate lots of different headers quite fast.
I confess I'm quite ignorant on mining since I don't mine myself, so it's quite possible that this problem is already solved, and I'm not aware about it.
For example, do pools allow their workers to change the header themselves, by rearranging part of the transactions for example? That would increase the size of individual messages sent because at least some transactions plus Merkle branches would need to be sent back and forth, but it could certainly decrease the frequency that the worker needs to get new work from the pool. It could decrease the required bandwidth after all...
Jump to: