225 / 736TARGET

Mining Target

Le nombre que le résultat du mineur ne doit pas dépasser

Jana sait que les mineurs répètent des calculs, mais elle se demande encore ce qu’ils attendent. Chaque tentative produit un hash, un résultat que l’on peut comprendre comme un très grand nombre. N’importe quel résultat ne suffit pas : il doit rester sous une limite définie, l’égalité étant aussi admise. Cette limite s’appelle Mining Target. Plus elle est basse, plus la réussite est rare. Les autres participants peuvent ensuite vérifier facilement que le résultat respecte bien la condition.

Mining Target désigne le nombre auquel on compare le hash de l’en-tête du bloc, son résumé compact de données. Pour une preuve de travail valide, le hash ne doit pas dépasser la bonne cible. Sur le réseau Bitcoin, cette cible doit être positive et respecter les règles applicables au bloc concerné ; le mineur ne la choisit pas librement.

Imaginons, uniquement pour l’exemple, une limite de 20 : les résultats 19 et 20 conviendraient, mais pas 21. Les nombres réels du minage sont beaucoup plus grands, mais la relation reste la même : hash ≤ target. Le signe signifie inférieur ou égal, pas strictement inférieur. Bitcoin Core est un logiciel qui permet aux participants du réseau de vérifier les blocs et les transactions. La version v29.0 citée ici compare ainsi le hash de tout l’en-tête. Le nonce, une valeur que le mineur fait varier pendant la recherche, est une donnée d’entrée. C’est le hash obtenu que l’on compare à la cible. [1]

Jana voit l’image d’un hash réussi commençant par beaucoup de zéros. C’est une illustration utile : à longueur de représentation égale, davantage de zéros initiaux signifie un nombre plus petit. Pourtant, deux hashes ayant autant de zéros au début peuvent être de part et d’autre de la cible. Les chiffres suivants comptent aussi. Les zéros ne remplacent donc pas la comparaison complète hash ≤ target. La règle impose une condition numérique précise, pas un joli motif de caractères. [1]

Un bit peut prendre la valeur zéro ou la valeur un ; huit bits forment un octet. Pour éviter de stocker tout le grand nombre dans l’en-tête, Bitcoin utilise le champ nBits de 32 bits. Il encode une cible dans l’espace des nombres de 256 bits, avec un coefficient, un exposant déterminant le décalage et un bit de signe. Par exemple, 0x04123456 se décode en 0x12345600 ; le préfixe 0x indique la notation hexadécimale, qui utilise aussi des lettres. Il s’agit d’un exemple d’encodage, pas de la cible actuelle du réseau. Pour comprendre l’essentiel, distinguez le nombre de son écriture abrégée. [3] [5]

Dans les données brutes, un même nombre peut sembler inversé. Dans l’en-tête de 80 octets, nBits occupe quatre octets stockés en little-endian : l’octet de poids le plus faible vient en premier. Le nombre 0x1d00ffff apparaît donc sous la forme ff ff 00 1d. L’ordre des octets ne modifie pas la cible ; il décrit son stockage. Ce détail concerne le traitement des données brutes. Un lecteur ordinaire d’un explorateur de blocs n’a pas à inverser les nombres affichés. [2]

Jana pourrait proposer d’inscrire un nombre plus grand pour faciliter la recherche. Mais le logiciel ne vérifie pas seulement qu’il sait lire nBits. DeriveTarget dans Bitcoin Core v29.0 rejette une cible négative, zéro, un dépassement de la plage numérique et une valeur supérieure à powLimit, la plus haute cible autorisée pour ce réseau. Un décodage réussi précise donc seulement le nombre représenté ; il n’autorise pas à l’utiliser. [1]

Même une cible située dans la plage autorisée peut être incorrecte pour un bloc donné. Bitcoin Core compare nBits à GetNextWorkRequired, un calcul fondé sur le bloc précédent et les règles du réseau. Une différence entraîne bad-diffbits. Un hash inférieur à une cible personnelle plus facile n’excuse pas une mauvaise valeur dans l’en-tête. Jana ne peut obtenir un bloc accepté en réduisant simplement les exigences : les autres nœuds, les ordinateurs qui vérifient les règles, rejetteront cette tentative. [4]

Dans un modèle de hashes de 256 bits uniformément distribués, chaque résultat possible a la même probabilité. Pour une cible autorisée T, les valeurs acceptées vont de zéro à T inclus. D’où p = (T + 1) / 2^256 par tentative, où p représente la probabilité de réussite. Le un ajouté compte le zéro. Cette relation explique pourquoi une cible plus basse rend la recherche plus difficile. Elle n’indique ni le nombre de tentatives par seconde d’une machine ni l’instant exact du prochain bloc. [1]

Lorsque Jana remplit la condition, elle prouve le travail de calcul requis, pas la validité de tout le contenu du bloc. Bitcoin Core vérifie aussi l’empreinte commune des transactions, la transaction spéciale de récompense appelée coinbase, les limites du bloc et la validité des transactions. Ici, coinbase désigne la première transaction du bloc, pas la plateforme d’échange. Un hash bas ne répare pas un contenu invalide. La cible est une partie importante des règles, pas une autorisation de contourner les autres. [4]

Pour une vision complète, lisez aussi Share Difficulty, Proof of Work, Nonce, Block Header, Bitcoin. Cette entrée est également citée par ASIC Miner, Nonce, Mining Share, Share Difficulty.

DOC · 001Bitcoin Core v29.0 — Proof-of-work checksSource primaire DOC · 002Bitcoin Developer Reference — Block headers and nBitsDocumentation DOC · 003Bitcoin Core v29.0 — Compact arithmeticSource primaire DOC · 004Bitcoin Core v29.0 — Contextual and block validationSource primaire DOC · 005NIST — Binary data unitsDocumentation
Révisé le: Sources d’abord · Pas un conseil financier