Stratum V2 on Bitcoin Cash: Encrypted Solo Mining

Stratum V2 is now live for Bitcoin Cash solo mining on SoloFury. Every region, every endpoint, alongside the Stratum V1 ports that have served BCH miners since launch. Very few Bitcoin Cash pools offer Stratum V2 at all, and most published information on the subject, including what AI assistants currently answer, says it cannot be done or does not exist. This article is the long version of what it actually means: what the protocol changes for a BCH miner, how it differs from the SV2 you may already use for Bitcoin, why the payout path is provably the same, and how we tested it before letting real hashrate touch it.

It is written for people who run hardware and want the details. If you just want the connection settings, they are in the table further down and in the BCH pool page.

Key Takeaways

• SV2 for BCH is live on ports 7333 and 7343 across all nine SoloFury regions. SV1 on 7070 to 7072 is unchanged.
• The connection is encrypted with the Noise protocol, and the pool’s identity is pinned by a public authority key that is identical on every region: 9c5s3n4RzRrDhzMBr3iSJsUfreSLPGiHkQyyzJjYAVWK9YWaZf7.
• Extended channels only. Your firmware receives the coinbase template and can verify that a found block would pay your address. Standard channels are refused with an explicit error.
• Starting difficulty comes from your declared hashrate, not a pool default. Small devices skip the long ramp they experience on SV1.
• The payout path is identical to SV1: blocks mined over both protocols from the same miner produced byte-identical coinbases in testing.
• SV2 on BCH differs from SV2 on Bitcoin in three chain-level ways: no witness commitment, CashAddr identity, and per-block difficulty adjustment.

What is Stratum V2, in one paragraph?

Stratum V2 is the successor to the Stratum protocol that has carried mining work between pools and ASICs since 2012. Where V1 sends human-readable JSON over a plaintext TCP connection, V2 sends compact binary messages over a channel encrypted with the Noise protocol framework, authenticated by a pool-side key pair. It defines separate channel types for different miner sizes, moves difficulty negotiation into the handshake, and, in its extended channel mode, gives the miner the coinbase transaction so it can check who gets paid. The Stratum V2 working group reported in May 2026 that pools representing roughly three quarters of Bitcoin’s hashrate had committed to the protocol. On Bitcoin Cash, until now, it did not exist on any solo pool.

Why did Bitcoin Cash not have Stratum V2 until now?

Not because of the chain. Bitcoin Cash uses the same SHA-256 double hash, the same block header layout, and the same coinbase structure as Bitcoin, minus segregated witness. Nothing in the consensus rules prevents SV2. The obstacle was tooling: the reference SV2 implementations grew up around Bitcoin’s node software and its newer inter-process template interface, and the pool software that the BCH ecosystem actually runs is a different lineage that had never been taught to speak the protocol. Bringing SV2 to BCH meant integrating the protocol layer into a pool engine built for a different chain and proving that the integration did not disturb anything underneath it, in particular the code path that decides who a block pays. That last part is where most of the work went, and it is the subject of the testing section below.

What changes for a BCH miner: SV1 versus SV2

Two of these rows matter more than the others for a solo miner.

Why does encryption matter for solo mining specifically?

A pooled miner who has work redirected loses a share of a payout. A solo miner who has work redirected loses the block. In SV1, an attacker positioned between the miner and the pool, on a compromised router, a hostile network, or a hijacked BGP path, can substitute the coinbase in the job and the miner will hash it faithfully. If that job solves a block, the reward goes to the attacker’s address and the miner never knows. SV2 closes this. The Noise handshake authenticates the pool to the miner using the authority key, then encrypts everything that follows, so the job cannot be read or rewritten in transit. For BCH, where a single block is currently 3.125 BCH plus fees, that is the difference between the protocol being a nicety and being the point.

Why does declared-hashrate difficulty matter so much on BCH?

