Windows Multi-PC Mining Manager + Coin Discovery

[BlackMica]

# Building a Windows Multi-PC Mining Manager with Speculative Coin Discovery — Feedback Wanted

I have been developing a Windows-based mining management system and I would like some feedback from experienced miners before I decide how far to take the public release.

This is not intended to be another simple front-end for launching miners, and it is not based on RainbowMiner.

The project has developed into a central controller/worker system that can manage mining across one PC or multiple Windows PCs containing mixed AMD GPUs, NVIDIA GPUs and CPUs.

The longer-term goal is to package the completed system into a normal Windows installer with a GUI so the underlying scripts, configuration and controller logic are hidden from the user during normal operation.

At the moment I am mainly interested in whether other miners think the concept is useful, what they would distrust about it, and what would need to be included before they would consider running something like this on their own machines.

## What problem I am trying to solve

Most of the mining tools I have used or looked at tend to concentrate on one of two things:

1. launching/configuring miners; or
2. switching to whatever appears most profitable at the time.

I wanted something that could do those things, but also answer a different question:

**What is the best use of the hardware I actually own, including opportunities that may not currently be the most profitable coin on a calculator?**

That led to adding a separate speculative mining system.

The intention is to support both:

**Profitability mining** — mine according to current economics.

**Speculative mining** — deliberately allocate hardware to selected mineable projects that may currently return less but that the user wants to accumulate.

The user chooses the strategy. The software should not silently decide that an obscure coin is somehow an "investment".

## Central controller + workers

The system uses a controller/worker architecture.

Each mining PC runs a worker. The controller maintains the overall state of the mining network and knows what hardware is available on each machine.

For example, the same installation could contain:

* one PC with a modern AMD GPU and CPU;
* another with an NVIDIA GPU;
* another with an older AMD card;
* a CPU-only system;
* and a general-purpose PC that is only allowed to mine under certain conditions.

They do not all have to mine the same coin or algorithm.

Hardware can be assigned independently.

The controller is responsible for deciding what should run. Individual miners are treated as execution engines rather than as the decision-making layer.

## It does not depend on RainbowMiner

RainbowMiner was investigated earlier in development, but it is being phased completely out of the final system.

The finished design has its own:

* controller;
* worker management;
* switching logic;
* validation;
* state tracking;
* rollback;
* scheduling;
* benchmarking;
* wallet handling;
* and execution controls.

Third-party miners such as XMRig and GPU miners can still be used where appropriate, but only as subordinate mining engines.

The intention is that a miner can be replaced or upgraded without changing the architecture of the entire system.

## Coin discovery

One part I would particularly like feedback on is the discovery system.

Instead of only working from a fixed list of known coins, the system can search for mineable cryptocurrencies and create candidate records.

A coin being discovered does NOT mean it is automatically mined.

It has to move through validation stages first.

The system attempts to establish things such as:

* Is the coin genuinely mineable?
* What algorithm does it use?
* Does the available hardware support it?
* Is there an appropriate miner?
* Is there a pool?
* What wallet/network requirements exist?
* Is there usable market information?
* Is there meaningful liquidity/trading information?
* Is the source data recent and consistent?
* Can a complete payout route actually be established?

Conceptually, the execution chain is:

**Coin -> Algorithm -> Hardware -> Miner -> Pool -> Wallet**

If one part of that chain cannot be validated, the system can stop the candidate at that point instead of making assumptions.

## Speculative discovery

The speculative side is not intended to be "mine random low-cap coins".

Candidates can be researched and filtered before they ever become eligible for mining.

For example, imagine:

Coin A currently returns about $2/day on a GPU.

Coin B returns about $1.50/day.

A normal profit switcher will probably choose Coin A.

With speculative mining enabled, Coin B could still be considered if the user deliberately wants exposure to it and it has passed the required technical and data-validation gates.

The important part is that the reason for mining it is visible.

The GUI should distinguish clearly between:

**"This is being mined because it currently has the better estimated return"**

and

**"This is being mined because it is part of the user's speculative strategy."**

## Real hardware benchmarking

I don't want the system relying entirely on internet hashrate tables.

Candidates can be benchmarked against the actual CPU or GPU that may mine them.

This matters because estimated performance can differ significantly from what a particular card, driver, miner version or power configuration actually produces.

The benchmark becomes part of that device's local performance history.

