1

When miners connect to the server, they get a "job" message back with a merkle_branch field that has hashes that correspond to transactions that will be included in the block being worked on.

What I'm wondering is, does the pool server bother changing that transaction set very often, or do they just wait for a block to be solved, and only then broadcast a new job with a different list?

In other words, in between block solvings, is everyone in the pool generally working on the same set of transactions?

0

The stratum pool managing software I'm familiar with is https://github.com/zone117x/node-stratum-pool, so I can tell you what they do. Stratum is a protocol, though, so multiple pieces of software could implement it differently.

This parameter is controlled by the blockRefreshInterval in the config. Every blockRefreshInterval milliseconds, the stratum server checks the bitcoin core node, via RPC, for new blocks using getblocktemplate. If there hasn't been a new block since the last time getblocktemplate was called, then it sets the current job, which is returned to all new requests for work.

The polling interval suggested in the config is every 1 second. Miners may request work at very different rates as well, so some may be working on older work. As long as it's work for the next block, it's considered valid though. The pool does use the same node and mempool data to build blocks, though. So, given all these variables, miners most likely won't be working on the exact same transaction set.

Relevant bits of code:

  • Ok, thanks this is good stuff. From what I see initially (might take me a while to digest this) processTemplate will just return false if the block hasn't changed. So I'm still missing where the data gets refreshed if the block hasn't changed. Seems like it will keep the same data unless the block changes, which means all miners would be working on the same job essentially, and the same set of txs. I'll keep looking at it though. – Fraggle Dec 15 '15 at 3:41
  • Now that I look at it again, I think you're right. This seems like a poor strategy, though, because newer transactions wouldn't get mined. It could be done intentionally, if it had some benefit for miners, but I don't see any benefits off hand. The regular get block template polling seems to only use the result if there has been a new block. Maybe we should open a github issue about this. – morsecoder Dec 16 '15 at 14:51
  • Judging by their commit log and un maintained issues list, though, I don't think it will do any good. You might try looking at github.com/int6/CoiniumServ or github.com/slush0/stratum. – morsecoder Dec 16 '15 at 14:58
  • Needless to say, the way it SHOULD work in any decently implemented stratum server is that you regularly check for new transactions (so that new transactions get mined), and update the current job to be given out from here forward (until a new block is found). Any work done for any jobs given out that build on the most recent block are valid. So, in the expected behavior, miners would not be mining on exactly the same transaction set most of the time. – morsecoder Dec 16 '15 at 15:06
  • 1
    Ok, thanks. I'm going to mark this as the answer. I think with the comments above it provides enough info. Also of course there are other stratum pool implementations that may work differently than this code base. So ultimately maybe figuring out what the top mining pools are doing is what I really need to do. – Fraggle Dec 17 '15 at 16:12

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.