CPU / PC SHA256 miner troubleshooting (cpuminer/minerd): get it running, then validate shares

CPU SHA256 mining is no longer a production strategy for Bitcoin, but it still matters for development: building a Stratum test harness, simulating low hashrate clients, or validating a new pool deployment. The failure modes are different from ASICs—here it’s usually a mix of old code, modern libraries, and protocol drift.

When CPU miners still make sense

CPU miners are useful for repeatable testing: you can run them on CI, on disposable VPS instances, and in isolated lab networks. They’re also good for verifying pool documentation (URL/port/worker format) because they fail fast and are easy to instrument.

Fixing build & dependency failures

Many cpuminer/minerd forks were written for older toolchains. On modern Linux you’ll typically run into: missing libcurl, jansson, OpenSSL/crypto headers, or compiler flags that assume old GCC. The goal is not “latest everything”—it’s a clean, reproducible build.

• Start clean: build in a fresh container/VM to avoid chasing system-wide conflicts.
• Pin dependencies: if the miner expects older OpenSSL behavior, use a compatible build environment.
• Confirm algorithm: many “multi” forks default to other algorithms—verify you’re actually running SHA256/SHA256d.

Stratum vs getwork: why “connects but no shares” happens

A common trap: an old miner appears to connect but never produces accepted shares because it expects legacy RPC/getwork flow, while your target endpoint is strict Stratum (or Stratum behaves differently than the miner expects). In practice, solving this is usually one of:

1. Use a compatibility proxy for old clients, or run a test Stratum endpoint with compatible behavior.
2. Point the miner at the right port (some pools separate “legacy/low-diff” from standard ports).
3. Normalize time and DNS (bad time sync and DNS failures look like protocol issues).

Tip: don’t judge success by “hashrate” logs. Success = accepted shares and stable submission cadence. If you are testing a pool you own, enable verbose logs on the Stratum server so you can correlate submissions.

Rejects, stales & low accepted share rate

With low-hashrate miners, a small amount of network jitter can look catastrophic. Focus on these checks:

• Latency: test from the same region as your Stratum gateway. Cross-continent tests skew stale rate.
• Difficulty updates: some old miners react poorly to frequent vardiff changes.
• Time drift: if the box clock is wrong, share timing can break (especially in VMs).
• Over-optimization: compiling with aggressive CPU flags can cause instability on older hardware.

Security & safety (don’t run random binaries)

The “miner download” ecosystem is heavily abused. For legacy projects, prefer building from source and pinning commits. If you must test a prebuilt binary, do it in a sandbox VM with no wallet keys and no access to your internal network.

Need a working test harness fast?

If your goal is to validate a pool (or debug why certain miners fail), we can set up a clean test harness and confirm: the endpoint is reachable, the Stratum session flow is correct, difficulty updates are safe, and shares are being validated properly.

Related guides: miner setup basics, pool URL list, pool software overview.