So the system may eventually know that:

GPU A performs particularly well on Algorithm X,

while GPU B, even though theoretically similar, performs badly enough that another option makes more sense.

The aim is for decisions to increasingly use measured hardware performance rather than generic assumptions.

## Switching logic

I also do not want constant profit hopping.

A 2-minute profitability spike should not necessarily restart a miner.

The controller can use switching thresholds, confirmation periods and other conditions before authorising a change.

A candidate can also remain on HOLD if something required for execution is not verified.

This is one area where I would particularly appreciate feedback from miners who have used profit switchers:

**What switching behaviour annoys you most in existing software?**

## Wallet management

Wallet information is managed centrally.

The intention is to avoid having wallet addresses duplicated across a collection of miner batch files and configuration files.

A discovered coin may exist in the research system without being operationally ready.

Before mining it, the appropriate wallet/network configuration has to exist and pass the required checks.

I am deliberately keeping the wallet system separate from the discovery decision because I do not want:

"Interesting coin found"

to automatically become:

"Start mining it somewhere and hope the wallet details are correct."

## Failure recovery

A lot of development work has gone into preventing a failed switch from leaving a mining PC in a broken state.

The system maintains known working state information.

If a new mining configuration fails, it can attempt to return the machine to the previous known-good state.

The principle is:

**Failed change -> rollback**

rather than:

**Failed change -> leave the worker half-configured**

There are also checks around which processes the mining system actually owns.

If a PC is doing something else, the controller should not simply kill unrelated processes because it wants to change a mining task.

## Research-only mode

The system can also operate without autonomous mining.

In that mode it can:

* discover coins;
* validate them;
* research them;
* benchmark them;
* maintain candidate information;
* and show opportunities in the GUI;

without actually starting anything.

I think this may be useful to people who do their own speculative mining and want discovery/research assistance without handing execution control to software.

## Planned GUI

The final system is intended to be usable without PowerShell or manually editing batch files.

The GUI should show things such as:

* all enrolled PCs;
* detected CPUs/GPUs;
* online/offline status;
* current mining assignment;
* algorithm;
* miner;
* pool;
* wallet readiness;
* current hashrate;
* benchmark history;
* profitability candidates;
* speculative candidates;
* failed/held candidates;
* warnings;
* controller/worker status;
* and mining history.

Advanced users should still be able to see why a decision was made rather than just being shown a big green "Mining" indicator.

Transparency is important because I personally would not trust autonomous mining software that could not explain what it was doing.

## Security / trust

This is probably the biggest issue if the software is ever released publicly.

A central mining controller potentially has the ability to:

* start executables;
* stop executables;
* change mining assignments;
* use wallet addresses;
* communicate with multiple PCs;
* and download/update supported mining components.

That needs to be treated as a security problem, not just a convenience feature.

The controller/worker system therefore uses controlled execution rather than simply allowing arbitrary commands to be pushed to a worker.

Before a public release I also want the user to be able to see exactly:

* what miners are authorised;
* what executable is being launched;
* which pool is being contacted;
* which wallet is being used;
* what triggered a switch;
* and what changed on the worker.

This is an area where criticism is welcome.

If you saw software like this offered publicly, **what would you need to inspect or verify before you trusted it?**

## Distribution

The current intention is to eventually package it as a standard Windows installer.

The aim is for the software itself to be free.

I am considering an optional, clearly disclosed donation-mining mechanism to help support continued development.

If included, it would be visible, limited and optional rather than hidden developer mining.

I know donation/developer mining can be controversial, so I am also interested in opinions on whether that is acceptable at all, even when completely transparent.

## What I am looking for from this thread

I am not asking for investors, pre-orders or anyone to download an unknown executable.

At this point I am looking for experienced mining feedback.

In particular:

**Would you have any use for a system that combined multi-PC management, hardware benchmarking, profit-based mining and speculative coin discovery?**

Also:

**What existing mining software currently does this better?**

**What would make you immediately reject a system like this?**

**What security information would you require before installing it?**

**Would you prefer full automatic control, recommendation-only mode, or both?**

**How much control should the user have over speculative coin selection?**

**Would central wallet management be useful, or would you prefer wallet information to remain entirely external?**

And for people with mixed AMD/NVIDIA/CPU setups:

**What is the biggest problem you currently have managing different miners and algorithms across multiple Windows machines?**

