kHeavyHash Share Difficulty: Compatibility and Rejects

kHeavyHash share difficulty is the easier pool target used to measure a miner's contributed work; it is not the Kaspa network difficulty that determines whether work becomes a block. Most pools adjust share difficulty to the worker's estimated hashrate. A reject labelled low difficulty, stale, duplicate or invalid describes a different failure route, so changing random values or firmware before reading the exact pool response can make diagnosis harder.

Network difficulty and share difficulty

Reassess kHeavyHash share difficulty whenever network conditions, firmware, tariffs or official guidance changes.

Kaspa’s kHeavyHash proof-of-work network has a target that valid blocks must meet. A pool gives a worker an easier target so it can receive frequent evidence of contributed work. A share that meets the pool target earns accounting credit under the pool’s rules; only a much rarer result meeting the network target can be submitted as a block.

The Kaspa Wiki explains that solo mining uses network difficulty, while a pool sets easier share difficulty and selects solutions that meet the network target. This distinction is the starting point for every reject investigation.

Share difficulty that is too low for a very fast ASIC creates excessive messages and server load. Share difficulty that is very high can produce long gaps between accepted shares, making a healthy worker look idle. Neither setting changes the ASIC’s physical hashrate.

Many pools use variable difficulty, often shortened to vardiff, to target a manageable share interval. Allow the pool’s adjustment period before deciding that an initial value is wrong.

Compatibility comes before tuning

When reviewing kHeavyHash share difficulty, separate measured facts from forecasts so the result can be reproduced.

A kHeavyHash ASIC must connect to a pool endpoint that explicitly supports the device or the protocol variant it speaks. Verify the algorithm, hostname, port, encryption requirement, username or wallet format and worker separator from the pool’s current setup page.

Do not copy an endpoint from a video or old forum post. Pools can change ports, regions and authentication. Confirm that the destination resolves to the intended operator and that the miner clock is correct where secure connections depend on time.

Firmware can report difficulty in scaled units or show a requested and accepted value differently. Use pool-side accepted shares as the commercial record and treat the local display as diagnostic evidence.

Hashpower marketplaces can impose order minimums or required share rates. A marketplace difficulty error may therefore need a marketplace-specific setting rather than the ordinary pool default. Read both services’ current instructions before connecting them together.

Read the reject category accurately

Pool wording is not universal. Save the exact response, timestamp, worker name and endpoint rather than translating every reject into ‘bad difficulty’. A persistent reject rate deserves investigation even when local hashrate looks normal.

Stales are primarily a timing problem. Distance alone is not a complete latency measure; routing, congestion, Wi-Fi, packet loss, proxy load and pool job propagation also matter. Use a wired connection and compare a suitable regional endpoint.

Duplicates can arise after unstable restarts or a faulty proxy replaying submissions. Do not run two controllers against the same hardware or clone a configuration without unique worker identities.

A controlled diagnostic sequence

• Record the exact ASIC model, firmware version, pool endpoint and reject message.
• Return one test miner to a supported stock power and frequency profile.
• Confirm kHeavyHash, the current port and the pool’s required wallet or account format.
• Remove unverified proxies and connect directly where the pool supports the miner protocol.
• Use wired Ethernet, check packet loss and select an appropriate regional endpoint.
• Allow vardiff to settle, then compare accepted and rejected shares over a representative period.
• Check whether the pool assigned a new difficulty after reconnecting.
• Change one variable at a time and retain a rollback note for every firmware or configuration change.

Worked share-frequency check

Suppose a high-hashrate kHeavyHash ASIC submits hundreds of shares each second at an initial easy target. The pool raises the assigned difficulty, after which accepted shares arrive less often but each represents more work. The expected credited hashrate should remain broadly consistent once the measurement window is long enough.

If the pool shows only one accepted share in a brief window after a large increase, do not immediately lower the target. Estimate the expected interval from the pool’s own documentation or support data and wait for a fair sample. Share arrival is probabilistic.

If the miner instead continues sending shares below the newly assigned target and the pool labels them low difficulty, inspect whether the job and target update reached the firmware or proxy. This is a compatibility or communication question, not evidence that network difficulty is too high.

Evaluate the outcome through pool accepted hashrate and reject percentage, not the number of shares alone. Two correct difficulty settings can produce different share counts but equivalent credited work.

When manual difficulty is appropriate

Use it only where the service documents it

A fixed or minimum difficulty can be useful for a compatible marketplace order, proxy or unusually large worker when the service publishes the required syntax. Record the reason and the unit used.

Test one worker and compare accepted work before applying the setting to a fleet.

Prefer vardiff for ordinary pool use

Where the pool supports the ASIC correctly, its variable-difficulty system usually provides a suitable accounting rate without manual intervention.

Do not use overclocking to solve a protocol reject. Aggressive clocks can create hardware errors and hide the original problem while affecting stability and warranty.

Mistakes that prolong a reject fault

• Confusing pool share difficulty with network difficulty.
• Using a port copied from an old guide without checking the pool.
• Changing clocks, proxy, pool and worker format at the same time.
• Judging success by local hashrate while accepted hashrate remains low.
• Treating every stale or duplicate as a low-difficulty response.
• Forcing a value without confirming its unit or supported syntax.
• Leaving remote miner interfaces exposed while troubleshooting.

Frequently asked questions

Is kHeavyHash share difficulty the same as network difficulty?

No. The pool target is easier and is used to account for contributed work. Network difficulty applies to valid block solutions.

Does higher share difficulty increase hashrate?

No. It changes how frequently qualifying shares are expected, not the ASIC’s physical hashing output.

Why does vardiff change after connection?

The pool estimates worker performance and adjusts the target to obtain a manageable share interval.

What causes low-difficulty rejects?

Possible causes include an incorrect endpoint, failure to apply the assigned target, proxy incompatibility, firmware scaling or an unsupported marketplace setting.

Are stale shares caused only by distance?

No. Routing, packet loss, Wi-Fi, congestion, proxy load and slow job updates can contribute.

Should I overclock to fix rejects?

No. Restore a supported stable baseline and resolve protocol, endpoint or network errors first.

Conclusion

kHeavyHash share difficulty is an accounting target, not a speed control. A reliable diagnosis starts with the exact pool response and current compatibility instructions, then separates target errors from stale, duplicate, invalid and authorisation failures. Test one stable miner, let vardiff settle and judge the result by accepted pool work before changing a fleet.

Next steps

Use The Mining Shop UK setup and profitability guidance to compare accepted output, power and operating cost after the connection is stable.