Stratum Jobs and clean_jobs

A miner spends its time hashing work the pool can invalidate at any moment. Understanding that mechanism explains why perfectly computed shares end up stale, and where to act to lose fewer of them.

What a Stratum job is

Stratum is the usual protocol between the machine's controller and the pool server. The server sends a job, meaning the pieces of a block template: version, previous block hash, coinbase parts, Merkle branches, nBits, nTime, extra-nonce. Firmware builds an 80-byte header, rolls the nonce and then the extra-nonce, and submits any proof that beats the share target.

The job is not the block. It is an invitation to search one specific space. While the job is current, hashes count. The moment it stops being current, hashing on it produces dead work, labelled stale or rejected depending on the pool.

Clean job: drop the work in progress

Some messages carry a clean_jobs flag, or its equivalent in that protocol version. It means one thing: abandon previous jobs immediately. The template changed in a way that invalidates the search space already open, typically a new block with a new prevhash, sometimes a rebuilt template.

Without that flag, the pool can add work while still accepting older jobs. With it, the machine has to switch. Firmware that ignores the flag, or drains its queue too slowly, keeps submitting into a network state that no longer exists.

That behaviour is not tunable from your hall: it depends on pool policy and the embedded agent. What you can observe is that after a block, every machine on the same VLAN receives the new job and drops the old one within the same second.

The five causes of invalidation

• A new block on the network. Prevhash changes, and any job built on the old parent is dead.
• A new template on the pool side. The pool rebuilds its candidate with different fees, different transactions, or a different extra-nonce. Same height, different Merkle root, so a different contract.
• A share difficulty change. The pool's meter moves, and hashing against the old target produces out-of-contract shares.
• A server switch or failover. Another stratum server uses different job ids. Submitting an old id to the new socket generates an identity reject, unrelated to the state of the hashboards.
• Network path latency. The longer it takes to receive the new job and drop the old one, the larger the fraction of time spent off-template. VPN, Wi-Fi, saturated NAT, distant peering, or an overloaded controller CPU all act on that delay.

Block arrival stays a random process: a clean can land seconds after the previous one. A run of closely spaced stales does not by itself indicate a fault.

What you actually control

Block arrival and pool policy are out of your hands. Four levers belong to you:

• Point of presence. Check the stratum URL the machines actually use, and pick the geographically closest point of presence the pool offers.
• Link quality. Cable for the control plane, avoiding Wi-Fi and powerline, which add latency variance nothing downstream compensates for.
• One failover at a time. Two agents mining the same worker in parallel produce duplicates and identity rejects.
• Effective application of the new job. Job id and height are visible in the miner interface or logs: after a block, they have to change.

Always compare machines over the same window and the same pool. If one unit stays stuck on an old job id while its neighbours have switched, the problem belongs to that unit or its network segment.

Holding a dead job longer improves no count: shares submitted against it are refused whatever their quality. The only gain available sits in the switching delay, so in the network path and in the firmware.