I am quite happy to hear reasons why the idea would not work as well as reasons why it might.

At this stage, critical technical feedback is probably more useful to me than positive comments.

[shyquisyz]

Not an expert, just someone mining on one everyday PC, so take this with a grain of salt.

The part I'd actually use is the "general-purpose PC that only mines under certain conditions." For me that means capping GPU usage (I keep mine around 50%, at 100% the PC gets laggy) and pausing when I'm using it. If that's easy to set per PC, that alone would make me try it.

On trust: I'd want recommendation-only mode first, and to see exactly which exe, pool and wallet it's using before letting it run on its own.

The speculative mode makes sense to me too. Some people mine a coin because they want to hold it, not because it tops a calculator.

[BlackMica]

Thanks, that is actually very useful feedback, especially because I want the system to work for ordinary PCs as well as dedicated mining rigs.

The “general-purpose PC” side is something I think I should expand.

Rather than just enabling or disabling a PC, I’m thinking each machine could have its own usage policy. For example:

* mine only when the PC is idle;
* pause when keyboard/mouse activity is detected;
* resume after a configurable idle period;
* limit how heavily the GPU is used;
* restrict or disable CPU mining while the PC is being used;
* set allowed mining hours;
* and stop or reduce mining if temperature limits are reached.

The exact way a 50% GPU limit is achieved may differ between miners and algorithms, but I’d like the GUI to make that simple rather than expecting the user to know every miner’s intensity settings.

I also agree with you about trust.

I’m planning for a recommendation-only mode where the controller can do all the discovery, benchmarking and decision making but show you exactly what it proposes before anything is launched.

Ideally you would be able to see:

Coin → PC/GPU → exact miner executable → pool → wallet → reason for the recommendation

and then approve or reject it.

That would also give people a way to build confidence in the system before enabling automatic control.

Your point about speculative mining is exactly the reason I want it kept separate from normal profitability switching. If somebody specifically wants to accumulate a certain coin, the controller should optimise the best way to mine that coin rather than abandoning it just because another coin temporarily tops a calculator.

Thanks — the per-PC “mine without interfering with normal use” controls are definitely something I’m adding to the requirements.

[shyquisyz]

Sounds great, the idle and keyboard/mouse pause would cover most of it for me.

One small thing: the miner I'm using now has a simple GPU % slider plus a setting for how long the card can be held in one go. Lower feels smoother while I'm using the PC, higher is faster. Having both in one place made it easy to find a balance, so something like that in your GUI would be nice.

Good luck with it, I'll keep an eye on the thread.

[FP91G]

# Building a Windows Multi-PC Mining Manager with Speculative Coin Discovery — Feedback Wanted

Similar projects are very slow to add new coins that might show promise in the future.
I tell all miners to look into Hive OS, because mining software is released for this platform first. It allows you to run any custom Linux-based miner.

Windows is a poor choice for mining. the OS consumes memory from the primary graphics card, and software updates are released later.
Remotely administering Windows is also inconvenient.

[BlackMica]

I agree that for a dedicated mining rig HiveOS/Linux has some clear advantages, particularly lower OS overhead, easier remote administration and the fact that some miners/releases appear on Linux before Windows.

The reason I’m starting with Windows is that this project is intended to be more than a conventional mining manager or mining OS.

One of the main goals is to make use of machines that may already be normal Windows PCs as well as dedicated mining systems. A machine might only mine while idle, use restricted GPU resources while someone is using it, or participate temporarily when the controller needs additional hardware for a particular objective.

The other major difference is the discovery/controller side.

I’m trying to address exactly the issue you mentioned about existing systems being slow to add new coins.

The system is being designed with a New Coin Radar that can discover very recent CPU or GPU mineable coins before they necessarily appear on the normal mining aggregators. A new coin would initially appear for investigation rather than automatically being trusted or mined.

The controller can then work through things such as:

Coin → algorithm → compatible CPU/GPU → miner → pool → wallet → benchmark

and continue evaluating the coin as more information becomes available.

The user could manually authorise an extremely new coin they want to accumulate, while the controller still decides which available PC, CPU/GPU, miner, pool and configuration is best for mining it.

There are also other objectives being built around the controller, such as speculative mining, completing outstanding pool payouts with several workers, hardware-specific benchmarking and recommendation-only operation before giving the software autonomous control.

