Bitaxe – Extranonce Subscribe Mismatch / Invalid Nonce Range

Switch to a known-good public pool. Open AxeOS → Settings → Stratum. Set URL to public-pool.io, port 21496, SSL off. Save and reboot with a full 10-second power-cycle. Watch the AxeOS dashboard for 5 minutes — shares should arrive within one pool job cycle (30-90 seconds). If they do, the original pool was running legacy stratum software that doesn't handle mining.extranonce.subscribe gracefully. Either stay on the modern pool, or ask the original pool operator to update their CKPool fork to a current-gen build.

Cold power-cycle the Bitaxe. Unplug USB-C (or the 12V XT30 / barrel input on Hex / GT) for a full 10 seconds. Plug back in. Flushes wedged stratum task state from a previous failed extranonce-subscribe handshake. Some AxeOS builds keep the task state in RAM after a soft reboot and replay the broken sequence — only a hard power-cycle resets the ESP32-S3 stratum state machine cleanly. If pool was the variable, this won't fix it; but it eliminates one diagnostic dimension before swapping settings.

Try a different pool family. If Public-Pool didn't fit your use case (e.g., you want Solo-CKPool for lottery odds), try solo.ckpool.org:3333 (current-gen build), mine.ocean.xyz:3334, or stratum.braiins.com:3333. Each uses different pool-side software and at least one will handle the BFGMiner extension cleanly. Save URL change, save port, cold power-cycle, watch for shares for 5 minutes per pool tested.

Check for an OTA firmware update. AxeOS → System → OTA Update. If newer stable available, the extranonce-subscribe handler may have been fixed. Read release notes at github.com/bitaxeorg/ESP-Miner/releases before upgrading — if new version mentions stratum or extranonce fixes, take it. Document current version first so you can roll back if needed. Major version jumps need extra care.

Confirm BTC address format isn't the actual problem. Pools are strict about worker naming. Public-Pool wants bc1q... or 1... or 3... + .workername. Lightning addresses pasted by mistake (lnbc... format) pass subscribe, pass authorize on some pools, then silently break the session at first share submission — looks identical to extranonce mismatch from dashboard. Cross-check BTC address character-by-character against the pool's getting-started doc.

Capture USB-C serial log at 115200 baud. Plug a data-capable USB-C cable (not charge-only) into the Bitaxe. Open serial terminal — screen on macOS/Linux, PuTTY on Windows, or Chrome WebSerial in-browser. Watch boot sequence and stratum handshake. Filter for extranonce. Exact log line tells you whether pool acknowledged the extension, rejected it explicitly, or went silent. Save 2-minute log capture for reference — this is the artifact D-Central's repair team and ESP-Miner maintainers ask for.

Wireshark the stratum exchange. From a laptop on the same LAN, run Wireshark with filter tcp.port == 21496 and ip.addr == <bitaxe-ip>. Reconnect the Bitaxe. Should see TCP SYN → SYN-ACK → ACK, then JSON-RPC: mining.subscribe, response, mining.authorize, response, mining.extranonce.subscribe, response. Examine the response byte-for-byte. Truncated JSON = network middlebox issue; clean JSON-RPC error = pool doesn't support extension; no response at all = pool silently ignoring + AxeOS waiting forever.

Disable any stratum proxy in the path. If you've configured a stratum proxy on your LAN (for VPN, geo-routing, logging), bypass it. Point the Bitaxe directly at the upstream pool's hostname and port. If shares start flowing, the proxy was the variable — update or remove it. Common culprits: home-grown Python relays, abandoned stratum-proxy builds, old bfgminer --proxy setups. Modern proxies (braiins-os proxy mode, current cgminer-stratum-proxy) handle the extension correctly.

Test on a residential LAN if you're on enterprise / hotel / CGNAT. Move the Bitaxe to a known-residential LAN — your home network, a friend's place, or a phone hotspot in the worst case. If extranonce mismatch clears on residential and reappears on the original network, a middlebox in the original network path is mangling the JSON-RPC traffic. This is rare but documented. Solution: use a different LAN, or set up a VPN out of the constrained network.

