Une Mining Share est un résultat de calcul qui satisfait l’exigence du pool pour une tâche précise. Le pool estime le travail fourni à partir de ces échantillons vérifiables. L’exigence est généralement moins stricte que celle d’un bloc Bitcoin valide : la plupart des shares ne sont donc pas de nouveaux blocs.
La machine de Petr effectue énormément de tentatives. Le pool n’a pas besoin d’un message pour chacune : il reçoit des résultats sélectionnés qui respectent une condition fixée à l’avance. Il les vérifie et estime statistiquement le travail à partir de leur fréquence et de leur difficulté. Une Mining Share n’est donc ni un fragment de bloc inachevé ni une part transférable de bitcoin. Ce n’est pas non plus une transaction inscrite dans la blockchain, l’historique public des transactions Bitcoin organisé en blocs reliés entre eux. Elle permet au mineur de justifier son apport de calcul au pool. [1]
Le minage cherche un hash, un résultat de calcul interprété comme un nombre, qui ne dépasse pas une cible fixée. Le pool choisit généralement une cible numériquement plus élevée que celle du réseau : davantage de résultats passent, la condition est donc plus facile. Ce qui suffit au pool ne suffit généralement pas pour un bloc. Par hasard, certains résultats satisfont aussi la cible plus stricte du réseau. Ils peuvent mener à un nouveau bloc si celui-ci respecte également toutes les autres règles. Le pool n’assouplit pas les règles de Bitcoin ; il fixe son propre seuil pour les preuves régulières de travail. [1]
Petr n’assemble pas ces messages à la main : le logiciel de minage s’en charge. Stratum V2 est un protocole, un ensemble de règles de communication entre équipements et pool. Son message SubmitSharesStandard contient job_id pour identifier la tâche, nonce pour la valeur modifiée pendant la recherche, ntime pour l’horodatage de l’en-tête du bloc et version pour la version de l’en-tête, la partie compacte de données du bloc. Il identifie aussi le canal de communication. Le pool a besoin de ce contexte pour vérifier le calcul : un nonce sans la bonne tâche n’est pas une preuve autonome de travail. [2]
Imaginons Petr comparant des machines dont les tâches ont des difficultés différentes. La difficulté sert ici de pondération : un résultat satisfaisant une condition plus stricte compte pour davantage de travail. En ramenant les résultats à la même échelle, deux envois acceptés de difficulté 1024 ont le même poids total qu’un seul de difficulté 2048. Le nombre de messages diffère, le poids comptabilisé du travail est identique. Même cette somme ne recense pas exactement tous les calculs réalisés : les succès individuels sont aléatoires. Il faut donc savoir si un compteur appelé shares indique les résultats acceptés ou leur poids ramené à une échelle commune. [3]
Le pool peut confirmer plusieurs envois à la fois. Stratum V2 utilise pour cela la réponse SubmitShares.Success. Le champ new_submits_accepted_count compte les envois nouvellement confirmés, tandis que new_shares_sum additionne les difficultés des tâches correspondantes. Le premier compte les résultats, le second leur poids. Tous deux concernent le lot en cours de confirmation, pas automatiquement les totaux depuis le début de l’activité du mineur. Il ne faut donc pas attendre une confirmation distincte pour chaque résultat envoyé. [2]
La machine de Petr peut signaler un résultat envoyé alors que le pool le vérifie encore. Stratum V2 utilise SubmitShares.Error pour un envoi incorrect ; sequence_number indique l’envoi concerné. Si la vérification ne peut pas être immédiate, l’erreur peut arriver plus tard. Il faut distinguer les résultats envoyés des résultats confirmés comme acceptés, et surveiller les refus. La hausse du compteur local d’envois ne prouve pas que tout a été comptabilisé par le pool. [2]
Le travail confirmé entre dans les règles de rémunération du pool. Par exemple, chez Braiins, FPPS, Full Pay Per Share, calcule la rémunération à partir du travail soumis et des données du réseau, dont la difficulté et les récompenses de bloc ; il inclut aussi une composante de frais de transaction. Le pool déduit ses frais et les transferts suivent les paramètres de versement. La confirmation d’une share n’envoie pas en elle-même de BTC (bitcoins) au portefeuille. Petr suit donc séparément travail accepté, rémunération calculée et versement effectif. [4]
Un compteur de shares peut rappeler une barre de téléchargement, mais le minage fonctionne autrement. Shares et blocs proviennent de la recherche de hashes suffisamment bas, avec des résultats aléatoires. Davantage de travail attesté donne une meilleure base statistique pour estimer la puissance, sans garantir un nouveau succès. Une longue série de shares acceptées ne promet aucun bloc à la tentative suivante. Le compteur informe Petr sur le travail et son acceptation, pas sur un dernier morceau de bloc restant à terminer. [3]
Pour une vision complète, lisez aussi Mining Pool, Share Difficulty, Proof of Work, Mining Target, Bitcoin. Cette entrée est également citée par ASIC Miner, Mining Pool, Braiins Pool, Stratum V1.