So I don’t really see it as trying to replace HiveOS for somebody who already has a dedicated Linux mining farm.

It is more about putting an intelligent management/discovery layer over a collection of machines and making that accessible to Windows users who may not want to convert their PCs into dedicated Linux mining rigs.

That said, your point about miners sometimes being available on Linux first is a good one. Architecturally I think it would be sensible not to design the controller in a way that permanently prevents a Linux worker from being added later, even though Windows is the initial target.

[LazMiner]

I am working on something similiar but with AI hosting on Vast.ai, Cloreai and more to come. Also in combination with my own GPU miner.
The overview app will be released in beta in the next months. Coins will be updated every day and a solution for automated search is also in development. But you can also add coins by yourself easily

The miner will be available for windows and linux (ubuntu) and Hiveos later, the overview app is for windows, and the client agents for linux ubuntu (cloreai and vastai need ubuntu) and windows for sure

I think many people have this idea at the moment.

This is not my thread so i won´t post links to my X Account and website here, but i think i will open a thread for my miner the next days.

[BlackMica]

That sounds interesting, especially combining mining with AI hosting on Vast.ai and Clore.ai. I think you are probably right that quite a few people are starting to look at ways of making better use of GPUs instead of treating mining as one fixed workload.

My project has also expanded quite a bit since I first started working on it.

The basic idea is now a central controller that can scan the local network, discover PCs, and let the user decide which machines should become mining workers. Each worker then has its own hardware profile, benchmarks and mining rules rather than assuming every machine is identical.

The scanner side is also becoming more important. I am keeping the deeper coin scanner, but I am also adding a separate **New Coin Radar** intended to look for very new mineable coins that may only be a few hours old.

The Radar will not rely on just one source such as MiningPoolStats because, as others have pointed out, those services can be several hours behind a new launch. The idea is to eventually use several sources such as ANN posts, pool coin lists/APIs, project repositories/releases, miner releases and other early sources.

Anything the Radar finds is only treated as a candidate. It still has to work through checks for things such as identity, live mainnet, algorithm, hardware compatibility, miner support, pool availability and wallet requirements before it can become a normal mining candidate.

Another feature I am working toward is separating **what the user wants to achieve** from **what the hardware actually mines**.

For example, one mode will allow the user to manually choose:

**Pool + payout coin + payout wallet**

and then leave the controller to decide which supported underlying coin each CPU or GPU should actually mine for the best practical return.

So if the selected payout is BTC on an auto-converting pool, one CPU may be mining one coin while an AMD GPU and NVIDIA GPU are mining completely different coins, but they are all working toward the same BTC payout.

The controller will eventually use the real benchmark performance of each individual machine rather than relying only on published hashrates.

There is also a **Payout Completion Queue** being designed. Instead of leaving small balances sitting on several pools indefinitely, the controller can look at the remaining balance needed for each payout, estimate the mining effort required, concentrate suitable workers on the easiest practical payout, complete it, confirm the payout and then move to the next one.

Some of the other things being added are:

* automatic CPU thread-count benchmarking, because maximum threads are not always the fastest setting for every algorithm;
* worker-specific CPU and GPU benchmarks;
* different mining rules for each PC;
* idle-only mining for everyday computers;
* reduced GPU workload modes so a normal desktop can remain usable;
* automatic selection of the best worker/device for a job;
* support for different miners through adapters;
* central wallet and payout-address management;
* pool validation;
* post-switch verification so simply starting a miner process is not considered success — the controller should confirm pool connection, hashrate and share activity;
* rollback to the previous known-good configuration if a mining change fails;
* recommendation-only mode where the system shows exactly what it intends to run before the user allows it;
* several levels of automation, from monitoring only through to controlled automatic optimisation;
* continuous re-evaluation while a coin is being mined, so a better miner, pool, thread count or piece of hardware can be used later without changing the user's actual objective.

There will also be a manual coin mode. In that case the user can say, effectively:

**“I want to accumulate this particular coin.”**

The controller can still optimise the machine, miner, pool and settings, but it should not abandon that coin simply because something else becomes more profitable.

The architecture is Windows-first at the moment, although I am trying not to design the worker/controller protocol in a way that would make a Linux worker impossible later.

One thing your project has that mine does not currently concentrate on is the AI-hosting side. That is quite interesting because it introduces another decision for the controller: whether the GPU is worth more at that moment doing AI compute or mining.

