Mining Job (Stratum)

A mining job is the packet of work a pool sends to a connected miner over the Stratum protocol. Delivered via the mining.notify message, it tells the machine exactly what to hash without shipping the full block. Each job carries a job ID, the previous block hash, the two halves of the coinbase transaction (coinb1 and coinb2) that the miner splices its extranonce between, the merkle branch needed to rebuild the merkle root, the block version, the encoded difficulty bits, the timestamp, and a clean-jobs flag. The elegance of the design is compression: the pool has already chosen the transactions and built the template, so the job contains only the variable parts, a few hundred bytes standing in for a block that may weigh megabytes.

How a miner uses a job

On receiving a job, the machine splices its assigned extranonce into the gap between the coinbase halves, hashes the completed coinbase, and folds it up through the supplied merkle branch to recompute the merkle root, no knowledge of the actual transactions required. It then assembles the 80-byte header and begins rolling the nonce through its full 32-bit range. Because a modern ASIC exhausts four billion nonces in a fraction of a second, the machine extends the search space by incrementing its extranonce portion (changing the coinbase, hence the merkle root) and, on modern hardware, by rolling permitted bits of the version field, a technique negotiated as version rolling. Results that clear the pool's share threshold go back via mining.submit with the job ID, extranonce2, timestamp, and nonce; a share that also clears the network target is a full block solution.

Clean jobs and job turnover

Jobs are perishable. When a new block arrives on the network, the pool immediately issues a job with the clean-jobs flag set, ordering miners to abandon in-flight work, every further hash on the old previous-block-hash is wasted effort on a stale tip, and shares submitted against expired job IDs are rejected. To shave latency at these moments, pools often push an empty or near-empty job first (a valid template with minimal transactions) so hashrate lands on the new tip instantly, then follow with a full fee-rich template seconds later. Between blocks, fresh jobs without the flag arrive periodically to update timestamps and fold in newly arrived fee-paying transactions; miners can finish current work before switching.

Jobs in Stratum V2

Stratum V2 keeps the job concept but rebuilds it as compact binary messages with a sharper separation of concerns: NewMiningJob carries the work definition while SetNewPrevHash separately activates jobs against a new chain tip, which allows future jobs to be distributed ahead of time and activated the instant a block is found. More fundamentally, with the Job Declaration Protocol a miner can declare a transaction set built by its own node rather than passively accepting whatever the pool's job contains, converting the job from an instruction into a negotiation. Whichever protocol carries it, the work a job represents ultimately derives from a node's block template, and who builds that template is one of the live decentralization questions in mining.

Jobs are also the unit of pool accounting. The pool assigns each connection a share difficulty, tuned automatically by variable-difficulty (vardiff) logic so that a machine submits a steady trickle of shares, enough to measure its hashrate accurately, not so many that the pool drowns in traffic. Every accepted share is a statistical receipt proving work was performed against a specific job, and payout schemes are built on counting them. When a miner shows a high stale or rejected share rate, the cause is almost always job-related: network latency delivering jobs late, a machine grinding old jobs after a clean-jobs flag, or clock drift pushing timestamps outside the job's permitted window.