
Solo mining means competing for a block without sharing its reward with regular pool participants. This guide explains the hardware, wallet, solo-pool and full-node paths. It also shows how to estimate your probability of finding a Bitcoin block.
A solo miner keeps the reward from a valid block after any service fee. The trade-off is extreme payout variance. There are no regular partial payments to offset electricity or maintenance costs.
Your ASIC tests block headers against Bitcoin’s network target. If it finds a valid hash, the block’s coinbase transaction pays the configured address. The current subsidy is 3.125 BTC. Applicable transaction fees are added to that reward.
A regular pool combines hashrate from many miners. It distributes income according to submitted work and its payout rules. A solo service also accepts shares, but ordinary shares do not earn partial payments. They only help confirm that the miner is working.
Each solo worker keeps the probability produced by its own hashrate. Other users do not divide that probability or share its reward.
A calculated block interval is an average, not a deadline. A miner can succeed immediately or run far beyond that interval.
Solo mining suits experiments and lottery-style risk. It does not provide predictable operating income.
Bitcoin mining requires SHA-256 hardware. A current ASIC performs far more hashing work than a CPU or GPU. Higher hashrate improves the odds, but it also raises power, cooling, and noise requirements.
| Hardware type | Best use | Main constraint |
|---|---|---|
| Industrial SHA-256 ASIC | Dedicated mining space or managed facility | Electrical load, heat, and noise |
| Compact home ASIC | Monitored home or workshop setup | Lower hashrate and long expected wait |
| Open-source device such as Bitaxe | Learning, firmware testing, and lottery mining | Very low probability per device |
| CPU or GPU | Software experiments | Unsuitable performance for Bitcoin block discovery |
An industrial miner may need a dedicated circuit and controlled exhaust. Confirm the manufacturer’s electrical requirements before installation. Do not size wiring from a reseller’s summary.
A Bitaxe exposes its controls through AxeOS and can connect to a compatible Stratum endpoint. It is useful for learning how jobs, shares, and difficulty interact. It should not be treated as a short-term payout tool.
Compare Bitaxe and larger-ASIC pool options before choosing hardware. More hashrate shortens the statistical wait but never guarantees a block.
Use a Bitcoin address controlled by your own private key. The solo service or local mining stack places that address in the coinbase transaction. Check the address before starting because a completed block cannot be redirected afterward.
Prepare the wallet, power, cooling, and network together. Copy the receiving address from the wallet itself. Verify its first and last characters on the wallet screen.
Check the circuit, plug, voltage, and continuous load against the miner’s official specifications. Provide a clear intake and a path for hot exhaust. Use a stable wired connection for an industrial ASIC when possible.
Save the payout address separately from the miner configuration. Confirm the same address in the solo service’s statistics page. Monitor accepted and rejected shares after every configuration change.
A disconnected service cannot deliver new work. Local hashing speed alone does not prove that the miner receives current jobs.
A hosted solo service handles block templates, Stratum connections, and block broadcasting. This reduces setup work, but the service becomes an operational dependency. It may also deduct a fee from a successful block.
A full-node setup gives the operator more control over template construction and broadcasting. It adds node synchronization, RPC authentication, storage, monitoring, and bridge maintenance.
| Question | Hosted solo service | Own full-node setup |
|---|---|---|
| Bitcoin node required | No | Yes |
| Hosted-service fee | May apply after a found block | None |
| Setup complexity | Lower | Higher |
| Block template | Built by the service | Built by the local stack |
| Main dependency | External Stratum service | Local node and mining bridge |
Choose a hosted service when you do not want to maintain Bitcoin infrastructure. Choose a full-node path when template control justifies the added work.
The ASIC uses the same pool-configuration screen used for ordinary pooled mining. The payout address replaces the usual account name.
<bitcoin-address>.<optional-worker> as the username when the service supports that format.Solo CKPool publishes stratum.ckpool.org:3333. Braiins publishes solo.stratum.braiins.com:3333, with additional ports on its setup page. Both services accept the Bitcoin address as the username.
Accepted shares confirm that the ASIC receives jobs and returns work. They do not create a payable balance. Compare the service’s longer reporting window with the ASIC’s local average.
A backup endpoint can reduce idle time during an outage. Remember that work sent to a regular pool follows that pool’s payout rules.
Bitcoin Core supplies block data through getblocktemplate. Most ASIC appliances speak Stratum instead of Bitcoin Core RPC. A compatible local bridge must translate between them.
bitcoin-cli getblocktemplate '{"rules":["segwit"]}'.Running Bitcoin Core alone does not create a complete ASIC mining service. The bridge must build suitable jobs, handle submissions, and send a valid block back to the node.
Read the full-node solo mining setup guide before changing RPC access or bridge settings.
The table covers two active Bitcoin solo services with public setup instructions. Verify their official pages again before moving hashrate.
| Service | Fee on a found reward | Low-hashrate guidance | Payout destination |
|---|---|---|---|
| Solo CKPool | 2% | Share difficulty starts at 10,000; below 100 GH/s is discouraged | Configured Bitcoin address |
| Braiins Solo | 0.5% | Reporting may fluctuate below 500 GH/s | Configured coinbase output |
CKPool explains that high share difficulty can delay visible statistics for a small miner. This does not change the worker’s chance of finding a network-valid block.
Braiins adjusts share difficulty and uses submitted shares for monitoring. Its documentation also notes that weak-device reporting may be imprecise.
The lower fee matters only after a block has been found. Also compare endpoint latency, public statistics, recent service availability, and worker visibility. Copy connection details only from the operator’s official documentation.
Estimate the average interval with:
T = difficulty × 2³² ÷ miner hashrate
Difficulty is the stable input: it holds until the next retarget, while network hashrate readings swing by ten percent from one day to the next. The figures below use difficulty 132.76 trillion, which corresponds to roughly 950 EH/s of network hashrate. Express the miner hashrate in hashes per second before dividing: 200 TH/s is 2 × 10¹⁴ H/s.
| Example hashrate | Network difficulty | Expected time to one block |
|---|---|---|
| 1 TH/s | 132.76 trillion | About 18,100 years |
| 10 TH/s | 132.76 trillion | About 1,810 years |
| 200 TH/s | 132.76 trillion | About 90.3 years |
| 1 PH/s | 132.76 trillion | About 18.1 years |
The result is a statistical mean. It is not a countdown. At one expected interval, the probability of finding at least one block is about 63.2%.
For any period t, estimate the probability with:
P = 1 − e^(-t/T)
Use the same time unit for t and T. A five-year window and an expected interval of 88.9 years produce a small probability, even though the ASIC runs continuously.
MiningPoolStats reports current network conditions on the Bitcoin pool statistics page. Recalculate after material difficulty or hashrate changes.
Keep the ASIC administration page, mining bridge, and Bitcoin Core RPC off the public internet. Exposing them creates avoidable paths for credential attacks and configuration changes.
Bitcoin peer connections and Bitcoin Core RPC serve different purposes. Opening peer connectivity does not require publishing the RPC interface.
Authentication is not a reason to expose a management or RPC service. Limit access at both the bind address and firewall.
Start at the ASIC, then inspect the solo service or local bridge. Check the node last. This order separates hardware, network, and upstream failures.
| Symptom | Likely cause | What to check |
|---|---|---|
| ASIC never connects | Wrong hostname, port, or DNS result | Compare the settings with the official setup page |
| Shares are rejected | Invalid address, worker format, or protocol mismatch | Read the rejection message and recheck every field |
| Dashboard hashrate disappears | Connection loss or high share difficulty | Use a longer reporting window and inspect reconnect logs |
| Full node returns no template | Synchronization or RPC request problem | Check node status, then test getblocktemplate locally |
| RPC authentication fails | Credential or configuration mismatch | Recheck the bridge settings and node log |
| Local hashrate falls | Heat, power, or hashboard problem | Inspect temperatures, frequency, fans, and hardware errors |
If the ASIC hashes locally but submits no accepted shares, test a verified endpoint. This separates a miner fault from a solo-service or bridge fault.
A small device may take a long time to submit a share at the service’s starting difficulty. Missing short-window statistics do not automatically mean that the device has stopped hashing.
Altcoins can offer different solo-mining odds, but only compatible hardware can participate. A new pool URL cannot make an ASIC run a different proof-of-work algorithm.
Start with the algorithm supported by the device. Then compare the miner’s hashrate with that network’s hashrate. Check its block interval, reward rules, node software, and solo-service fee.
Hashrate units cannot be compared across unrelated algorithms. A figure shown for one algorithm says nothing about performance on another.
A smaller network may shorten the expected interval. It can also bring lower liquidity, faster difficulty changes, or fewer maintained services. Verify each network through its official node and mining documentation.
Altcoin solo mining fits operators who already own compatible equipment. Hardware purchases should not rely on a lower-looking network hashrate alone.
Solo mining offers one clear upside: the successful miner receives the block reward after any service fee. The downside is the loss of regular partial payouts.
The approach can fit protocol enthusiasts, operators with substantial hashrate, and owners running a low-power learning device. It is a poor primary-income plan for someone relying on one ASIC. The expected wait may outlast the hardware.
Record the miner’s hashrate, power use, service fee, and expected block interval. Decide whether the variance fits the purpose of the setup.
Before moving hashrate, check the live Bitcoin network and pool figures.
Yes. A Bitaxe can connect to a compatible Stratum solo service through AxeOS. Its limited hashrate makes it better suited to learning and lottery mining than predictable payouts.
Multiply network difficulty by 2³² and divide by the miner hashrate in hashes per second. At difficulty 132.76 trillion, 200 TH/s gives an expected interval of about 90.3 years. Actual discovery can happen earlier or much later.
Yes. An exposed administration page allows password attacks and unauthorized configuration attempts. Keep it on a private network, replace default credentials, and remove port forwarding. Protect Bitcoin Core RPC and local mining bridges the same way.
It can make sense when you already own compatible hardware and the network offers a shorter expected interval. Check the algorithm, current network conditions, reward rules, liquidity, and electricity cost before switching.
These primary sources support the fees, endpoints, network snapshot, and setup details above.