I would be interested to see how you handle that scheduling decision, especially when Vast.ai/Clore.ai demand changes and a GPU could move between AI work and mining.

Also interested in how you plan to handle brand-new coins. Will your automated search mainly discover coins once they appear on established mining sites/pools, or are you planning to watch launch announcements, repositories and miner releases as well?

It sounds like we are approaching the same general problem from different directions, which is probably a good thing. There are quite a few interesting problems to solve beyond simply choosing the coin with the highest number on a profitability table.

[FP91G]

I agree that for a dedicated mining rig HiveOS/Linux has some clear advantages, particularly lower OS overhead, easier remote administration and the fact that some miners/releases appear on Linux before Windows.

The reason I’m starting with Windows is that this project is intended to be more than a conventional mining manager or mining OS.

One of the main goals is to make use of machines that may already be normal Windows PCs as well as dedicated mining systems. A machine might only mine while idle, use restricted GPU resources while someone is using it, or participate temporarily when the controller needs additional hardware for a particular objective.

The other major difference is the discovery/controller side.

I’m trying to address exactly the issue you mentioned about existing systems being slow to add new coins.

The system is being designed with a New Coin Radar that can discover very recent CPU or GPU mineable coins before they necessarily appear on the normal mining aggregators. A new coin would initially appear for investigation rather than automatically being trusted or mined.

The controller can then work through things such as:

Coin → algorithm → compatible CPU/GPU → miner → pool → wallet → benchmark

and continue evaluating the coin as more information becomes available.

The user could manually authorise an extremely new coin they want to accumulate, while the controller still decides which available PC, CPU/GPU, miner, pool and configuration is best for mining it.

There are also other objectives being built around the controller, such as speculative mining, completing outstanding pool payouts with several workers, hardware-specific benchmarking and recommendation-only operation before giving the software autonomous control.

So I don’t really see it as trying to replace HiveOS for somebody who already has a dedicated Linux mining farm.

It is more about putting an intelligent management/discovery layer over a collection of machines and making that accessible to Windows users who may not want to convert their PCs into dedicated Linux mining rigs.

That said, your point about miners sometimes being available on Linux first is a good one. Architecturally I think it would be sensible not to design the controller in a way that permanently prevents a Linux worker from being added later, even though Windows is the initial target.

You have a good idea, but it comes too late. Nowadays, it isn't profitable to mine cryptocurrency on a standard PC with a single graphics card because the electricity costs are too high. The only exception would be children whose parents pay the electricity bill. A PC needs to be properly prepared for mining, otherwise, it could overheat and break down.
A profitable coin lasts a week or slightly longer, and there is no Windows miner for it. You will always be lagging behind.

[RVNChainScout26]

The per-PC idle/usage policy is the bit I'd care about most. A hard pause on input plus a temperature ceiling is more useful than another aggressive profit switcher; I'd also want the controller to show the exact executable and pool before allowing an automatic switch.

[BlackMica]

The per-PC idle/usage policy is the bit I'd care about most. A hard pause on input plus a temperature ceiling is more useful than another aggressive profit switcher; I'd also want the controller to show the exact executable and pool before allowing an automatic switch.

I agree with you, and those two things are now becoming fairly important parts of the design.

The per-PC policy system is intended to let every computer behave differently.

For example, one dedicated mining PC might be allowed to run continuously, while a normal desktop could be configured to:

- mine only after a certain idle period;
- pause as soon as keyboard or mouse activity returns;
- resume after it becomes idle again;
- obey a maximum temperature;
- limit CPU usage;
- use a reduced GPU workload instead of 100%;
- protect certain applications or workloads;
- only mine during selected hours.

I also agree about showing exactly what will be executed.

I am planning a recommendation/approval mode before unrestricted automatic switching.

Before a proposed switch, the controller should be able to show something along the lines of:

PC / worker  
CPU or GPU  
coin actually being mined  
algorithm  
exact miner executable  
miner version/hash  
pool and endpoint  
payout wallet  
thread count or GPU configuration  
reason the controller selected it

The user can then approve or reject it.

Even if full automation is enabled later, I still want that information available in the GUI so the controller never becomes a black box where you only know that "something changed".

Another important part is post-switch verification. Starting the miner process will not count as a successful switch by itself.

The controller should verify progressively that:

