Nonce

Anna possède un appareil de minage qui cherche à produire un nouveau bloc de transactions. À partir de l’en-tête, un ensemble compact d’informations sur le bloc, il calcule avec SHA-256 une empreinte numérique appelée hash. Bitcoin applique ce calcul deux fois, d’où double-SHA-256. Si le résultat dépasse la limite autorisée, l’appareil change, par exemple, le Nonce de 10 à 11 et recommence. Anna ne devine pas les nombres à la main : son appareil effectue automatiquement une immense quantité d’essais. Un Nonce plus élevé ne signifie ni un hash plus petit ni un progrès vers le but. Un en-tête exactement identique donne toujours le même hash : le recalculer n’apporte donc aucune chance supplémentaire. [1] [2]

Le Nonce occupe quatre octets, soit 32 bits. Ils représentent les entiers de 0 à 4 294 967 295 inclus : 4 294 967 296 possibilités, ou 2^32. Cela semble énorme, mais un appareil spécialisé dans le minage, appelé ASIC, parcourt très vite cet intervalle. Essayer toutes les valeurs ne garantit pas le succès. Si les autres données de l’en-tête ne changent pas, repartir du début ne fait que reproduire les mêmes résultats. Le logiciel doit donc aussi préparer des en-têtes différents. [1] [5]

Une possibilité consiste à modifier l’Extranonce. Le nom peut prêter à confusion : ce n’est pas un champ supplémentaire de l’en-tête, mais une donnée de la transaction coinbase, la première transaction du bloc, qui attribue la récompense du minage. La modifier change son identifiant, le txid, puis le Merkle Root, l’empreinte commune des transactions inscrite dans l’en-tête. L’appareil dispose alors d’une entrée différente. Il peut réutiliser les mêmes valeurs de Nonce, mais calcule cette fois les hashes d’autres en-têtes. Ces 2^32 nouvelles possibilités ne garantissent toujours pas de trouver un bloc. [2] [3]

Un explorateur peut afficher un petit Nonce pour un bloc et un grand pour un autre. Le nombre seul ne révèle ni la difficulté rencontrée pour trouver le bloc ni sa qualité. Un Full Node, un logiciel qui vérifie lui-même les blocs et les transactions selon les règles de Bitcoin, calcule le hash de l’en-tête entier et le compare au target valide, dont la représentation compacte figure dans nBits. Ce qui compte est un hash inférieur ou égal à cette limite, pas la taille du Nonce. Le nœud doit aussi vérifier les transactions et les autres règles de validité du bloc. [1] [8]

Le mot nonce apparaît aussi dans les explications sur les signatures de transactions. Il peut alors désigner un nombre auxiliaire secret, appelé scalaire, que l’algorithme emploie avec la Private Key, la clé privée qui autorise une dépense. Réutiliser ce nombre à tort pour des messages différents peut révéler la clé. Le Nonce de minage, lui, est public et un même nombre peut figurer dans plusieurs en-têtes. Les parties publiques d’une signature ne sont pas non plus ce nombre auxiliaire secret. Les exigences de l’un de ces usages ne se transposent donc pas automatiquement à l’autre. [9]

Lorsque de nombreux appareils travaillent ensemble dans un Mining Pool, ils ne devraient pas tous calculer les hashes des mêmes en-têtes. Les répétitions n’ajoutent aucun nouvel essai. Le coordinateur leur attribue donc des données différentes, par exemple pour coinbase et Extranonce. Des protocoles comme Stratum transmettent les tâches ; les unités de minage connectées sont aussi appelées workers. BIP23 décrit également le paramètre facultatif noncerange, qui délimite une plage de Nonce. Cela n’oblige pas tous les pools à l’utiliser et ne leur permet pas de modifier les règles de validité des blocs. [4] [2]

Un Merkle Tree combine progressivement les empreintes des transactions pour obtenir une empreinte commune, le Merkle Root. L’identifiant de la transaction coinbase, son txid, entre dans ce calcul comme une feuille de l’arbre. Modifier Extranonce produit donc un nouveau txid, puis un nouveau Merkle Root. Le mineur peut conserver les autres transactions et la référence au bloc précédent tout en obtenant un autre en-tête. Il ne réécrit pas un bloc confirmé : il modifie une proposition de nouveau bloc pour laquelle il reste à trouver un Proof of Work valide. [1] [2]

Le logiciel peut créer d’autres en-têtes en modifiant le temps, nTime, dans les limites permises ou en changeant les bits de version autorisés. Cette seconde technique s’appelle version rolling. BIP320 propose un usage général de certains bits nVersion ; cette proposition n’autorise pas à modifier arbitrairement tous les bits. Les règles du réseau et celles de la tâche attribuée restent applicables. Aucune de ces possibilités ne dispense le hash final de respecter le target valide. Le BIP323 propose davantage de bits et reste au stade Draft, c’est-à-dire de brouillon. [4] [5] [10]

Pour lire la documentation technique, connaître le format est utile. L’en-tête contient 80 octets : version, hash du bloc précédent, Merkle Root, temps, nBits et Nonce de quatre octets. Ce dernier est un entier non signé de 32 bits, de type uint32. Il est encodé dans l’ordre little-endian, avec l’octet de poids le plus faible en premier. Modifier le Nonce seul change l’en-tête et son hash double-SHA-256, pas la liste des transactions. Le logiciel exige cette représentation exacte, mais comprendre le minage ne nécessite pas de savoir la construire à la main. [1]

Un lecteur avancé peut utiliser getblockheader dans Bitcoin Core avec le hash d’un bloc précis. La sortie détaillée par défaut contient notamment nonce, bits et time. Régler le paramètre verbose sur false renvoie les 80 octets exacts de l’en-tête en hexadécimal. Ils permettent de recalculer double-SHA-256 et de comparer le résultat numérique au target valide. Une implémentation personnelle doit respecter l’ordre des octets de Bitcoin : inverser des octets à tort change la comparaison. Lire le Nonce dans un explorateur ne remplace pas cette vérification. [1] [6] [8]