Bitcoin Cash Difficulty Adjustment: What SHA-256 Miners Need to Understand
2026-10-18 09:43

Bitcoin Cash (BCH) uses ASERT to recalculate its mining target for every block, aiming for an average block interval of 10 minutes. Bitcoin (BTC) instead retargets every 2,016 blocks. Both networks share the SHA-256 proof-of-work algorithm, so the same ASIC hardware can mine either network, but their different adjustment mechanisms affect how miners should interpret difficulty, block timing, and short-term output.

How BCH difficulty adjustment works

Since the November 15, 2020 network upgrade, BCH has used ASERT (aserti3-2d) as its difficulty-adjustment algorithm. It computes a target for each next block by comparing elapsed header time and block height against an ideal schedule measured from a fixed anchor. Two constants define this calculation on BCH mainnet: a 600-second ideal block time and a 172,800-second (two-day) half-life. The half-life controls how schedule deviation changes the target; it is not a rolling two-day average (Bitcoin Cash DAA documentation).

BCH's earlier difficulty algorithm used a rolling window that was susceptible to periodic oscillations in difficulty and hashrate. ASERT was adopted to address those oscillations and keep average block intervals close to the 10-minute target (ASERT specification).

As of October 14, 2026, ASERT remains BCH's current difficulty-adjustment mechanism. The May 15, 2026 network upgrade, supported by Bitcoin Cash Node v29.0.0, introduced script and virtual-machine changes; its published release notes do not list a replacement for ASERT (BCHN v29.0.0 release notes).

BCH vs. BTC: adjustment frequency and timing

BTC retargets difficulty once every 2,016 blocks, roughly every two weeks, by comparing elapsed block-header time against a two-week target. The adjustment is limited to a factor of four in either direction per retarget. Between retargets, BTC's mainnet target is fixed regardless of how hashrate moves.

BCH's ASERT recalculates the target for every next block using cumulative deviation from the anchor schedule. Each new block updates that deviation. An ordinary fast or slow block typically has a small effect, while an unusually long interval can produce a more noticeable adjustment. There is no requirement to accumulate a minimum number of blocks before the algorithm responds (ASERT specification).

The important distinction is between an adjustment and evidence of a lasting trend. A single slow block can affect the next target without proving that network hashrate has fallen. Block discovery is probabilistic, so miners should examine a broader observation window before interpreting a short-term change as a sustained shift.

For a miner choosing between BTC and BCH, BCH's target can change block by block, while BTC's target stays fixed between retarget boundaries. Neither mechanism guarantees predictable short-term revenue.

How to read difficulty, target, and block timing

Target and difficulty move in opposite directions. A higher numeric target is easier to satisfy and corresponds to lower difficulty; a lower numeric target is harder to satisfy and corresponds to higher difficulty. Difficulty is expressed as a reference target divided by the current block target (Bitcoin Cash proof-of-work documentation).

Pool shares use a separate threshold to measure miners' submitted work. An ordinary pool share target is typically numerically higher than the network block target, making a share easier to find than a valid network block. In other words, the share has lower difficulty, not a lower numeric target.

ASERT's calculation can be summarized conceptually as:

next_target = anchor_target × 2^(
 (time_delta − ideal_block_time × (height_delta + 1)) / halflife
)

Here, anchor_target is the target encoded in the anchor block, time_delta is elapsed header time from the anchor block's parent to the evaluation block, ideal_block_time is 600 seconds, height_delta is the evaluation block's height minus the anchor height, and halflife is 172,800 seconds.

This expression explains the relationship between schedule deviation and the next target. The actual consensus calculation uses prescribed fixed-point integer arithmetic, a cubic polynomial approximation, and target limits; directly evaluating the exponential with floating-point arithmetic is not an exact consensus implementation. The formula determines a mining target, not a BTC or BCH revenue amount (Bitcoin Cash DAA documentation).

Network hashrate estimates, short-window average block times, and expected block times calculated from difficulty and an assumed hashrate describe different things. They should not be treated as interchangeable measurements. In particular, an average over just 10 blocks can vary considerably around the 10-minute target because block discovery is probabilistic. Check each metric's method and observation window before comparing it with another.

Model fixed-hashrate output

A miner can estimate expected BCH output over a defined period by holding hashrate and network difficulty constant, estimating the expected number of blocks attributable to that work, and multiplying by the block subsidy plus estimated transaction fees. This is a planning model under a fixed-difficulty assumption, not a guarantee: BCH difficulty continues to adjust under ASERT.

