BzMiner 100.70 lets MoneroOcean choose the mining algorithm
Source report: 2026-11-05 · Editorial analysis published: 2026-11-05
The November 5 release adds pool-directed switching, cached hardware benchmarks and separate GPU/CPU connections. The pool’s choice still needs to be checked against electricity costs.
The pool can change the work without changing the connection
BzMiner 100.70, published on November 5 at 00:40 UTC, adds algorithm switching through MoneroOcean. An algorithm is the computing task the miner performs. Instead of keeping a graphics card on one task all day, this mode lets the pool request a different supported task when its own comparison favours it. For owners already moving between several coins, it can reduce manual changes to the mining setup.
The miner first tells the pool which algorithms the rig can run and its speed on each. Every new job names the algorithm the pool currently considers most profitable, and BzMiner follows that instruction. The decision comes from the pool; the new mode is not a local calculator reading your electricity bill. A connection using a Monero wallet does not mean every graphics card must work on Monero’s RandomX algorithm.
The release calls the mode mo or moneroocean. It is also different from the Pearl+C29 dual route: switching chooses a task for the connection, while dual mining works on two algorithms together. That distinction helps explain what a pool dashboard and the miner’s logs should show. Two advertised workloads in a configuration do not by themselves prove that both are running simultaneously.
A useful switching decision starts with the right speed figures
The default offered set is kawpow, ergo, etchash, cn/gpu, pearl and c29. RandomX is excluded by default because its large dataset can leave GPUs parked when the pool chooses it. Owners can add it to the offered list, but a longer list is not automatically a better list. The useful set depends on the actual devices intended to work through that connection.
On the first run, BzMiner measures algorithms that lack a saved rate. It keeps the results in mo-perf.json, associated with each card’s PCI identifier, the address that distinguishes devices inside the computer. Later starts reuse matching results when the requested overclock settings still agree. Changing a selected tuning profile causes the affected card and algorithm to be measured again.
This makes the cache part of the mining configuration, rather than a decoration in the installation folder. Setting the benchmark duration to zero skips fresh measurements and offers only matching cached rates; it does not manufacture missing performance data. After changing tuning, check what the miner actually advertises. A pool comparing an unsuitable speed estimate is solving a different problem from the one your hardware presents.
Keep CPU and GPU work on separate connections
The official examples offer Pearl, CryptoNight-GPU and C29 for a GPU-only connection. A separate CPU connection can offer RandomX alone. With just one algorithm offered on that CPU connection, the processor stays on RandomX; there is no second eligible task for the pool to select. An automatic-switching label therefore does not mean that every device will constantly change algorithms.
For a machine using both kinds of device, the release shows separate connections. The reason is practical: choosing a GPU algorithm must not leave the CPU waiting for work it cannot do. Think of two different workstations sharing one building: they can use the same provider without needing the same job. Device selection and the algorithm list need to describe the same group of hardware.
The project links MoneroOcean’s Multi-Miner as an explanation of the same pool-directed switching approach. That separate program can add switching to miners that do not implement it themselves. BzMiner now describes a native connection mode, so the announcement is not an instruction to install another wrapper automatically. Use documentation for the version and arrangement you actually choose, rather than combining unrelated example configurations.
Judge the result by accepted work and the electricity meter
The release also reports better Pearl hashrate and efficiency on NVIDIA Ampere, Ada and Blackwell and AMD RDNA4, plus a fix for missing GPU hashrate in some MMPOS dashboards. It supplies no universal improvement percentage. A corrected display is useful for monitoring, but a larger displayed number alone does not establish more accepted work or a lower electricity bill.
For a controlled comparison, record the algorithm chosen, useful work credited by the pool, whole-system power and the period spent measuring or changing tasks. Include the pool’s payout rules and fees in the income calculation. Comparing only the fastest moments can hide the time between them; comparing two different market periods can also mistake a coin-price change for a software improvement. Keep the hardware and driver unchanged during that comparison, so a second change does not hide the effect being tested.
The official release provides platform packages and SHA-256 checksums, which identify the published files but are not an independent security audit. This report used the release and documentation without running a miner. The practical change is more flexible job selection with saved hardware measurements. Whether it improves a particular farm’s net result remains a question for that farm’s power cost, workload and pool records.
Source: BzMiner ↗ · Official BzMiner documentation ↗ · MoneroOcean switching protocol documentation ↗
Mining calculator ↗