Verify pool's documentation and software version. Email or Discord the pool operator. Ask: 'What pool software are you running? What version? Do you support mining.extranonce.subscribe?' Modern pool operators (Public-Pool, Ocean, Braiins, NiceHash, current Solo-CKPool) answer within minutes. Self-hosted CKPool fork operators may not know — at which point you have your answer (legacy software). The Bitcoin home-mining ecosystem is small; pool operators are reachable and helpful.

Roll back ESP-Miner to a specific known-good version. If your AxeOS version has a documented extranonce-subscribe regression in the issue tracker, find the last-known-good stable release at github.com/bitaxeorg/ESP-Miner/releases. Match the .bin file to your exact board revision (printed on PCB — Ultra 205 vs 207, Gamma 601 vs 602, Hex 303 vs 304). Use Chrome / Edge with USB-C web flasher at https://bitaxe.org/flash, select factory flash, watch boot log on serial. Wrong .bin for wrong board revision bricks the device — verify before clicking flash.

Build ESP-Miner from source with verbose logging. Clone bitaxeorg/ESP-Miner from GitHub. In main/stratum_api.c (or equivalent), add ESP_LOGI traces around the stratum_api_extranonce_subscribe function — log the request being sent, the response received (or timeout), and the state-machine transition. Build with ESP-IDF v5.x, flash via USB-C. Reproduce the bug; the extra log lines pinpoint exactly where the handler stalls. PRs upstream welcome — the Bitaxe ecosystem grew because plebs sent fixes back.

Patch the extranonce-subscribe handler to fail-open. If you've identified that AxeOS treats a missing or error response as fatal, the fix is two lines: change the handler to log the error and continue to the mining.notify receive loop instead of wedging. Submit the patch upstream at bitaxeorg/ESP-Miner; in the meantime, run your patched build. This is exactly the kind of community contribution that has kept ESP-Miner shipping cleanly through six BM136x silicon variants.

Set up a local pool test rig. Spin up a current-gen CKPool build on a Raspberry Pi or old laptop on your LAN. Configure with extranonce-subscribe support enabled. Point the Bitaxe at <local-ip>:3333. If shares flow against your local CKPool but fail against the original remote pool, the original pool's software stack is the variable — confirmed pool-side fault. This trick is also useful for offline development and Bitaxe firmware testing.

Use a stratum proxy as a translation layer. If stuck with a legacy pool you cannot replace (corporate constraints, contractual mining arrangement, geographic limits), run a modern stratum proxy in front of it that strips mining.extranonce.subscribe from the upstream conversation while answering it locally to the Bitaxe. Configure on a Pi on your LAN, point Bitaxe at the Pi, point the Pi at the legacy pool. The Bitaxe sees a clean handshake; the legacy pool sees a stratum-only client.

Stop DIY and ship to D-Central when (a) factory-flashed Bitaxe pointed at three modern public pools all fail with zero shares in 15 minutes per pool, (b) Wireshark shows clean request + clean response but AxeOS state machine never advances to mining.notify, (c) failure persists across factory flash + clean URL/port + DNS override + LAN swap + cable swap + PSU swap, or (d) physical damage is visible (scorched USB-C port, cracked PCB, bulged cap, blown fuse on VIN). At that point you've exhausted every software variable and the device needs bench diagnosis.

D-Central bench process: test fixture with known-good public-pool.io:21496 connection over clean LAN with 1.1.1.1 DNS, serial log capture at 115200 baud, Wireshark on bench LAN, ESP-Miner factory flash of current stable matched to exact board revision. If behaviour persists post-flash, ESP32-S3 itself or NVS partition is suspect — chip swap or board swap from D-Central's Bitaxe inventory. D-Central pioneered the Bitaxe ecosystem and runs bench rigs tuned for stratum-path diagnostics.

Ship safely. Pack the Bitaxe in an anti-static bag. Double-box with at least 3cm of foam on every side. Include a note with: observed symptoms, pool URL + port + SSL setting that triggered the symptom, AxeOS firmware version, board revision (printed on PCB), saved serial log if captured. The note saves D-Central's bench tech 30 minutes of preliminary diagnostics, which saves your repair cost. Ship to address listed on the D-Central ASIC Repair page.