the process started → miner API responds → pool connects → mining job is received → hashrate appears → shares are being submitted/accepted.

If that fails, it should be able to stop the failed configuration and roll back to the previous known-good mining setup.

I am increasingly thinking the resource/usage policies and transparency may be more useful in everyday use than extremely aggressive switching for a few percent extra theoretical profit.

The controller can still optimise profitability, but it should do it inside the limits set by the person using the PC rather than treating maximum hashrate as the only objective.

You have a good idea, but it comes too late. Nowadays, it isn't profitable to mine cryptocurrency on a standard PC with a single graphics card because the electricity costs are too high. The only exception would be children whose parents pay the electricity bill. A PC needs to be properly prepared for mining, otherwise, it could overheat and break down.
A profitable coin lasts a week or slightly longer, and there is no Windows miner for it. You will always be lagging behind.

You make a fair point about electricity costs and Windows often being behind Linux for very new mining releases.

I am not really designing this around the idea that someone should run a normal desktop GPU at 100% all day regardless of power cost or temperature. One of the features being built is a per-PC policy system so an everyday computer can, for example, mine only when idle, stop when the user returns, run at reduced GPU intensity and obey temperature limits.

The profitability side is also only one part of it.

There will be several different modes. One allows the user to select a pool and payout coin, while the controller decides which supported underlying coin each CPU/GPU should mine for the best practical return. Another allows the user to deliberately accumulate a particular coin even if it is not currently the most profitable.

The point about new coins only being profitable for a short time is actually one of the reasons I am adding a separate New Coin Radar.

The deeper scanner is useful for normal research, but the Radar is intended to look for coins that may only be a few hours old by checking several sources rather than waiting for them to appear on established profitability sites. A newly found coin still has to be checked for things such as mainnet status, algorithm, miner availability, pool availability and wallet requirements before it can be considered usable.

The lack of an early Windows miner is definitely a limitation. At the moment the system is Windows-first because that is where my existing machines are, but I am trying not to design the controller/worker protocol in a way that prevents Linux workers later.

The Radar can also keep a coin on a watchlist if, for example, there is already a Linux miner but no Windows miner. If Windows support appears later, the controller can pick that up instead of having forgotten the coin completely.

I agree that for someone paying high electricity rates, ordinary "mine whatever is currently most profitable on one GPU" mining can be difficult to justify. The project is becoming more about intelligent use of a group of machines: early discovery, speculative accumulation, completing pool payouts, different policies for different PCs, benchmarking the actual hardware and only running workloads when the user considers it worthwhile.

So I don't think Windows removes the problem you mention, but I am trying to design around that limitation rather than pretending it doesn't exist.

[mod note: merged consecutive posts]

[FP91G]

You have a good idea, but it comes too late. Nowadays, it isn't profitable to mine cryptocurrency on a standard PC with a single graphics card because the electricity costs are too high. The only exception would be children whose parents pay the electricity bill. A PC needs to be properly prepared for mining, otherwise, it could overheat and break down.
A profitable coin lasts a week or slightly longer, and there is no Windows miner for it. You will always be lagging behind.

You make a fair point about electricity costs and Windows often being behind Linux for very new mining releases.

I am not really designing this around the idea that someone should run a normal desktop GPU at 100% all day regardless of power cost or temperature. One of the features being built is a per-PC policy system so an everyday computer can, for example, mine only when idle, stop when the user returns, run at reduced GPU intensity and obey temperature limits.

The profitability side is also only one part of it.

There will be several different modes. One allows the user to select a pool and payout coin, while the controller decides which supported underlying coin each CPU/GPU should mine for the best practical return. Another allows the user to deliberately accumulate a particular coin even if it is not currently the most profitable.

The point about new coins only being profitable for a short time is actually one of the reasons I am adding a separate New Coin Radar.

The deeper scanner is useful for normal research, but the Radar is intended to look for coins that may only be a few hours old by checking several sources rather than waiting for them to appear on established profitability sites. A newly found coin still has to be checked for things such as mainnet status, algorithm, miner availability, pool availability and wallet requirements before it can be considered usable.

The lack of an early Windows miner is definitely a limitation. At the moment the system is Windows-first because that is where my existing machines are, but I am trying not to design the controller/worker protocol in a way that prevents Linux workers later.

