Share Difficulty

Le minage produit des hashes : des résultats de calcul que l’on peut interpréter comme des nombres. Pour que le pool puisse accepter un résultat, celui-ci ne doit pas dépasser la cible fixée. Une cible plus basse est plus stricte, car moins de résultats passent en dessous. Share Difficulty augmente donc lorsque la cible numérique diminue. Pour les lecteurs intéressés par le protocole, Stratum V2, qui définit les échanges avec le pool, transmet cette limite dans le champ target du message SetTarget. Inutile de connaître le format pour comprendre : une limite numérique plus basse rend la condition plus difficile à remplir. [1]

Imaginons que le pool fasse passer la difficulté de Petra de 1024 à 2048. À puissance de calcul identique et avec une difficulté mesurée sur la même échelle, on attend environ deux fois moins de résultats admissibles sur une même durée. La machine continue ses tentatives aussi vite ; moins de résultats franchissent simplement le filtre plus strict. Les intervalles restent aléatoires. Petra ne doit donc pas attendre chaque share suivant après exactement le double du temps. [2]

Ne compter que les messages reviendrait à comparer des choses différentes. Braiins explique donc sa comptabilité à l’aide d’unités de travail pondérées selon la difficulté. Deux résultats acceptés à la difficulté 1024 ont le même poids total qu’un résultat à la difficulté 2048. Moins de messages ne prouvent pas une contribution moindre. Petra ne doit pas non plus confondre ce poids comptable avec le nombre exact de calculs réellement effectués : il s’agit d’une preuve statistique du travail. La rémunération dépend aussi des règles du pool. [3]

Modifier Share Difficulty n’accélère pas à lui seul l’ASIC, la puce spécialisée de la machine de minage. Cela ne change pas non plus la cible du réseau pour un bloc Bitcoin. À nombre de tentatives indépendantes et difficulté du réseau identiques, la probabilité de trouver un bloc reste la même. Le pool modifie seulement les résultats intermédiaires qu’il souhaite recevoir. Abaisser la difficulté des shares ne facilite donc pas la production de blocs Bitcoin. [3]

Avec un réglage identique, des machines faibles et puissantes enverraient des quantités très différentes de résultats. VarDiff, l’ajustement automatique de la difficulté, compense cet écart et limite le trafic inutile. Braiins permet aussi de fixer un minimum. C’est un plancher, pas une valeur attribuée fixe : le pool peut choisir une difficulté supérieure selon la puissance de calcul. Lorsque Petra compare son réglage à l’affichage actuel, elle doit d’abord déterminer si elle lit le minimum ou la difficulté réellement attribuée. [2]

Le logiciel doit savoir quel travail est concerné par un changement. D’après la spécification actuelle de Stratum V2, SetTarget s’applique aux tâches reçues ensuite et aux tâches futures reçues auparavant dont ntime_start est vide. Ce champ fixe l’horodatage initial dans l’en-tête du bloc, qui résume ses données essentielles. Un champ vide signale une tâche qui attend encore d’être activée. Une tâche déjà reçue dont ntime_start est renseigné conserve sa cible. Pour comprendre un rejet, il ne suffit donc pas de comparer le résultat à la dernière limite : il faut le rattacher à la bonne tâche. Le logiciel de minage s’en charge normalement. [1]

Petra peut aussi rencontrer l’indicateur best share. Braiins Solo l’utilise, par exemple, pour le share de difficulté la plus élevée trouvé pendant une session de minage. La difficulté attribuée décrit la condition suffisante pour soumettre un résultat ; best share décrit la rareté du résultat effectivement trouvé. Un record n’est pas une progression accumulée vers un bloc. Même un résultat exceptionnel n’améliore pas les chances de la tentative indépendante suivante. [4]

Un minimum manuel trop élevé peut rendre les envois si rares que l’estimation de la puissance de calcul fluctue fortement. La surveillance peut alors déclencher une alarme alors que l’ASIC fonctionne toujours. Une courte période sans share ne prouve pas, à elle seule, une panne. Petra compare donc la difficulté attribuée, la période observée, le travail accepté et l’état de la connexion. Ensemble, ces données l’aident à distinguer le hasard ordinaire d’un véritable problème. [2]