Solo Mining rewards a miner for blocks found by their own computing power and accepted into the chain. A block is a group of transactions added to the blockchain, Bitcoin’s public history. “Finding a block” means finding a computation result that lets a miner propose that group to the rest of the network, which still checks that it follows all the rules. Other miners’ discoveries provide no regular income. The miner may run their own infrastructure or use an external solo server that charges a fee. “Solo” primarily describes how rewards are allocated.
Jan buys an ASIC, a machine designed for the computations used in mining. Its dashboard shows activity, yet nothing arrives in his wallet. With Solo Mining, that alone does not mean something is wrong. Computing power gives him a chance to find a block, not an hourly wage. A conventional Mining Pool divides rewards among participants under its chosen rules; mining solo, Jan waits for his own find. Using a server through Stratum, a communication protocol for miners, does not automatically make him part of a shared payout scheme. [1] [6]
For a simple example, assume a constant 1% of the network’s computing power. This is a large illustrative share, not an assumption for a home miner. Across the next 100 network blocks, the expected number of personal finds is one. Yet the chance of finding at least one is only 1 − 0.99^100, about 63.4%. The formula first works out the probability that other miners find all of those blocks, then subtracts it from certainty. What remains is the chance that Jan finds at least one. There may be several, or none. A long wait does not improve the next attempt: mining has no memory of previous failures. Changes in difficulty, relative computing power or uptime also change the model’s assumptions. [1]
Jan pays for electricity regardless of the outcome, as well as equipment, cooling and maintenance. Expected average income is therefore not money he can count on for monthly bills. Sharing revenue in a pool reduces its variability; it does not give the same machine more Hashrate, the number of computations per second. Pool fees and payout rules also differ. For a home experiment, Jan can set a cost limit he can afford even without a single find. Somebody else’s success story is not an estimate of his own earnings. [1]
Solo CKPool is an example of a service supplying mining work, network connectivity and statistics. It does not distribute the reward from Jan’s block to other participants as a conventional pool would, although it may deduct its service fee. Jan needs to understand the payout address, terms and outage procedures. Conversely, a Full Node, a node checking Bitcoin’s rules, cannot replace an ASIC’s computing power. Choosing infrastructure and choosing how rewards are divided are separate decisions. A service’s list of winning blocks shows winners, not every connected machine’s odds. [6]
The machine repeatedly calculates a hash, a numerical fingerprint of the proposed block header. The header is a short set of data about a block, linking the proposal to the previous block and to the transactions it contains. Bitcoin Core checks that it is less than or equal to the network target, encoded in the nBits field. A server can also accept results meeting an easier target: these are called shares. In a solo service, a share helps monitor the machine’s work; it is not itself a discovered block or entitlement to a small payment. Lower share difficulty produces more reports, not a better chance for each computation against the network target. Even the best share so far does not prove a valid block was found. [2] [6]
Before the search, software prepares a proposed block, called a template. BIP 22 describes getblocktemplate, an interface supplying, among other things, previousblockhash, the reference to the preceding block, transactions and coinbasevalue, the maximum amount available for the reward. Software assembles the coinbase, the special first transaction paying the reward, and the header; the ASIC then tries different computations. When the network advances, it needs fresh work. Fast hardware with an incorrect reward recipient or an outdated template is not a properly configured mining setup. [3]
A sufficiently low hash is not enough. Other nodes also verify transactions, the coinbase and the block’s place in the chain. Two miners may find competing blocks, and the network may continue along the other branch. A block outside the active chain is called stale; its reward cannot be spent in that chain. Prompt delivery and up-to-date work therefore matter. Jan checks acceptance of the whole block and subsequent confirmations, not merely a green “share accepted” message on the server dashboard. [3] [4]
The reward can include newly created bitcoin, called the block subsidy, and fees from transactions in the block. A block’s height identifies its position in the chain. On mainnet, from height 840000 until the block before 1050000, the subsidy is 3.125 BTC. Fees vary, and a service may deduct its share. The coinbase must not pay more than the subsidy and these fees combined. COINBASE_MATURITY also applies: the reward can only be spent in a block whose height is at least 100 greater than that of the block that created it. These are blocks, not 100 minutes. Finding a block, having a confirmed reward and having immediately spendable money are different things. [4] [5] [7]
For the clearest picture, read this entry together with Mining, Mining Pool, getblocktemplate, Hashrate, Pay Per Share, Pay Per Last N Shares. The reverse links also lead from Mining Pool, Pay Per Share.