The Radar can also keep a coin on a watchlist if, for example, there is already a Linux miner but no Windows miner. If Windows support appears later, the controller can pick that up instead of having forgotten the coin completely.

I agree that for someone paying high electricity rates, ordinary "mine whatever is currently most profitable on one GPU" mining can be difficult to justify. The project is becoming more about intelligent use of a group of machines: early discovery, speculative accumulation, completing pool payouts, different policies for different PCs, benchmarking the actual hardware and only running workloads when the user considers it worthwhile.

So I don't think Windows removes the problem you mention, but I am trying to design around that limitation rather than pretending it doesn't exist.

I’ve come across mining software that selects the most profitable algorithm and the concept itself isn't new. There are "cold" and "hot" algorithms, and constantly switching between them on a mining rig with 5–12 GPUs can sometimes lead to crashes.
It works well with a single GPU, but not so well with multiple cards. It comes down to a trade-off between profitability and stability, where a miner will generally prioritize stability.

[BlackMica]

You have a good idea, but it comes too late. Nowadays, it isn't profitable to mine cryptocurrency on a standard PC with a single graphics card because the electricity costs are too high. The only exception would be children whose parents pay the electricity bill. A PC needs to be properly prepared for mining, otherwise, it could overheat and break down.
A profitable coin lasts a week or slightly longer, and there is no Windows miner for it. You will always be lagging behind.

You make a fair point about electricity costs and Windows often being behind Linux for very new mining releases.

I am not really designing this around the idea that someone should run a normal desktop GPU at 100% all day regardless of power cost or temperature. One of the features being built is a per-PC policy system so an everyday computer can, for example, mine only when idle, stop when the user returns, run at reduced GPU intensity and obey temperature limits.

The profitability side is also only one part of it.

There will be several different modes. One allows the user to select a pool and payout coin, while the controller decides which supported underlying coin each CPU/GPU should mine for the best practical return. Another allows the user to deliberately accumulate a particular coin even if it is not currently the most profitable.

The point about new coins only being profitable for a short time is actually one of the reasons I am adding a separate New Coin Radar.

The deeper scanner is useful for normal research, but the Radar is intended to look for coins that may only be a few hours old by checking several sources rather than waiting for them to appear on established profitability sites. A newly found coin still has to be checked for things such as mainnet status, algorithm, miner availability, pool availability and wallet requirements before it can be considered usable.

The lack of an early Windows miner is definitely a limitation. At the moment the system is Windows-first because that is where my existing machines are, but I am trying not to design the controller/worker protocol in a way that prevents Linux workers later.

The Radar can also keep a coin on a watchlist if, for example, there is already a Linux miner but no Windows miner. If Windows support appears later, the controller can pick that up instead of having forgotten the coin completely.

I agree that for someone paying high electricity rates, ordinary "mine whatever is currently most profitable on one GPU" mining can be difficult to justify. The project is becoming more about intelligent use of a group of machines: early discovery, speculative accumulation, completing pool payouts, different policies for different PCs, benchmarking the actual hardware and only running workloads when the user considers it worthwhile.

So I don't think Windows removes the problem you mention, but I am trying to design around that limitation rather than pretending it doesn't exist.

I’ve come across mining software that selects the most profitable algorithm and the concept itself isn't new. There are "cold" and "hot" algorithms, and constantly switching between them on a mining rig with 5–12 GPUs can sometimes lead to crashes.
It works well with a single GPU, but not so well with multiple cards. It comes down to a trade-off between profitability and stability, where a miner will generally prioritize stability.

That is a very good point, and I agree that stability has to come before constantly chasing the highest theoretical return.

I am not planning for the controller to simply switch algorithms every time another one becomes a fraction more profitable.

The idea is to make switching **stability-aware**, especially on machines with multiple GPUs.

Each worker will have its own hardware profile and benchmark history, so the controller can learn not only which algorithm is profitable, but also which combinations are actually stable on that particular machine.

I am also planning to use things such as:

- minimum profitability improvement before a switch is considered;
- cooldown periods between switches;
- hysteresis so it does not bounce backwards and forwards between two algorithms;
- per-worker and per-GPU stability history;
- temperature limits;
- failed-start and crash detection;
- post-switch verification;
- automatic rollback to the last known-good configuration if the new setup is unstable.

The point you make about "hot" and "cold" algorithms is particularly relevant.