The hashrate input should match the purpose of the estimate. An ASIC's local hashrate can support a theoretical production model, with uptime and work that does not reach or get accepted by the pool accounted for separately. A pool's estimate based on accepted shares over a sufficiently long window can help assess effective contributed work, although it has statistical variance. State the source and measurement period, and avoid deducting rejected work again if that loss is already reflected in the chosen input.

Gross block reward—subsidy plus transaction fees—is also distinct from a miner's realized payout. Payout depends on the pool's payment method, fee schedule, and the miner's effective contribution. A fixed-hashrate model should state which quantities it estimates and how it accounts for those differences.

What to check before switching between BTC and BCH

Because BCH and BTC share SHA-256 hardware, some mining operations reallocate hashrate based on relative profitability. Before switching, compare the following using consistent measurement periods and snapshot times:

  • Current BCH and BTC network difficulty and recent block-timing behavior over a broader window, rather than relying on a single block or a 10-block sample.
  • Each chain's subsidy and estimated transaction fees, together with the difficulty used in the output estimate.
  • BTC and BCH exchange prices from the same point in time, so both output estimates can be converted into a common unit such as USD. Coin output, revenue, and profit after operating costs are different measures.
  • ASIC wall power draw and the applicable electricity price, since these costs apply regardless of which chain is mined.
  • The pool's payment method, fee schedule, and settlement rules for each chain, since these affect realized payout independently of network difficulty.
  • Miner uptime and rejected shares by reason, accounting for any losses already reflected in the hashrate estimate.

Pool payment method is a separate layer from network difficulty and deserves its own check. ViaBTC's published pricing documents two payment methods for BCH: PPS+ and PPLNS. Under PPS+, the block-reward component is paid using PPS accounting, while the transaction-fee component is distributed separately under PPLNS. The fee schedule lists a 4% fee on the PPS-paid block-reward component and a separate 2% fee on the PPLNS-distributed transaction-fee component. These are distinct fees on distinct reward components, not a combined flat rate. Under PPLNS, both components are allocated according to a miner's share of the pool's submitted work over the trailing five difficulty rounds, following six confirmations (ViaBTC fees and payment methods, checked October 14, 2026).

Neither payment method changes BCH network difficulty. They determine how the pool accounts for and distributes rewards: the PPS component pays for valid submitted shares, while PPLNS distributions depend on blocks found by the pool.

For operations already mining through ViaBTC, its one-click switch address is a Stratum mining endpoint, not a withdrawal wallet address. ViaBTC instructs miners to configure that endpoint and then select the payment coin in mining settings; the documentation states that the change takes effect in 10 minutes. Keep the mining connection, payment-coin setting, and withdrawal address distinct when configuring the service (ViaBTC one-click switch instructions, checked October 14, 2026).

Conclusion

ASERT does not make BCH mining revenue predictable or eliminate the variance inherent in block discovery. Its practical relevance for SHA-256 miners is that BCH recalculates its target block by block using deviation from a fixed schedule. Difficulty should therefore be treated as a changing input tied to a specific snapshot, rather than a static daily figure.

When comparing BTC and BCH mining economics, keep network difficulty, pool share accounting, and payout rules separate. Use consistent data periods, convert expected coin output into a common valuation unit, and account for operating costs before drawing profitability conclusions.

FAQ

Does BCH difficulty adjust every block?

ASERT recalculates the target for each next block using elapsed header time and block-height deviation from a fixed anchor schedule. Each new block contributes to that cumulative deviation; the calculation does not use only the preceding block interval as its reference.

Is a higher BCH difficulty always bad for miners holding fixed hashrate?

Higher difficulty means a lower numeric target and a lower probability of finding a valid block with each hash. With hashrate and the modeled period held constant, expected block output falls. That does not by itself determine profitability: block rewards, BCH price, pool fees, and operating costs also matter.

Does switching a miner between BTC and BCH change how BCH difficulty is calculated?

No. Switching does not change the consensus formula. Hashrate moving into or out of BCH can affect block timing, which then feeds into subsequent ASERT calculations. ViaBTC's mining endpoint and payment-coin settings are separate from that network rule; changing a withdrawal wallet address is a different action again.

Can a single unusually fast or slow BCH block indicate a lasting difficulty trend?

A single block is not sufficient evidence of a lasting trend. Its timestamp can affect the next target, and an unusually long interval can produce a noticeable adjustment, but miners need a broader observation window to distinguish sustained changes from random variation.

References