Stratum V2 has been a Bitcoin story so far. The reference implementations grew around Bitcoin Core, the spec has PRs dedicated to segwit coinbase conventions, and if you search for "SV2 on Bitcoin Cash" you mostly find people explaining why it cannot be done. I spent the last few weeks finding out whether that was true, and it is not. SV2 has been running on our BCH endpoints for a few days now, with a real Bitaxe and Braiins hardware on the other end.
This post is about the technical side, since that part is not written down anywhere else. If you just want the settings, they are in the write-up linked at the bottom.
The three things that actually differ on BCH 1. No witness commitment. The SV2 spec assumes a segwit coinbase; there are PRs in sv2-spec specifically adding BIP141 conventions and witness_reserve_value to the Template Provider. On BCH that output does not exist, and a template builder that reserves space for it produces an invalid block. This is the single most important adaptation, and the only way to be sure you got it right is to mine real blocks on a private BCH network and have the node accept them.
2. CashAddr identity. In SV2 the miner's identity arrives inside the channel-open message and the pool derives the payout output from it. That means the address classifier — including checksum validation — has to be reachable from the SV2 auth path, not just the SV1 one. A typo'd address must be refused at channel open, with no work served.
3. Per-block difficulty. ASERT recomputes the target after every block, so every template carries a slightly different network target and it has to reach open channels immediately. Bitcoin's two-week difficulty period is comparatively forgiving here.
What people get wrong about the obstacles The objection you hear most is that SV2 needs the node's inter-process template interface, which BCH nodes do not have. That interface is needed for the Job Declaration proxy path. A pool-side SV2 server needs a block template and a new-block notification, and BCH nodes provide both today. Job Declaration is a separate feature, and for a solo pool it is not the interesting one anyway: JD exists so pooled miners can resist transaction censorship by the pool, while a solo miner is the sole beneficiary of the block and just needs to verify the payout — which extended channels give you.
The other one is that firmware "does not support BCH over SV2". Firmware is chain-agnostic: it speaks SV2 to whatever pool you point it at. AxeOS and Braiins OS+ both opened extended channels against our BCH endpoints with no BCH-specific setting. What is missing is cosmetic — AxeOS decodes the coinbase assuming Bitcoin, so a BCH template shows a "BTC" ticker and Base58 addresses instead of CashAddr. I have opened an issue on ESP-Miner about it.
The part I would want to see from anyone claiming this works A protocol port that touches the payout path is dangerous in a specific way: a mistake there does not crash anything, it silently pays the wrong address. So the design rule was that exactly one place in the pool decides where a block's reward goes, and both protocols must pass through it — the protocol layer receives payout outputs as already-serialised bytes and never builds them.
Then I tested that it held. Same miner, same pool instance, one block mined over SV1 and one over SV2, coinbases compared output by output: identical amounts, identical addresses, identical pool signature. Concurrent SV1 and SV2 miners with different addresses, each block paying its own miner (verified by block hash, because the fast test network orphaned one and a height lookup showed me the wrong block for a moment). Full money lifecycle: mined over SV2, matured, spent in a confirmed transaction. An overnight soak of 52k blocks on a single channel, zero crashes. And the existing 31-scenario end-to-end suite for SV1 run twice on the SV2-enabled build — once with SV2 dormant, once with the listener active in the same process — 31 passes both times.
One thing that surprised me SV2 solves the small-miner difficulty ramp for free. On SV1 a solo pool hands every new connection the same starting difficulty, tuned for the fleet that dominates the pool, and vardiff takes 15-30 minutes to walk a 1.5 TH/s device down from it. On SV2 the miner declares its nominal hashrate when the channel opens and the pool computes a matching target: the same device opened at ~2300 and was at its operating point in seconds. That is a bigger deal for a home miner than the encryption, day to day.
Known limitation Standard channels do not work and are refused with an explicit error. Upstream's standard share path submits with a null extranonce, so a ckpool-style stratifier rebuilds a different merkle root than the one it sent and every share scores zero difficulty. Rather than accept a channel that can never pay, we refuse it at open. Both firmwares fell back to extended on their own. Worth knowing if anyone else goes down this road.
Full technical write-up, including the SV1/SV2 comparison and the connection settings:
https://solofury.com/blog/stratum-v2-bitcoin-cash-solo-mining/ Happy to answer technical questions here, and if anyone wants to point hardware at it to reproduce any of the above, the endpoints are public.