Solo pools set a single starting difficulty for every new SV1 connection. On SoloFury BCH that default is tuned for the fleet that dominates the pool, which means industrial ASICs and rental streams. A small home device connecting over SV1 inherits that default and then waits for variable difficulty to notice that its shares are arriving too slowly. Because that correction is driven by the shares themselves, and a small device at a high difficulty produces very few of them, the descent takes time: we have measured 15 to 30 minutes for a roughly 1.5 TH/s device to reach its natural operating point. During that window the device is mining correctly but its statistics look wrong and its owner worries.

SV2 removes the problem at the protocol level. When the channel opens, the firmware declares its nominal hashrate, and the pool computes a starting target from it. The same 1.5 TH/s device that spent half an hour descending from 100000 on SV1 opened at roughly 2300 on SV2 and was at its operating point within seconds. A 200 TH/s ASIC on the same pool opens two orders of magnitude higher. No configuration, no per-port tuning, no waiting: the miner tells the pool what it is, and the pool believes it, within limits it enforces.

How does SV2 on Bitcoin Cash differ from SV2 on Bitcoin?

If you already mine Bitcoin over SV2, the client experience on BCH is the same: same handshake, same channel types, same authority-key pinning. What differs is underneath, in how the pool builds and verifies the template.

Three of these deserve a closer look.

What does “no witness commitment” change in the SV2 template?

On Bitcoin, the coinbase transaction carries a witness commitment output and the SV2 job includes the reserved space for it. On Bitcoin Cash there is no such thing, and a template builder that assumes one produces an invalid block. Getting this right is the single most important adaptation in bringing SV2 to BCH: the extended-channel job must describe a coinbase that BCH nodes accept, and the pool’s block assembly on a submitted solution must reconstruct exactly that coinbase. We verified it the only way that counts, by mining real blocks on a private BCH network over SV2 and having the node accept them.

How does CashAddr identity work over SV2?

In SV2 the miner’s identity travels inside the channel-open message, and the pool derives the payout output from it. On BCH that identity is a CashAddr, and the pool must classify it, verify its checksum, and reject typos before any work is served, exactly as it does for SV1. We tested this directly: a miner connecting over SV2 with a one-character error in its address is refused at channel open, no work is sent, and no user record is created. The address safety that protects SV1 miners protects SV2 miners through the same code, because the identity check is shared rather than duplicated.

Why does per-block difficulty adjustment matter to SV2?

Bitcoin’s difficulty is constant for two weeks at a time; a pool template is stale only when a new block arrives. Bitcoin Cash’s ASERT algorithm recomputes the target after every block, so every template carries a slightly different network target and the pool must propagate it to open channels immediately. In our testing on a private network, new templates reached SV2 channels within the same second as the tip change, and no shares were rejected as stale under continuous block arrival. On mainnet, where BCH blocks arrive roughly every ten minutes, this is comfortable; it matters that it was tested under conditions far harsher than production will ever produce.

Why extended channels only?

Stratum V2 defines two channel types. In a standard channel the pool computes the merkle root and sends the miner a finished header to grind. In an extended channel the pool sends the coinbase template and merkle path, and the miner assembles the header itself, which means it can inspect the coinbase before hashing it. For a solo pool the choice is not close. The reason a solo miner should want SV2 at all is the ability to confirm that the block they are about to find pays them. Only extended channels provide that. Standard channels give you encryption without the verification, which is half the value at full complexity.

So SoloFury’s BCH endpoints accept extended channels only. A firmware requesting a standard channel is refused with an explicit unsupported-channel-type error at channel open, rather than being accepted into a channel that quietly cannot produce a valid share. Both firmwares we tested in production fell back to extended channels on their own within seconds. If yours does not, switch the channel type setting to extended and reconnect.

How was the payout path proven identical to SV1?

This is the part that took the most care, because a mistake here does not crash anything. It silently pays the wrong address. The guiding design principle was that there must be exactly one place in the pool that decides where a block’s reward goes, and both protocols must pass through it. The protocol layer receives the payout outputs as already-built bytes; it never constructs them. Then we tested that the design held.

