Stratum V1 vs V2 Protocol Mismatch — Miner Won’t Connect

Open your firmware's pool configuration page. Note exactly what's in each pool slot — URL, port, username, password — and screenshot it before changing anything. If you're on stock Antminer, Whatsminer, Avalon, ESP-Miner, NerdMiner, NerdAxe, NerdQAxe, or NerdNOS firmware, you are SV1-only by definition; skip ahead to Step 3. If you're on DCENT_OS, Braiins OS+, LuxOS, or Vnish, continue to Step 2.

Toggle Stratum V2 OFF in your firmware's pool settings. The setting lives in different places per firmware: DCENT_OS exposes it on the Pool config page; Braiins OS+ uses a `protocol: stratum-v2` line in its TOML config; LuxOS has a per-slot toggle; Vnish exposes it under Advanced Pool Settings. Save the change, reboot the miner. Wait 90 seconds. If hashrate begins climbing, you confirmed an SV2 mismatch.

Switch to a known-good SV1 pool as a control. Set Pool 0 to `stratum+tcp://public-pool.io:21496` (Bitaxe / open-source) or `stratum+tcp://stratum.slushpool.com:3333` (any ASIC). Username = your on-chain BTC address. Password = `x`. Save, reboot. If shares start landing, the original configuration was hitting an SV1↔SV2 mismatch on the original pool side.

If you specifically want SV2 (encrypted transport, Job Negotiation, sovereignty) and your firmware supports it, switch to a pool that supports it. As of 2026-04 that's Braiins Pool (`stratum.braiins.com:3333` with the SV2 toggle on) or D-Central's pool when its SV2 endpoint goes live. Set the URL, enable the SV2 toggle, save, reboot. Watch the firmware log for `Noise handshake complete` and `Channel opened`.

Cross-reference the pool support matrix one more time before walking away. As of writing, Antpool, F2Pool, ViaBTC, Public Pool, and `solo.ckpool.org` are SV1-only. Do not waste time trying to enable SV2 against a pool that doesn't speak it. Verify your target pool against its current docs before changing firmware settings.

Capture the actual stratum traffic with `tcpdump`. From a laptop on the same LAN, run `sudo tcpdump -i any -A -s 0 host <pool-host> and port <pool-port> -w stratum.pcap`. Boot the miner. Capture for 60 seconds. Open the pcap in Wireshark. SV1 traffic shows readable JSON-RPC strings starting with `{`; SV2 traffic shows binary length-prefixed frames where the first 16 bytes are the Noise `e` ephemeral key.

Hand-test SV1 reachability with `nc`. Run `nc -v <pool-host> <pool-port>`. Paste literally: `{"id": 1, "method": "mining.subscribe", "params": ["test"]}` followed by a newline. An SV1 pool replies with `{"id": 1, "result": [...] }` within a second. An SV2-only endpoint either closes the connection or hangs silently. Fastest way to confirm what the pool actually speaks at that port without involving the miner.

Hand-test SV2 reachability is harder because SV2 requires a Noise-protocol library to send a valid `SetupConnection` frame. Use the SRI mining-proxy test harness, or note that SV2 endpoints often live on a non-standard port (`:3336`) distinct from the SV1 port. If `nc -v <pool-host> 3336` shows `Connection refused` but `:3333` connects cleanly, the pool likely doesn't have an SV2 listener.

Run an SV1-to-SV2 translation proxy if you need an SV1-only miner to talk to an SV2 pool, or vice versa. The SRI project (github.com/stratum-mining/stratum) ships `translation-proxy` for exactly this case: it accepts SV1 from your stock-firmware miner on one side and speaks SV2 to the upstream pool on the other side. Deploy on a spare Raspberry Pi or a small VPS in the same region as the pool.

Roll firmware versions strategically. If the protocol toggle exists but enabling SV2 produces no shares, check the firmware changelog for SV2-specific fixes since your installed version. Braiins OS+, DCENT_OS, LuxOS, and Vnish have all shipped SV2 fixes in 2024-2026. Running an older build against a current SV2 pool can fail at the channel-open stage even though both sides claim SV2 support. Roll forward to the latest stable, retest.

Deploy a self-hosted SRI Job Negotiator + Translation Proxy for a multi-miner farm. Architecture: miners speak SV1 to your local proxy on the LAN; proxy speaks SV2 to your upstream pool; the local Job Negotiator runs alongside a local `bitcoind` and proposes block templates from your own mempool. Maximum-sovereignty configuration. SRI documentation provides reference deployments for `docker-compose` and `systemd`. Budget a weekend for first deployment.

Build DCENT_OS or Braiins OS+ from source with verbose stratum logging if pre-built binaries don't give enough log detail. DCENT_OS is open-source on GitHub (DCentralTech/DCENT_OS) — clone, enable `STRATUM_LOG_LEVEL=DEBUG`, rebuild, flash. Every byte going out and coming back gets logged. Catches negotiation bugs, padding errors, encryption mismatches, and Noise-handshake failures that a stock build silently buries.

Patch your firmware to expose SV2 telemetry if you operate at scale. DCENT_OS and Braiins OS+ both expose Prometheus metrics for stratum-layer events — channel opens, channel closes, share submissions per channel, encryption handshake duration. Wire those metrics into Grafana and you'll see protocol mismatches in seconds rather than hours, across an entire farm.

Contribute upstream when you find a real bug. SV2 is still maturing; firmware implementations have edge cases. If you've isolated a reproducible mismatch — wrong handshake sequence, wrong channel-open handling, wrong difficulty negotiation — file an issue in the relevant repo (DCENT_OS, Braiins OS+, SRI, your firmware vendor's tracker) with your `tcpdump` capture and firmware version. Decentralized mining infrastructure improves at the rate operators publish their bugs.

Stop DIY and escalate. If firmware is current, pool definitively supports the configured protocol, URL prefix is correct, an SV1-fallback test works, and `tcpdump` confirms well-formed protocol frames going out — and the pool still doesn't deliver work — you're either looking at a pool-side outage, a firmware bug specific to your hardware revision, or a network-path issue (DPI, MTU mismatch, IPv6/IPv4 dual-stack confusion). Open a D-Central support ticket at https://d-central.tech/contact/ with your tcpdump capture, firmware version string, and pool selection.

For Antminer fleets that need SV2 today, the fastest path is to flash DCENT_OS — D-Central's own open-source Antminer firmware. SV2 is one of DCENT_OS's flagship features alongside per-chip HW% diagnostics and autotuning. Built by Mining Hackers, maintained in public, no licensing fees, no vendor lock-in. Braiins OS+, LuxOS, and Vnish are alternatives if you prefer commercial backing. Visit d-central.tech/dcent-os for the current build and flash instructions.