Solo Mining Shows Zero Shares for Hours — Is It Broken?

Confirm the pool is using vardiff, not fixed difficulty. solo.ckpool.org, public-pool.io, OCEAN solo all run vardiff. If you're on a hobby pool with `share-diff = 65536` fixed on a low-hashrate miner, expected wait can stretch to many minutes — long but mathematically correct. Switch to a vardiff pool for more frequent share feedback at the same block-reward odds. AxeOS → Settings → update Stratum URL and Port → Save → reboot.

Switch to the right port for the pool's solo channel. solo.ckpool.org solo is on `:3333`. public-pool.io solo is on `:21496`. Some pools also offer testnet/signet ports for practice — `share-diff` is much lower there and shares fly even on a NerdMiner. Useful for confirming the rig works before committing to mainnet solo for the long haul.

Wait for vardiff to engage. The first 60 seconds after a stratum connect, the pool sends a default `share-diff` (often `512` or higher). After your first share or two, it adjusts to your hashrate. Reboot-and-watch behaviour can look like 'no shares for two minutes!' — that is the vardiff calibration window, not a fault. Give it a full 5 minutes from a fresh connect before judging.

Set realistic expectations on the dashboard. AxeOS shows lifetime `Best Difficulty` — the highest-difficulty share your miner has ever found. This number creeps up slowly and should NOT be confused with an estimated time to block. Best Difficulty is a rolling watermark, not a progress bar.

Stop refreshing. Set the AxeOS tab to auto-refresh every 60 seconds and walk away. Compulsive refresh is the largest cause of false-positive 'is it broken?' tickets in our support queue. Variance feels worse the more often you check — that's a feature of the human brain, not the miner.

Capture a clean log baseline. From AxeOS Logs, copy 5 minutes of output during normal operation. Save as `baseline.txt`. Next time you suspect a fault, capture another 5 minutes and diff against baseline. Real faults show up as new error strings; variance shows the same `mining.notify` / `mining.set_difficulty` cadence with longer gaps between `mining.submit` lines.

Validate share-difficulty matches expectation for your hashrate. In Logs, find the most recent `mining.set_difficulty` line. If it is pinned at `share-diff = 1` despite a 1.2 TH/s Bitaxe Gamma, the pool is treating you as a low-hashrate miner — usually because vardiff has not seen any shares yet to calibrate. Disconnect, reconnect, and watch — share-diff should climb to ~1024-4096 within the first 10 minutes for a Gamma.

Switch pools as a sanity test. Point the same Bitaxe at two different solo pools sequentially over a few days and compare share rates. If both fall within ~1.5x of the formula `expected_interval = (share_diff * 4.295e9) / hashrate_H_per_s`, hardware is fine. If one pool is dramatically slower than the other, that pool's vardiff is misbehaving for your hashrate band — switch back.

Enable webhook notifications. ESP-Miner exposes share counts at `/api/system/info`. A 30-line Python script polling that endpoint every 60 seconds and POSTing to a Discord or Telegram webhook turns 'anxious dashboard refresh' into 'ping when something happens.' Same approach works for NerdMiner and NerdAxe via their respective APIs. Stop watching, start being notified.

Run a Bitaxe Max or NerdMiner alongside as a control. A second low-hashrate miner running on the same WiFi confirms it is not a router-level issue. Both should produce shares on schedule per the formula, scaled to their hashrate. If the control miner submits and the main miner doesn't, you have a real divergence — escalate.

Run `tcpdump` against the stratum connection for 24 hours: `tcpdump -i any -w stratum.pcap host <pool-ip> and port <pool-port>`. Capture every byte: outbound `mining.submit` attempts, inbound `mining.notify` and `mining.set_difficulty`. Reconstruct the conversation in Wireshark with the Stratum protocol dissector. You will see exactly when shares are submitted, when they are accepted, when (rarely) they are rejected, and when stratum is silent because there's nothing to send.

Cross-check against the pool's public solver dashboard. Solo CKPool publishes `/users/<address>` with full submission history. Public Pool offers per-address share charts. Compare the on-rig log to the pool's record — they should match line-for-line. Discrepancies (rig logged a submit, pool shows nothing) point to network packet loss between you and the pool, not chip variance.

Build ESP-Miner from source with extra share-rate metrics. Patch `stratum_api.c` to log inter-share intervals to a circular buffer; expose them via a new `/api/system/share_stats` endpoint. Now your Bitaxe self-reports its variance distribution. Useful for any operator running a fleet of multiple Bitaxe / Nerd-family miners.

Run a Monte Carlo simulation against your config. In Python, `numpy.random.exponential(scale=expected_interval, size=86400)` simulates a day of expected share waits. Compare the simulated distribution to your actual log. If your real distribution falls inside the simulated 95% confidence interval, you have textbook Poisson variance. If it is outside, you have a real divergence — file a GitHub issue with the data.

Mine on signet for a calibration baseline. Signet has dramatically lower difficulty so you can validate 'is the chip computing valid hashes' in minutes instead of hours. If signet shares fly and mainnet shares are silent past `4x expected wait`, you have a real chip- or firmware-level fault despite a healthy-looking hashrate dashboard. Point it back at mainnet immediately after the test — signet rewards are not real BTC.

Pool your hashrate with friends or your own gear. Three Bitaxes pointed at the same address on the same solo pool give you ~3x the share rate against the same block lottery. You're still solo — you keep the entire block reward if any one of them wins — but variance smooths out and the dashboard is far less anxiety-inducing. Same logic scales to NerdQAxe + Bitaxe Hex + Bitaxe Gamma stacks.

Run an internal stratum proxy. Aggregate multiple miners (Bitaxe + NerdQAxe + Hex) behind a single ckpool instance on a Raspberry Pi or small VPS. Same effect as step 16, scoped to gear you own — the proxy aggregates shares so you see a smoother stream while still solo-mining against the network. Open-source ckpool is the reference implementation.

Or just accept the lottery. The whole reason solo mining is interesting is the variance — every share you submit is a real chance, however slim, at the full block reward. Pooling against a traditional pool gives smooth payouts but eliminates the lottery upside. This is a design choice, not a problem. The Mining Hacker move is to mine solo and treat the variance as the point, not the bug.

Open a D-Central support conversation only when the math is wrong. If you have verified the formula, captured 24 hours of logs, ruled out stratum and chip faults, and your share rate is consistently more than 4x outside the expected interval — open a ticket at https://d-central.tech/contact/ with the captures attached. We'll cross-check against our fleet data and either confirm a hardware fault or point you to a pool-side bug to escalate. Variance alone is not a ticket.