Stratum V1 Explained: Jobs, Shares and Pool Control

Stratum V1 explained for ASIC operators: follow subscriptions, authorisation, mining jobs, share difficulty, extranonce handling and pool control.

Why Stratum V1 replaced getwork

The earlier getwork approach repeatedly transferred large amounts of work over HTTP and scaled poorly as pooled mining and hashrate grew. Stratum introduced a persistent connection and compact job messages. The pool sends enough block-header and coinbase components for the worker to search many nonce combinations without requesting a new unit of work for every small range.

Start with the validating node, because the ASIC only hashes the candidate header it receives. Record the node release and the pool component that assembled the block. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.

Subscription and worker authorisation

A miner normally opens a TCP connection, calls mining.subscribe and receives subscription details plus extranonce information. It then calls mining.authorize with a worker identity and credential. Authorisation identifies an account for share credit. it does not prove that the endpoint is the intended pool unless the connection and configuration are separately authenticated.

Treat status dashboards as observations, not as the source of truth. Compare them with an independently operated node and retain the raw deployment or template response. Period boundaries, chain reorganisations and cached pool pages can otherwise make a correct-looking percentage describe the wrong state.

What a mining job contains

A mining.notify message supplies a job identifier, previous block hash, coinbase parts, Merkle branches, version, target bits, time and a clean-jobs flag. The miner combines these with its extranonce to construct a coinbase transaction and Merkle root. It then hashes candidate headers while varying nonce, time or permitted version bits.

Build the failure response before the boundary arrives. Define which rejection messages trigger an alert, who can pause a template source and how failover is prevented from returning miners to the same faulty validation stack. A second hostname is not independent when both endpoints share one node.

Shares and pool difficulty

Pools set a share target easier than Bitcoin’s network target so workers submit frequent proofs of work. mining.set_difficulty changes that accounting threshold. A share demonstrates contributed hashrate but is not normally a valid Bitcoin block. If its hash also meets the network target, the pool reconstructs and broadcasts the full block candidate.

Separate readiness, signalling and enforcement in the operating log. Readiness is a claim about software and process, signalling is data carried by blocks, and enforcement is a validation result. Combining them into a single supported or unsupported label hides the point at which revenue is actually at risk.

The role of extranonce

The nonce field alone is too small for large fleets to search indefinitely without duplication. Extranonce values alter the coinbase transaction. This changes the Merkle root and creates a fresh header search space. The pool allocates a unique prefix and tells the miner how many bytes remain. Proxies must preserve uniqueness across all downstream devices.

Map responsibility across the full path: validating node, template server, pool protocol, proxy, firmware and ASIC. For each layer, state what it can alter and what it merely relays. This prevents a version-bit setting in firmware from being mistaken for complete consensus-rule support. Relate that responsibility map to the pool and job-control boundary in our Stratum V2 guide.

What the pool controls

In the normal V1 model the pool’s node and template system select transactions, coinbase outputs and the chain tip. The miner receives a compact job and cannot reconstruct the undisclosed transaction set from the Merkle branches. It can choose a different pool. But it cannot independently change one job’s transactions while retaining that pool’s accounting arrangement.

Test the primary and failover paths with the same checks. Compare chain tip, chainwork, deployment state, required rules and template age, then save the result with a timestamp. The process should be repeatable by another operator without relying on an undocumented pool conversation.

Operational checks for V1 fleets

Record the exact stratum URL, port, account, TLS or tunnel arrangement, difficulty behaviour and failover order. Alert on repeated authorisation failures, stale jobs, duplicate shares, unusual extranonce changes and rising reject rates. Test every backup pool with a small worker, because a syntactically valid endpoint may use a different payout scheme, chain or worker-name format.

Turn the conclusion into a business decision. State which chain and settlement venues the operation intends to serve, the maximum acceptable stale-block exposure and the point at which mining pauses. This connects protocol evidence to electricity cost, pool revenue and payout finality.

Operator decision record

A concise decision record for Stratum V1 explained should name the source documents, their dates, the node release tested, the responsible pool or template provider and the exact trigger for action. Include screenshots or machine-readable output for the deployment state. But keep the raw node response as the stronger evidence.

State whether a change affects policy, block construction or consensus validity, because those layers have different failure costs.

Run the check on every production and failover path. Confirm that monitoring alerts on stale templates, unexpected chain tips, rejected proposals and a rise in stale shares. Keep rollback instructions for node and pool configuration. But do not roll back across an active consensus boundary without understanding the rules the older release enforces.

If the evidence conflicts, pause the affected path and investigate before committing more electricity to uncertain work.

For related background, read our plain-English BIP-110 guide and technical BIP-110 review. Those articles use a modern proposal to show why signalling, activation, template construction and accepted chain history must be examined separately.

Conclusion

Stratum v1 explained is best understood as a defined interaction between validating software, mining infrastructure and economic acceptance. The safest operator does not infer consensus from a dashboard percentage or a pool slogan. They verify the rule source, the activation boundary, the template fields and the chain their payouts ultimately settle on. That discipline reduces the chance of hashing an invalid or commercially unwanted block.