Bitcoin Forum
September 20, 2026, 09:04:34 PM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Windows Multi-PC Mining Manager + Coin Discovery  (Read 42 times)
BlackMica (OP)
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
September 19, 2026, 06:46:43 AM
 #1

# 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
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
Today at 06:56:52 AM
 #2

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 (OP)
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
Today at 07:51:01 AM
 #3

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!