How is work distributed among members of a pool?

Regarding the block hashing algorithm and valid hashes of a new node, how is the set of solutions for nonces "distributed" among miners?
Is a nonce, for example, tried out multiple times by different miners in the pool? Or do miners split the space of solutions among each other, each working with a limited and mutually exclusive range of nonces?

  • 1
    In general the work is distributed such that the same work is never done twice, as that would simply be a waste. Note however that it can be done as a way to check the honesty of the miner: send him some work that the pool operator already knows should have a solution very quickly and check that the miner actually responds with that solution.
    – Jannes
    May 7 '15 at 10:50
  • 1
    @Jannes: checking honesty this way doesn't really work anymore since work distribution is now done by giving the miner a template for work (stratum and getblocktemplate protocols). The miner is no longer given specific work (as with the old getwork protocol).
    – Dr.Haribo
    May 8 '15 at 8:25

The pool's mining server gives each miner a template to use for generating blocks. When the server wants to update which transactions are included or which block to build upon it will push a new template to each miner.

To generate work for itself the miner is allowed to change the nonce, the timestamp and the extranonce.

The nonce is just a 32-bit number with no special meaning. All possible nonce values are quickly scanned by modern bitcoin ASIC hardware, so with the same timestamp and extranonce you only have a tiny amount of work.

The extranonce is part of the generation transaction, the transaction that generates new coins, which is the first transaction in the block. The extranonce has no special meaning.

The server must never send out the same block template twice, to ensure that the same work is not done multiple times. In the stratum protocol the extranonce is split in extranonce 1 and extranonce 2. Extranonce 1 belongs to the server and is in a part of the block template that the miner is not allowed to modify. To prevent sending the same work twice the server must never reuse the same extranonce 1 value unless something else (that is not modifiable by the miner) in the template has changed. For example the other (non-generation) transactions, or the previous block (the block we are building upon). As part of the template the server will tell the miner how large the extranonce 2 should be, usually 4 bytes. When the miner has tried all possible nonce values it can generate new work by changing the extranonce 2 value.

The timestamp (known as ntime) can also be useful to generate work. This can reduce the work load on a slow controller feeding work to fast ASIC chips. The controller only has to generate enough work to keep the ASICs busy for 1 second, using different extranonce 2 values. After that the ntime can be incremented by 1 every second and the same extranonce 2 values reused. This is known as "roll ntime" or "roll time", as the ntime field of the block is rolled forward. The ntime value can also be incremented every second for the purpose of more exact timestamps on blocks without reusing extranonce 2 values.

In this way the server and client cooperate to generate work and the same block is never hashed twice.

  • Thanks for your answer! One thing is still not clear to me: "In this way the server and client cooperate to generate work and the same block is never hashed twice." - By "the same block", do you mean the same block header hash or do you mean another valid child block with a different hash is never created? Because in the case of a forking between a selfish and an honest subchain, there's a chance of forking on the honest pool's subchain, isn't it? May 8 '15 at 11:18
  • You never want to hash the same block twice (redo the same work), so you must always change some part of the block either in the header or in the set of transactions.
    – Dr.Haribo
    May 9 '15 at 10:48

To clarify this first, header h which is hashed by miners using double SHA256 is a summation of version v, previous block's hash pb root hashof r, time t, bits b which is the target (difficulty) in addition to a nonce.
Keep in mind that the nonce is not a really big number. In fact a fast ASIC miner can test all different values in a nonce. But there are other dynamic attributes like t which gives a new set of possibilities for a nonce every second and also root hash r which is the hash of all transactions in merkle root. Depending on how you sort the transactions it makes different roots.
Depending on the pool, the pool organizer should try not to waste its miners effort by making the most out of it efficiently. So by changing the position of transactions, pool organizer can make different r which can also make different works for its miners. Additionally transactions that are added every second can also change r.

  • I was under the impression that updating extraNonce was the more common way for pool operators to alter the merkle root— see this SE answer. May 7 '15 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.