Bitaxe – Stratum mining.authorize Failed / Wrong Worker Name

Open the AxeOS web UI at the Bitaxe's IP address and go to Settings. In the Stratum User field, delete everything. Paste a fresh receive address from your Bitcoin wallet — must start with `bc1`, `3`, or `1`. Do NOT paste a Lightning address, an email, a username, or anything containing `@`. Save. Reboot the Bitaxe (full power cycle, 10 seconds off). Watch the home screen — Pool should flip from `Disconnected` to `Connected` within 30 seconds and stay there.

Verify the Stratum URL field contains only the bare hostname: `public-pool.io` or `solo.ckpool.org` or `pool.d-central.tech`. Remove any `stratum+tcp://` prefix, `https://` prefix, trailing slash, or surrounding whitespace. Save and reboot. On reconnect the log should show `Connected to pool` followed by `mining.authorize` followed by `result: true`.

If the current pool still rejects, switch to a known-good solo pool for testing. Set Stratum URL to `public-pool.io`, Port to `21496`, User to your on-chain BTC address, Password to `x`. Save, reboot. Public Pool is the lowest-friction solo pool for a Bitaxe — if auth fails there, the problem is your address, not the pool.

Strip the worker suffix. In Stratum User, remove everything from the first `.` onward so the field contains only the raw address. Some pools silently reject non-conforming worker suffixes. Once basic auth works, re-add the suffix using only lowercase alphanumerics and hyphens (`bc1q...bitaxe-01` is fine; emojis, spaces, slashes, or mixed case may be rejected).

Factory reset and reconfigure from a clean state. AxeOS → System → Reset Settings. Re-enter WiFi SSID/password, Stratum URL, Port, User, Password by typing them (not by pasting from a PDF — PDFs embed zero-width characters). Reboot. If auth now succeeds, your previous config had invisible characters or subtle corruption.

On a laptop on the same network, verify reachability: `ping public-pool.io` for sub-200 ms responses, then `nc -v public-pool.io 21496` (Linux/macOS) or `telnet public-pool.io 21496` (Windows). You should see `Connected to...`. This proves the network can reach the pool. If this fails, your problem is router/firewall/ISP, not auth.

Capture the raw stratum handshake from the laptop with `nc public-pool.io 21496`. Send literally: `{"id": 1, "method": "mining.subscribe", "params": ["Bitaxe-Test"]}` then newline, then `{"id": 2, "method": "mining.authorize", "params": ["YOUR_BTC_ADDRESS", "x"]}` then newline. Watch the response. The error message at the raw protocol level is usually human-readable — `bad-user-name`, `worker-banned`, `invalid-address`.

Validate the BTC address against the blockchain: `curl https://mempool.space/api/address/YOUR_BTC_ADDRESS` — a valid address returns JSON, a malformed one returns 404. If 404, the address is bad (checksum failure, wrong network, truncated) and `mining.authorize` will always fail. Generate a fresh address from Sparrow, Electrum, or a hardware wallet and retry.

Enable verbose logging in AxeOS if the firmware exposes it (Settings → Debug, or query `/api/system/log`). Capture 60 seconds of logs across a connect-auth-disconnect cycle and review the full JSON exchange. The pool's rejection often includes a specific error string that AxeOS truncates in the default web-log view.

If you run a self-hosted pool (MiningCore, NOMP, ckpool), check the pool-side log — the server tells you exactly why auth was rejected with far more detail than the client sees. For managed pools, check the pool's documentation for username-format requirements, address-whitelist policies, or geo-blocking.

Build ESP-Miner from source with verbose Stratum logging enabled. Clone `github.com/bitaxeorg/ESP-Miner`, enable DEBUG-level logging in `stratum_api.c`, flash over USB. You'll see every byte going out on `mining.authorize` and every byte coming back. This catches UTF-8/ASCII encoding mismatches, whitespace, and character-escape bugs that the normal UI hides. File a GitHub issue if it's a parser bug.

For NerdQAxe++ against username-pools (Kano and similar), fork the NerdQAxe+ firmware and rewrite the `mining.authorize` builder to submit `registered_username.worker` instead of `btc_address.worker`. Stock ESP-Miner assumes address-auth. Issue #501 in `shufps/ESP-Miner-NerdQAxePlus` tracks this; a pool-auth-style configuration toggle is the correct long-term fix.

Flash a known-good official ESP-Miner release via OTA (NOT via Web Flasher — Web Flasher's factory image wipes NVS, and your pool settings go with it). OTA preserves config. Reboot into the fresh firmware and observe auth behaviour for 10 minutes — stable `result: true` means the previous firmware had a bug.

Run Wireshark or tcpdump on your router or on a laptop in promiscuous mode during Bitaxe boot. Capture the TCP stream to the pool host and reconstruct the stratum exchange. This is the nuclear diagnostic — you see everything, including TLS interception by corporate firewalls or stratum-protocol rewrites by some ISPs. If the Bitaxe is sending a correctly-formed `mining.authorize` with a valid address and the pool still rejects, the problem is pool-side, not client-side.

Stop DIY and escalate. If address is validated, URL and port are correct, alternate pools also reject, and Wireshark confirms a well-formed `mining.authorize` — open a D-Central support ticket at https://d-central.tech/contact/ with the log capture and hardware revision. For confirmed firmware bugs, file on ESP-Miner GitHub issues with the same capture. D-Central's Bitaxe support usually resolves this class of error inside one ticket from a screenshot of your AxeOS Settings page.