Solo Mining rémunère un mineur selon ses propres blocs trouvés et acceptés, au lieu de partager les découvertes d’un pool plus large. Il peut utiliser son infrastructure ou un serveur solo ; les éventuels frais du service sont déduits de la récompense.
Le mineur ne partage pas les découvertes comme dans un système ordinaire de versements en pool. Il lui faut néanmoins du travail valide, une connexion réseau et livrer le bloc. Utiliser un serveur Stratum ou le modèle d’un tiers n’implique pas des récompenses partagées ; posséder un nœud ne fournit pas la puissance d’un ASIC. [Rosenfeld — Solo mining variance] [Solo CKPool — Service and shares]
Bitcoin Core compare la valeur numérique du hash d’en-tête au target dérivé de nBits. Le hash doit être inférieur ou égal à la cible valide. Un share target plus facile mesure le travail, sans créer un bloc partiel donnant droit à récompense. Réduire la difficulté des shares n’améliore pas la chance d’un hash réseau. [Bitcoin Core — Proof-of-work verification]
BIP 22 getblocktemplate fournit previousblockhash, transactions, hauteur et coinbasevalue pour construire le bloc. Le logiciel assemble la coinbase et l’en-tête, l’ASIC essaie des variantes. Quand le sommet de chaîne change, il faut actualiser le travail ; vérifier modèles et sorties cibles est distinct de la vitesse de hachage. [BIP 22 — Block templates]
Avec une part constante de 1 % et des découvertes indépendantes, l’espérance est une découverte pour 100 blocs réseau. Mais la chance d’au moins une découverte dans ces cent est 1 − 0,99^100, environ 63,4 %, pas une certitude. Une longue série sans découverte n’améliore pas l’essai suivant. Difficulté, hashrate et interruptions modifient les hypothèses du modèle. [Rosenfeld — Solo mining variance]
La coinbase peut réclamer au maximum la subvention et les frais des transactions du bloc. Sur mainnet, de la hauteur 840000 jusqu’avant 1050000, la subvention est de 3,125 BTC ; les frais ne sont pas fixes. COINBASE_MATURITY vaut 100 blocs, pas 100 minutes. Une récompense trouvée n’est donc pas immédiatement dépensable. [Bitcoin Core — Block subsidy and validation] [Bitcoin Core — Coinbase maturity] [Bitcoin Core — Mainnet parameters]
Le bloc entier doit respecter les règles de transactions, coinbase et contexte de chaîne. Une livraison tardive ou du travail sur un ancien sommet peut donner un bloc stale hors de la chaîne active. Surveillez la fraîcheur du travail, l’acceptation par le nœud et les confirmations suivantes ; un meilleur share ne prouve pas une découverte de bloc valide. [BIP 22 — Block templates] [Bitcoin Core — Block subsidy and validation]
Solo CKPool illustre coordination, modèles et statistiques avec attribution individuelle des découvertes. Ses shares servent de retour d’information, pas de versements proportionnels ordinaires. Évaluez frais, adresse de versement, disponibilité et règles de travail ; une liste publique de gagnants ne décrit pas la probabilité de chaque participant. [Solo CKPool — Service and shares]
Électricité, matériel et exploitation se paient en continu, tandis que le revenu solo peut rester longtemps nul. Un pool réduit la variance en répartissant autrement revenu et risque, pas en augmentant magiquement la puissance de la même machine. Les modèles personnels peuvent servir à apprendre ; le financement ne doit pas reposer sur l’idée qu’une victoire devient obligatoire après une longue attente. [Rosenfeld — Solo mining variance]
Pour une vision complète, lisez aussi Minage, Mining Pool, getblocktemplate, Hashrate, Pay Per Share, Pay Per Last N Shares. Cette entrée est également citée par Mining Pool.