Solo Mining rewards a miner according to their own discovered and accepted blocks instead of sharing a wider pool’s discoveries. It can use personal infrastructure or a solo-server service; any service fee is deducted from the reward.
The miner does not share discoveries with others under an ordinary pooled payout scheme. They still need valid work, network connectivity and block delivery. Using a Stratum server or someone else’s template does not itself imply shared rewards; conversely, owning a node does not supply an ASIC’s hashing power. [Rosenfeld — Solo mining variance] [Solo CKPool — Service and shares]
Bitcoin Core compares the numerical header hash with the target derived from nBits. The hash must be less than or equal to a valid target. An easier share target measures work operationally, rather than creating a partial reward-bearing block. Lowering share difficulty does not improve a single network hash’s chance. [Bitcoin Core — Proof-of-work verification]
BIP 22 getblocktemplate supplies material for block construction: previousblockhash, transactions, height and coinbasevalue. Mining software assembles the coinbase and header, while the ASIC tries work variants. Work must be updated when the chain tip changes; verifying templates and destination outputs is separate from hashing speed. [BIP 22 — Block templates]
With a constant 1% share and independent discoveries, the expectation is one discovery per 100 network blocks. Yet the chance of at least one discovery within those hundred is 1 − 0.99^100, about 63.4%, not certainty. A long run without a discovery does not improve the next attempt. Difficulty and hashrate changes or downtime alter the model’s assumptions. [Rosenfeld — Solo mining variance]
The coinbase may claim at most the block subsidy plus fees from transactions in the block. For mainnet heights from 840000 up to but excluding 1050000, the subsidy is 3.125 BTC; transaction fees are not fixed. COINBASE_MATURITY is 100 blocks, not 100 minutes. A discovered reward is therefore not immediately spendable balance. [Bitcoin Core — Block subsidy and validation] [Bitcoin Core — Coinbase maturity] [Bitcoin Core — Mainnet parameters]
The entire block must satisfy transaction, coinbase and chain-context rules. Delayed delivery or work on an old tip can produce a stale block outside the active chain. Monitor work freshness, node acceptance and subsequent confirmations; a best share is not evidence of a valid block discovery. [BIP 22 — Block templates] [Bitcoin Core — Block subsidy and validation]
Solo CKPool is an example of coordination, templates and statistics with solo allocation of discoveries. Its shares provide feedback rather than ordinary proportional payouts. Assess fees, payout address, availability and work policies before use; a public winners list does not describe every participant’s probability. [Solo CKPool — Service and shares]
Electricity, hardware and operations require ongoing payment while solo income may remain zero for a long time. A pooled scheme reduces variance by allocating revenue and risk differently, not by magically increasing the same machine’s power. Personal templates can be explored for learning; financing should not rely on a belief that a win must arrive after a long wait. [Rosenfeld — Solo mining variance]
For the clearest picture, read this entry together with Mining, Mining Pool, getblocktemplate, Hashrate, Pay Per Share, Pay Per Last N Shares.