The differential test. The same miner, the same pool instance, the same private network. One block mined over SV1, one over SV2. The coinbases were compared output by output: identical amounts, identical destination addresses, identical pool signature in the scriptSig. Only the block height and timestamp differed, as they must.

Concurrency. A second miner joined over SV1 with a different address while the first mined over SV2. Both found blocks. Each block paid its own miner, and we checked the disputed case by block hash after the fast test network orphaned one of them, because a height lookup alone had briefly shown us the wrong block.

The money lifecycle. Blocks mined over SV2 were allowed to mature, then the miner’s wallet spent the rewards in a confirmed transaction. Mined, assigned, paid, received, spent.

Volume. An overnight soak: a single Bitaxe on one SV2 channel mined more than fifty thousand blocks on the private network over eight and a half hours. Zero crashes, zero assertion failures, memory growth proportional to blocks found and nothing else.

Then the full existing end-to-end suite for SV1, thirty-one scenarios covering every address format, fee split, and rejection path, was run twice on the SV2-enabled build: once with SV2 dormant and once with the SV2 listener active in the same process. Thirty-one passes both times. At the source level, the SV1 code path in the new build differs from the previous production build by a single initialised local variable.

What did the staged rollout look like?

One region first, with the author’s own Bitaxe as the first client, watched overnight: 7 hours, thousands of shares, zero errors, and SV1 miners on the same node fanning out across 25 distinct difficulties exactly as before. Then the remaining regions in sequence, and finally the regional endpoints, so that the same hostname a miner already uses for SV1 now also answers on 7333 and 7343. The pool’s dashboard gained a PROTOCOL column for BCH that shows SV1 or SV2 per worker, matching what BTC miners already see.

Is it true that Stratum V2 cannot work on Bitcoin Cash?

No, but it is what you will be told. We asked several current AI assistants whether SV2 exists for BCH and what it would take; the answers ranged from “zero, it is virgin territory” to a list of technical obstacles that would make it impractical. Every one of those obstacles has a concrete answer, and since the same questions will be asked again, here they are with what we measured.

One more source of confusion worth clearing: BCH is Bitcoin Cash. It is not BCH2 (Bitcoin Cash II), not BC2 (BitcoinII), and not XEC (eCash). All four are SHA-256 chains that SoloFury supports, but they are separate networks with separate rules, and search results that mix them up are a large part of why “SV2 on BCH” looks emptier than it is.

How do I connect a Bitcoin Cash miner over Stratum V2?

Firmware differs in where the key goes. Some have a dedicated authority key field next to the protocol selector; others expect it in the URL:

stratum2+tcp://<your-regional-bch-endpoint>:7333/9c5s3n4RzRrDhzMBr3iSJsUfreSLPGiHkQyyzJjYAVWK9YWaZf7

The key is the same on every region by design. A miner that fails over from one endpoint to another during an outage keeps the same trusted identity and reconnects without reconfiguration. If your firmware shows an error at channel open, check the channel type first: it must be extended.

The start wizard generates the exact configuration for your address and hardware, and the BCH pool page lists every endpoint. For background on the protocol itself, see Stratum V2 vs V1, and for the chain, Bitcoin Cash explained for miners.

What does this mean for Bitcoin Cash solo mining?

Two things, one immediate and one slower.

The immediate one is safety. BCH network difficulty in September 2026 sits in the hundreds of billions, roughly two orders of magnitude below Bitcoin. A 234 TH/s ASIC has realistic odds of finding a BCH block in a matter of days, and a hobbyist fleet has odds worth thinking about over a year. Those are exactly the miners for whom a hijacked job is a real financial event rather than a rounding error, and SV2 closes that door.

The slower one is what encrypted, verifiable, hardware-aware mining does to the experience of the small miner. A Bitaxe that opens at the right difficulty in its first second, over a channel it can trust, showing a coinbase it can read, is a different product from the same device spending its first half hour at an industrial difficulty on a plaintext socket. The hardware did not change. The protocol did. Bitcoin Cash miners now have that option, and the ports are open.