A switch that looks better on a profitability table may not really be better if it causes a multi-GPU system to become unstable, requires repeated restarts, increases rejected shares, or forces a recovery.

So I am thinking the controller should eventually score something closer to:

**practical expected return = profitability - instability/switching cost**

rather than simply:

**highest estimated revenue right now**.

It may also make sense for a multi-GPU worker to have a more conservative switching policy than a single-GPU PC.

For example, a single GPU might be allowed to change relatively easily, while a 6- or 8-GPU machine could require a much larger expected gain before changing an already stable configuration.

The controller could also remember combinations that caused problems on a particular worker and either avoid them or require manual approval before trying them again.

That is one reason I am keeping worker-specific profiles instead of treating all GPUs of the same model as interchangeable.

I think your point is important because "most profitable" and "best mining choice" are not necessarily the same thing once stability, downtime, temperatures and switching failures are taken into account.

[FP91G]

You face a very challenging task, as no one has yet managed to create a perfect system. Among my fellow miners, the preference is for Hive OS and manual control, while this approach isn't the most time-efficient, it is highly reliable.
Since switching to Linux-based systems, I no longer have to deal with Windows update failures or issues where 12 graphics cards aren't detected correctly. The Windows GUI consumes up to 400 MB of memory from the primary graphics card.

[BlackMica]

You face a very challenging task, as no one has yet managed to create a perfect system. Among my fellow miners, the preference is for Hive OS and manual control, while this approach isn't the most time-efficient, it is highly reliable.
Since switching to Linux-based systems, I no longer have to deal with Windows update failures or issues where 12 graphics cards aren't detected correctly. The Windows GUI consumes up to 400 MB of memory from the primary graphics card.

I think that is a fair criticism, particularly for large dedicated mining rigs.

If I were building this specifically for 8–12 GPU dedicated rigs, I can understand why Hive OS/Linux would be the obvious starting point. Avoiding Windows update problems, reducing unnecessary overhead and having better behaviour with large numbers of GPUs are all good reasons miners prefer it.

My project is aimed a little differently, though.

A large part of what I am trying to manage is a mixture of ordinary Windows PCs and mining machines across a local network rather than just large dedicated GPU rigs.

Some machines may have one GPU, some may be CPU-only, some may be normal everyday PCs that are only allowed to mine while idle, and others may eventually be allowed to run continuously.

That is why Windows is the first target.

I am also deliberately not trying to remove manual control.

There will be several levels of control, including:

- monitoring only;
- recommendation mode;
- approval before switching;
- limited automation;
- full automation if the user eventually trusts it.

So someone who prefers manual control could still let the system do the research, benchmarking and calculations while retaining final approval over every mining change.

I also want the controller to show exactly what it is proposing before a switch:

worker/PC, GPU or CPU, coin, algorithm, miner executable, miner version/hash, pool, wallet, thread count or GPU configuration, and the reason it believes the change is worthwhile.

The controller is also being designed to favour stability over constant switching.

A theoretically more profitable algorithm should not automatically replace a configuration that has already proved stable if the expected gain is small.

The system will eventually take into account things such as:

- previous crashes;
- failed miner starts;
- rejected shares;
- temperatures;
- switching frequency;
- restart cost;
- worker-specific stability;
- real benchmark history.

So a known stable configuration may deliberately remain running even when another option is slightly more profitable.

There are also some things I am trying to do that are outside the normal profit-switching model.

One is the New Coin Radar, which is intended to find coins that may only be a few hours old rather than waiting for them to appear on established profitability sites.

Another is allowing the user to select a pool and payout coin while letting the controller decide which underlying coin each CPU/GPU should mine for the best practical return.

There is also a payout-completion mode where several workers can be directed toward completing an existing pool payout rather than simply chasing the highest instantaneous profitability.

I do agree that Windows should not become a permanent architectural limitation.

I am keeping the controller/worker design separate enough that a Linux worker could potentially be added later.

That would actually be quite attractive in the future: Windows PCs where Windows is useful, and Linux workers for dedicated rigs where Linux/Hive-style operation is more reliable.

So I don't expect to create a “perfect” mining system either.

The goal is more modest: make the controller intelligent enough to know when it should optimise, when it should leave a stable configuration alone, and when the user should remain in control.

Your point about large multi-GPU rigs is useful because it reinforces that a future Linux worker would probably make more sense than trying to force every type of mining machine into Windows.