NerdMiner – Not Receiving Block Templates
Stratum handshake completes but mining.notify never arrives — TCP socket connects, mining.subscribe and mining.authorize succeed, mining.set_difficulty arrives, then the pool falls silent. No block templates means no work for the SHA-256 core: hashrate stays at 0, valid shares stay at 0, the dashboard shows Pool: Connected indefinitely. Cause is almost always pool-side (template-builder hang, wallet not registered, scheduled maintenance, DDoS mitigation) — sometimes network (NAT/firewall stripping notify payloads) or stale firmware (parser regression). Fix path: switch to a known-good pool first (solo.ckpool.org:3333 or public-pool.io:21496), check pool status, then network capture, then reflash.
Warning — Should be addressed soon
Symptoms
- Display shows `Pool: Connected` solid, not flickering or cycling
- `Valid Shares` counter stuck at `0` for 5+ minutes despite connected status
- Hashrate tile reads `0 kH/s` continuously after first sync
- Block height and BTC price refresh normally on the idle screen — confirms WiFi and API are healthy
- Serial console at `115200 baud` shows clean `mining.subscribe` → `mining.authorize` → `mining.set_difficulty` then long silence — no `mining.notify` lines
- Wireshark / tcpdump on the gateway shows the stratum TCP socket alive (keepalives every 30-60s) but zero JSON-RPC payloads after the handshake
- Pool dashboard reports the worker as online but with `0` hashrate and `last share: never`
- Other miners on the same LAN (Bitaxe, NerdAxe) behave identically against the same pool — confirms pool-side, not device
- Connection eventually drops after 60-180 seconds with `socket reset` or `EOF`, reconnects, repeats indefinitely
- Pool status page or Discord has been quiet for hours, or maintenance was just announced
- Issue started recently — not a chronic config problem; worked yesterday
- Pointing the same NerdMiner at a different pool produces `mining.notify` and shares within 30 seconds
Step-by-Step Fix
Power-cycle the NerdMiner: unplug USB-C for 10 full seconds, plug back in. Watch the boot sequence on the display (`Booting…` → `WiFi connecting…` → `Pool connecting…`). If `Valid Shares` starts ticking within 60 seconds you had a transient socket wedge — common after WiFi blips, router reboots, or after weeks of uptime without a restart. Done.
Switch to a known-good public solo pool. Enter config mode (hold `BOOT` while power-cycling, or browse to `http://nerdminer.local` / `http://192.168.4.1` via the captive portal). Set `Pool URL` = `solo.ckpool.org`, `Pool Port` = `3333`, `Wallet` = your `bc1q...` SegWit address, `Password` = `x`. Save and reboot. Within 60 seconds jobs should flow and the hashrate tile populate.
If ckpool also fails, try Public-Pool. Same drill but `Pool URL` = `public-pool.io`, `Pool Port` = `21496`. Public-Pool runs a different stratum codebase (`benjamin-wilson/public-pool`) and a different upstream node, so two working pools confirms your hardware is fine and the original pool has a backend bug.
Open the pool's status page in a browser. Public-Pool: `https://web.public-pool.io/` — banner appears at the top during outages. CKPool: `https://stats.ckpool.org/`. Smaller pools usually post outage notices on Discord or Twitter/X. If maintenance is announced, your job is to wait — typically 15 minutes to a few hours.
Verify your wallet address is well-formed by pasting it into `https://mempool.space/`. If the address page loads with script type `v0_p2wpkh` (native SegWit), the address is valid. `v1_p2tr` = Taproot — most pools won't authenticate it. If mempool.space rejects the address entirely, you copy-pasted something corrupt — generate a fresh `bc1q...` and try again.
Capture the stratum conversation on serial. Connect USB-C, open a serial monitor at `115200 baud` (`screen /dev/ttyUSB0 115200`, PuTTY, Arduino IDE Serial Monitor), then reboot the NerdMiner with the monitor open. Watch for the four-stage handshake. The serial log is the ground truth — it cuts through every dashboard misread. If `set_difficulty` arrives but no `notify` for 60+ seconds, the pool is stalling. Switch pools — don't keep debugging at the device.
Run a `tcpdump` or Wireshark capture on your gateway. From a laptop on the same LAN: `tcpdump -i any -nn -A -s0 'tcp port 3333 or tcp port 21496' | grep -E "subscribe|authorize|notify|set_difficulty"`. If `mining.notify` payloads appear on the wire but the NerdMiner reports zero shares, you have a parser/firmware bug — go to step 11. If `mining.notify` never appears in the capture, the pool isn't sending — your hardware is fine, the pool is broken.
Test from an isolated network. Hotspot the NerdMiner off your phone (mobile data, separate ISP, no enterprise firewall) for 5 minutes. If shares begin flowing on cellular when they didn't on home WiFi, your router is the problem — likely SPI firewall, MTU mismatch (try `1492` or `1500`), or QoS misclassification of the stratum socket as idle. Disable suspicious features one at a time.
Hardcode the pool IP if DNS is suspect. Run `nslookup public-pool.io` from a machine on the same LAN. Note the IPv4 address. In NerdMiner config, replace `public-pool.io` with the bare IP, keep port `21496`, save, reboot. If shares now flow, your router's DNS resolver is broken — switch upstream DNS to `1.1.1.1` (Cloudflare) or `8.8.8.8` (Google).
Cross-test with a Bitaxe or NerdAxe on the same LAN if you have one. Point the second device at the same pool and same wallet. Same handshake silence on both = pool-side, full stop. Different behaviour = specific to your NerdMiner unit (rare — possible with a damaged ESP32 SPI flash region holding a corrupt stratum library).
Wipe NVS and reflash from the official `master` branch. With NerdMiner on USB: `esptool.py --chip esp32s3 --port COM3 erase_flash` (or `--chip esp32` on older variants). Then flash the latest official build from `https://github.com/BitMaker-hub/NerdMiner_v2/releases` — pick the binary matching your exact board variant. After flash, factory-configure from scratch — do NOT import any saved config, because a corrupt NVS region survives a reflash if you preserve it. Rules out the stratum-parser regression bugs from older builds.
Build from source with serial verbosity raised. Clone `https://github.com/BitMaker-hub/NerdMiner_v2`. Open `platformio.ini`, find the build flags for your board, add `-DCORE_DEBUG_LEVEL=5` and `-DSTRATUM_DEBUG=1` if available. Compile, flash. The serial console now prints every JSON-RPC frame parsed and every state transition. You can see exactly where in the handshake the device is stuck — `state: AUTHORIZED, waiting for first notify` for 5+ minutes is pool-side; `parser error` after a notify-shaped payload is firmware.
Inspect the NerdMiner upstream issue tracker at `https://github.com/BitMaker-hub/NerdMiner_v2/issues`. Search keywords like `notify`, `template`, `0 shares`, `pool stuck`. If your symptom matches an open issue, comment with your firmware version, board variant, pool, and serial capture — that's how upstream gets fixed. If it matches a closed issue, check which build version closed it and flash that build or newer.
Try a stratum-proxy fork or third-party NerdMiner firmware. A few experimental NerdMiner-friendly stratum proxies exist that re-marshal jobs from one pool to another — useful for isolating whether the silence is in the pool's notify pipeline or the device's parser. Treat third-party firmware as untrusted: read the diff against upstream `BitMaker-hub/NerdMiner_v2` before flashing, especially the stratum and wallet-handling code paths.
Stop DIY and open a D-Central ticket. All of the following must be true: (a) two known-good pools both fail to push notify after clean handshake, (b) fresh `erase_flash` + flash of latest official release didn't help, (c) `tcpdump` shows no notify payloads from either pool, (d) cellular hotspot also fails. At that point ship for diagnostic — see step 16.
Open a D-Central support ticket at `https://d-central.tech/contact/`. Include: board variant (T-Display-S3 / T-Dongle-S3 / WROOM / S3 reference), firmware version (read from splash screen at boot), the pools you tested, a serial console capture of the handshake (10-30 lines is plenty), and a `tcpdump` snippet if you have one. We replicate on bench, narrow the failure mode, and either ship a config fix, escalate to upstream maintainers with a reproducible report, or replace the unit if it's hardware. Free with any Nerd-family device purchased from D-Central; pre-quoted bench hour for units bought elsewhere.
Replace the unit if diagnostic time is exceeding 4-6 hours. NerdMiner v2 boards are CAD `$80 – $160` depending on variant. D-Central stocks every Nerd-family device — NerdMiner, NerdAxe, NerdNOS, NerdQAxe, NerdQAxe++ — and ships from Canada. The economics of a 5W lottery-ticket miner are simple: pleb pragmatism beats heroic debugging. Buy fresh, ship the broken one for diagnostic credit, keep stacking sats.
Set up two-pool habits going forward. Configure primary `solo.ckpool.org:3333` and fallback `public-pool.io:21496` if your firmware build supports fallback (some forks do). Subscribe to both pools' Discord / Twitter / GitHub for outage notifications. Bookmark the captive-portal config URL so you can swap pools in 30 seconds when shares stall. Single-pool dependency is the #1 cause of repeat silent-stall outages — solve it once, never again.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.