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?

Improve this question

1 Answer 1

Reset to default
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:

Improve this answer
5
  • 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, 2015 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, 2015 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, 2015 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, 2015 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, 2015 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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