
Solo mining software connects your ASIC, GPU, or CPU to a solo Stratum service or your own mining gateway. If your worker finds a valid block, you receive the reward after any service fee. If it does not, submitted shares earn nothing. This guide compares suitable tools, setup requirements, fees, and the odds behind the wait.
Solo mining software sends proof-of-work from mining hardware to a hosted solo endpoint or a gateway connected to your node. It does not improve the probability of success for each hash. It changes who supplies the work and who receives the reward after a valid block.
A conventional pool combines work from many miners. It pays participants under rules such as PPS, FPPS, or PPLNS. Solo mining produces no partial payout for ordinary shares. A hosted solo service supplies Stratum infrastructure without dividing a winning block among its users.
The client and service play different roles. A miner such as CGMiner or BzMiner runs on or beside the hardware. A Stratum service creates jobs, receives shares, and submits a valid block. Management software can configure workers, but it does not perform the hashing itself.
See how a solo mining pool works for a closer look at the service side.
Solo mining concentrates the possible payout into one event. A successful worker receives the block subsidy and transaction fees after any service charge. Every unsuccessful share earns nothing.
A conventional pool converts submitted work into smaller credits. That reduces payout variance without changing the underlying value of the hashrate before fees. Solo mining keeps the variance with the individual miner.
Solo mode may suit a controlled test, a large operation, or a miner who accepts lottery-like risk. It does not suit an operator who needs regular revenue to pay each power bill. Higher network difficulty also increases the expected wait when hashrate stays fixed.
Solo mining pays for a valid block, not for time spent hashing.
Transaction fees vary between blocks. Operating costs also change with power price, downtime, cooling, and equipment efficiency. A long-run expected value is not a payment schedule.
The right tool depends first on the hardware. Bitcoin ASICs, GPU rigs, and management computers need different software.
| Tool or layer | Platform and hardware | Main role | Solo path | Published cost or fee |
|---|---|---|---|---|
| CGMiner | ASIC and FPGA client; source build | Sends work to supported Bitcoin hardware | Connects to a Stratum solo endpoint | GPLv3 |
| BzMiner | Windows, Linux, and macOS release archives; device support varies by algorithm | Mines supported GPU or CPU algorithms | Connects to a compatible solo pool or node-backed endpoint | Developer fee varies by algorithm |
| ASIC web interface | Runs in the miner’s firmware | Stores the pool URL, username, and password | Points the ASIC at a hosted solo endpoint | Vendor terms apply |
| Solo CKPool | Hosted Bitcoin Stratum service | Supplies jobs and submits valid blocks | Miner connects directly to the published endpoint | 2% service fee |
CGMiner remains useful for compatible ASIC and FPGA hardware, but its upstream repository is archived and read-only. Check whether the device vendor maintains a supported fork before deploying it.
BzMiner targets several GPU and CPU algorithms. Its current release page identifies supported devices and the developer fee for each algorithm. Those details can change between releases, so use the table shipped with the version you plan to run.
Most Bitcoin ASICs already expose the required connection fields in their firmware. In that case, a separate desktop miner adds no benefit. Enter the solo endpoint in the ASIC interface and confirm that the service receives shares.
Solo CKPool belongs in the service category. It supplies Bitcoin work over Stratum and charges a fee when a worker finds a block.
The coin’s proof-of-work algorithm determines the hardware. For Bitcoin, a SHA-256 ASIC is the relevant hardware class. A GPU cannot replace an ASIC merely because both clients accept a Stratum URL.
ASIC firmware usually provides fields for a URL, username, and password. A hosted Bitcoin solo service may use the payout address as the username. Follow that service’s documented format instead of copying settings from an unrelated pool.
GPU and CPU miners need a supported operating system, driver, and algorithm. Requirements can change between releases. Check the release notes and run the miner’s device-information command before adding a wallet address.
A self-hosted setup needs more than Bitcoin Core. Mining hardware cannot connect directly to a Bitcoin Core node over Stratum. You also need a gateway that builds jobs for the miner and submits completed work to the node.
The altcoin mining setup guide explains how hardware, algorithms, wallets, and pool endpoints fit together.
A working setup needs a payout address, a compatible endpoint, correct credentials, and at least one accepted share. Copy connection details from the operator’s official page.
stratum+tcp://stratum.ckpool.org:3333. The username is a Bitcoin address, with an optional worker suffix, and the password can be x.An accepted pool share shows that the connection works. Only a network-difficulty share produces a solo block reward.
Configure a fallback only after verifying that it uses the same coin and algorithm.
Solo CKPool publishes a 2% service fee. Ordinary submitted shares do not create a payable balance. The fee matters only after the service receives a valid block from the worker.
The service starts workers at share difficulty 10,000. A low-hashrate worker may therefore take time to appear in its statistics. Setting a lower client difficulty can make feedback more frequent when the service supports it, but it cannot improve block odds.
PPS and FPPS pools issue frequent share-based credits. PPLNS payouts depend on the pool’s blocks and share window. Solo accounting has only two outcomes: the worker finds a valid block, or it receives no mining payout.
Tax treatment depends on the miner’s location and circumstances. Keep the block height, receipt time, market value, service fee, electricity cost, and equipment records. Use current guidance from the relevant tax authority before filing.
Approximate Bitcoin time to block can be calculated as:
difficulty × 2^32 ÷ hashrate
The result is an expected interval, not a deadline. Divide by uptime when the miner does not run continuously.
Using the documented difficulty snapshot of 132,757,073,449,487.52:
| Stable hashrate | Expected time to one block |
|---|---|
| 100 TH/s | about 181 years |
| 500 TH/s | about 36.1 years |
| 1 PH/s | about 18.1 years |
| 10 PH/s | about 1.81 years |
At one expected interval, the probability of finding at least one block is 1 − e^-1, or about 63.2%. A miner can win immediately or run through several expected intervals without finding a block.
Difficulty changes over time, so the table will age. Recalculate with the difficulty at the time of the decision.
Electricity cost can be estimated as kilowatts × operating hours × power price. Compare that cost with the probability-weighted reward, not with the full value of one possible block.
Expected time describes an average across repeated trials. It does not predict the date of the next block.
Download mining software from the developer’s official release page. If the developer publishes a checksum or signature, verify it before execution.
BzMiner lists a SHA-256 value beside each release archive. Hash the downloaded file locally and compare every character. A matching checksum shows that the file matches the published archive, but only if you obtained the expected checksum from the official page.
CGMiner publishes its source under GPLv3. Its upstream repository is archived, so inspect the origin and maintenance history of any newer binary or fork that uses the name.
Test a new release on one isolated worker first. Keep the version, archive name, checksum, download URL, and test result in the rig log.
Signs that require investigation include:
Verify the exact archive you run, not only the page that linked to it.
A hashrate marketplace can direct rented capacity to a compatible solo endpoint. The order still needs the correct algorithm, host, port, username, and password.
Renting changes where the hashrate comes from. It does not alter network difficulty or the probability attached to each hash. Compare the full rental invoice with the probability-weighted reward before placing an order.
Some solo services publish a separate high-difficulty port for rentals. Use the operator’s documented rental endpoint when required. Confirm accepted shares before extending the order.
A short rental can test a Stratum configuration, payout address, dashboard, or monitoring pipeline. Stop the test if the delivered hashrate, rejection rate, or endpoint differs from the order.
Before committing rented or owned hashrate, compare the current Bitcoin pool options and set a maximum loss for the experiment.
Solo mining pays only when your worker finds a valid network block. Pool mining combines hashrate and distributes smaller payments under rules such as PPS, FPPS, or PPLNS. A hosted solo service supplies infrastructure but leaves the block outcome with one worker.
Solo CKPool publishes a 2% service fee. Ordinary submitted shares do not earn payouts. Check the operator’s page before connecting because fees and endpoints can change.
The hardware must match the coin’s algorithm. Bitcoin mining calls for SHA-256 ASIC hardware. GPUs and CPUs can solo-mine only on compatible algorithms, and the odds still depend on their hashrate relative to the target network.
Yes. A rental service can send compatible hashrate to a solo endpoint. Renting changes the source and cost of the hashrate, not the probability of success for each hash.