ViaBTC | Mining Pool Difficulty Adjustment Explained: Share Difficulty vs. Bitcoin Network Difficulty

Mining Pool Difficulty Adjustment Explained: Share Difficulty vs. Bitcoin Network Difficulty

2026-10-07 16:50

Introduction

The phrase "mining pool difficulty adjustment" is often used loosely, and that looseness causes confusion. In practice it refers to two distinct mechanisms that share related mathematics but solve different problems. Bitcoin's network difficulty is a consensus rule enforced by every full node; it recalculates the proof-of-work target every 2,016 blocks to keep long-run block production near ten minutes per block. A mining pool's share difficulty, by contrast, is a pool-side parameter that controls how often a connected miner submits a valid share. Adjusting share difficulty does not change Bitcoin's network difficulty, an ASIC's physical hashrate, or its power draw. This article separates the two concepts, explains Bitcoin's network retarget calculation and the principles behind pool share-difficulty adjustments, and describes how ViaBTC's documented share-difficulty settings work in practice.

Bitcoin Network Difficulty: The Consensus-Level Mechanism

A Bitcoin block is valid only when its hash value is numerically at or below the network's current target. A lower numerical target is harder to satisfy and therefore corresponds to higher difficulty. Difficulty itself is expressed as a ratio:

Difficulty = (difficulty-1 target) / (current target)

Because difficulty moves inversely to the target, a falling target means rising difficulty, and vice versa.

Bitcoin recalculates this target every 2,016 blocks. The protocol compares how long the preceding 2,016-block interval actually took against the reference timespan of 1,209,600 seconds (14 days), then adjusts the target proportionally:

New target = Old target × (actual timespan / target timespan)

The actual timespan is measured from the timestamp of the first block to the timestamp of the last block in the interval, which technically spans 2,015 block intervals rather than 2,016, though the reference timespan used in the formula remains fixed at 1,209,600 seconds. Bitcoin Core also bounds the actual timespan to between one-quarter and four times the reference value before applying the formula, which limits any single retarget to roughly a 300% increase or a 75% decrease in difficulty (Bitcoin Core, pow.cpp).

This periodic, network-wide retarget is the only process that changes Bitcoin's actual mining difficulty. As a dated illustration: Mempool.space recorded a difficulty increase of 4.16% on September 19, 2026, raising difficulty to 132.76T, followed by a 0.03% decrease on October 3, 2026, bringing it to 132.72T (Mempool.space mining dashboard, snapshot October 6, 2026). The sequence shows that difficulty does not move only upward and that each adjustment reflects the full preceding 2,016-block period rather than any single day's hashrate.

What Is Share Difficulty in a Mining Pool?

Waiting for an individual ASIC to find a full Bitcoin block would make it impractical for a pool to measure a miner's contributed work, since a single device might go long stretches without meeting the network target. To solve this, pools assign each connection an easier share target—numerically higher than, and therefore easier to meet than, the Bitcoin network target. A result that meets this share target is called a share.

Most shares do not meet the much harder network target and are not valid Bitcoin blocks. Occasionally, a submitted share also happens to satisfy the network target; if the resulting block is otherwise valid, it becomes a block candidate. This is the mechanism by which pooled miners occasionally find blocks despite each individual share representing only a fraction of the work needed (Bitcoin Developer Guide, Mining).

Shares serve as verifiable, frequent evidence of work performed, which a pool uses to estimate a connection's contributed hashrate and to apply its payout accounting.

Why Pools Adjust Share Difficulty

A pool's objective in setting share difficulty is not to change a miner's expected long-run share of rewards; it is to manage a practical rate of share submissions for each connection.

A higher assigned share difficulty produces fewer shares on average, with each valid share representing more expected work.
A lower assigned share difficulty produces more frequent shares, with each valid share representing less expected work.

This trade-off exists because a pool needs enough shares to estimate hashrate and apply payout rules reliably, without flooding its infrastructure with unnecessary submissions from high-hashrate devices.

Many pools use variable difficulty, often called VarDiff, to adjust share difficulty according to the observed share-submission rate. If shares arrive faster than the desired rate, the pool raises difficulty; if they arrive too slowly, it lowers difficulty within its configured limits. The desired submission rate and adjustment timing depend on the pool's implementation; there is no universal pool retarget formula or requirement to wait 2,016 blocks (VarDiff explanation).

Protocol-level support for this kind of control exists in Stratum V2, where the upstream server can specify a mining target for each channel and send a SetTarget message to change that target and regulate the rate of successful submissions (Stratum V2 specification).

Does a Pool Difficulty Change Affect Earnings?

Changing share difficulty does not directly alter an ASIC's physical hashrate, its power consumption, or Bitcoin's network difficulty. What it changes is the frequency and size of the individual accounting units (shares) a pool uses to estimate the connection's work.

