0

These questions are partially inspired from this post on Merkle root hashing by pool operators. My understanding is that for Stratum mining the only hashing the pool has to do is produce the Merkle branch (which has to be done once per block and is the same for all miners in the pool?). My questions are:

  1. On the end device (miner/ASIC) side, (I believe) that the miner has to recompute the Merkle root after changing the extranonce2 field. If I have multiple miners connected to one "mining proxy" that is connected to a mining pool, I assume that each end device produces their own Merkle roots for the changed coinbase transaction and not the mining proxy?
  2. If it is the end devices computing the Merkle roots, is it done on the ASICs themselves or offloaded? The post I linked suggests that it's offloaded, but why - since wouldn't this be slower? Is the next Merkle root precomputed while hashing of the previous header is being performed by the ASIC?
  3. Does anybody have a sense of (roughly) what portion of total SHA256 hashes performed are from Merkle root calculations (not PoW hashes)?

Any help/clarification is appreciated.

2

The post I linked suggests that it's offloaded, but why - since wouldn't this be slower? Is the next Merkle root precomputed while hashing of the previous header is being performed by the ASIC?

It is not noticeably slower because merkle root computations make up a negligible amount of hashes computed. It is likely to implementing faster merkle root computation is simply not worth the extra effort. Keep in mind that the hashing chips of ASICs may not just be dumb SHA256d chips. They maybe implementing other optimizations (such as ASICBoost) or just bundle more operations than just SHA256d so that repurposing them to do merkle root calculations is not possible.

Does anybody have a sense of (roughly) what portion of total SHA256 hashes performed are from Merkle root calculations (not PoW hashes)?

Approximately 0. The number of hashes for merkle root calculations is so small compared to the number of PoW hashes that it is basically 0.

Modern blocks have about 3000 transaction in them. Given n leaves in a binary tree, there are a total of 2n - 1 nodes. When applied to a merkle tree, this means that there are 2n - 1 hashes. So for a full block, that's ~6000 hashes in order to compute the merkle root.

Now consider that the nonce range for a single header has 4294967295 possible values, so 4294967295 hashes to be computed for the PoW. That means that only 0.001% of the hashes computed for a single nonce range were for the merkle root.

Furthermore, the vast majority of those merkle root hashes are being done by the pool server. The miner only needs to do a small portion of them - just the branch involving the coinbase transaction. To make the math easier, let's say our block has 4096 transactions, so the merkle tree has 12 levels. This means that the individual miner will only have to compute 12 hashes after modifying the coinbase with their extranonce, not 8192 hashes. Compared to the total number of hashes for the PoW itself, this is negligible, basically 0.

4
  • This was a super helpful answer, thank you! One other follow up/clarification question: so the pool server only has to perform one set of hashes to produce a merkle branch that will be sent out to all connected miners? Then it will also have to hash a merkle root to validate a share submission (and also perform the hash on the resulting block header), right?
    – jatroy
    Sep 26 at 2:56
  • Yes. The pool server can compute the merkle branches once for all workers since the transaction data is not worker specific. When validating, it will compute the final merkle root so it can hash the block header to check the proof of work.
    – Andrew Chow
    Sep 26 at 4:57
  • I see - thanks for the answer to this. Another question, sorry: how do mining proxies with multiple workers ensure that different workers aren't computing the same hashes? Do they give each of them different extranonce2 values (since extranonce1 values are proxy specific)?
    – jatroy
    Sep 27 at 19:34
  • I am not familiar with the inner workings of pool proxy software so I cannot say for sure. But the most logical thing to do would be to reduce the extranonce2 length and append an additional unique id for each worker to extranonce1. Then when submitting work to the actual pool, the data added to extranonce1 is combined with the extranonce2 to produce an extranonce2 that is valid for the upstream pool.
    – Andrew Chow
    Sep 27 at 22:20

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.