This distinction matters for interpreting dashboards. If share difficulty rises while hashrate, uptime, and acceptance conditions remain unchanged, fewer accepted shares are expected per unit time, because each share now represents more work. Actual counts can fluctuate over short periods. Comparing raw share counts across periods with different assigned difficulties, or across miners with different settings, does not produce a meaningful comparison. Actual reward outcomes depend on the total accepted work over time, the pool's payout method, Bitcoin's network difficulty, pool fees, and the specific accounting rules in force—not on the raw count of shares submitted.

With the same hashrate, uptime, and acceptance conditions, a pool that credits shares according to their assigned difficulty should not reduce expected long-run rewards merely because share difficulty changes. Higher difficulty produces fewer, more heavily weighted shares, which can make accepted-work measurements over short periods more variable. How this affects short-term credited earnings depends on the payout method and accounting window (ViaBTC, Pool Hashrate and Mining Statistics Explained).

Configuring Share Difficulty on ViaBTC

ViaBTC's documentation allows miners to set two share-difficulty parameters directly in the mining software's password field: d for initial difficulty and md for minimum difficulty. For example, a configuration of d=2000,md=1000 requests an initial share difficulty of 2,000 upon connection, while md=1000 establishes a floor below which the pool will not assign a lower difficulty, even if the connection's apparent hashrate is low.

These parameters define a starting value and a lower limit; neither specifies a fixed difficulty for the entire session. If the minimum difficulty is too high relative to the connection's hashrate, qualifying shares become sparse. With fewer samples, short-term pool-estimated hashrate can fluctuate more even when the ASIC operates steadily. This is a reason to consider the sampling period when evaluating the result.

ViaBTC also publishes a practical guideline for selecting an initial value:

Recommended difficulty = Hashrate (TH/s) × 1,000

This is ViaBTC's own configuration recommendation for setting a reasonable starting point, not a Bitcoin protocol rule or an industry-wide standard. Both d and md affect how frequently a given connection submits qualifying shares to ViaBTC; they do not alter Bitcoin's network difficulty or the ASIC's physical hashrate (ViaBTC Help Center, Configure Mining Difficulty).

How to Monitor the Result

After changing share-difficulty settings, first check the difficulty actually assigned to the connection. Then compare several distinct data sources over matching periods, accounting for uptime:

The ASIC's own local hashrate reading, taken from the device's firmware or management interface.
The pool's estimated hashrate for that connection, which ViaBTC derives from accepted work over a defined window rather than reading directly from the device (ViaBTC, Pool Hashrate and Mining Statistics Explained).
Accepted and rejected share counts, keeping in mind that rejected shares is the umbrella category, with stale, invalid, and duplicate submissions as possible subcategories depending on the pool's classification.

Because local hashrate, pool-estimated hashrate, and share counts are measured differently and often over different windows, a short-term change in one of them should not be treated as conclusive evidence of a hardware or connectivity problem on its own.

FAQ

Is pool share difficulty the same as Bitcoin network difficulty?

No. Bitcoin network difficulty is a consensus parameter recalculated every 2,016 blocks and applies to the entire network. Pool share difficulty is a connection-level setting a pool uses to control how often a miner submits valid shares; it has no effect on the Bitcoin protocol.

Does raising pool share difficulty reduce mining rewards?

Not directly. With unchanged hashrate, uptime, and acceptance conditions, and accounting that weights accepted shares by their assigned difficulty, raising share difficulty should not reduce expected long-run rewards by itself. It produces fewer shares representing more work each, so short-term accepted-work measurements may fluctuate more. Credited earnings also depend on Bitcoin network difficulty, the payout method, fees, and the accounting window.

Why did my accepted share count fall?

First check whether the difficulty actually assigned to the connection increased. If it did, fewer accepted shares are expected over equal periods at the same hashrate, uptime, and acceptance rate. A lower count can also reflect random variation, less uptime, lower hashrate, or more rejected submissions. Check assigned difficulty, pool-estimated hashrate, local hashrate, uptime, and rejection information over matching periods before attributing the change to a particular cause.

Can pool share difficulty change while a miner stays connected?

Yes. Pools using VarDiff adjust a connection's share difficulty during an active session based on the observed share-submission rate, within the pool's configured limits. The desired rate and adjustment timing depend on the implementation.

What do the `d` and `md` parameters do on ViaBTC?

On ViaBTC, d sets the initial share difficulty requested at connection, and md sets a minimum difficulty floor for that connection, as documented in ViaBTC's Help Center guidance on configuring mining difficulty.

References

How to Choose a Mining Pool With Anti-DDoS Protection

What 24/7 Customer Support Really Means for a Mining Pool