Header de bloc Bitcoin : structure et champs
L'en-tête de bloc est le seul objet que la machine hashe en boucle. Le reste du bloc, transactions, signatures et scripts, n'entre dans le proof-of-work que par un résumé de 32 octets : la racine de Merkle. Comprendre l'en-tête, le nonce et l'extraNonce revient à comprendre ce que fait réellement un mineur.
Ce que contient l'en-tête
Un en-tête Bitcoin fait 80 octets. Dans l'ordre habituel du protocole :
- la version du bloc ;
- le hash du bloc précédent, qui forme le lien de la chaîne ;
- la racine de Merkle des transactions de ce bloc ;
- l'horodatage, ou nTime ;
- nBits, forme compacte de la cible de difficulté ;
- le nonce, champ de 32 bits.
Le réseau accepte un bloc si le double SHA-256 de ces 80 octets est numériquement inférieur à la cible déduite de nBits. Il n'existe aucun autre critère de travail sur l'en-tête, et aucune méthode connue pour calculer le bon nonce autrement qu'en l'essayant.
Un opérateur n'assemble jamais cet en-tête à la main. Le pool, ou le nœud en solo, fournit les champs stables du job ; le firmware les pose, fait tourner le nonce, et change autre chose quand il le faut.
Le nonce de l'en-tête
Le nonce est un entier de 32 bits, soit environ 4 milliards de valeurs. Chaque valeur donne un en-tête différent, donc un hash différent. Un ASIC moderne parcourt cet espace en une fraction de seconde, ce qui a une conséquence directe : le nonce seul ne suffit plus à alimenter la machine.
Quand l'espace est épuisé, un autre champ de l'en-tête doit changer, faute de quoi la machine re-hashe indéfiniment les mêmes 80 octets.
extraNonce : élargir l'espace sans toucher au protocole
L'en-tête ne prévoit pas de second nonce. La pratique établie consiste à placer un extraNonce dans la transaction coinbase, la première du bloc, celle qui crée la récompense et porte souvent un message du mineur.
Changer l'extraNonce change la coinbase, donc le hash de cette transaction, donc la racine de Merkle, donc les 80 octets de l'en-tête. Le mineur récupère ainsi un espace de nonces entièrement neuf, sans modifier la moindre règle de consensus.
En pool, le schéma classique de Stratum v1 répartit ce levier :
- le pool envoie des morceaux de coinbase et des branches de Merkle ;
- le firmware, ou un proxy, y insère un extraNonce qui lui est propre ;
- il recalcule la racine, puis balaie le nonce d'en-tête.
Deux machines du même pool ne doivent jamais explorer le même couple extraNonce et nonce sur le même job. Le pool alloue pour cela des plages distinctes, et une mauvaise allocation se traduit directement par des shares dupliquées.
nTime, version, et les champs imposés
Deux autres champs peuvent bouger dans des limites strictes :
- nTime se déplace dans une fenêtre autour de l'heure du réseau. Trop en avance ou trop en retard, le bloc est rejeté. À l'intérieur de la fenêtre, avancer d'une seconde renouvelle l'en-tête aussi efficacement qu'un nouveau nonce de départ.
- version accepte, sur certains jobs, un masque de bits négocié avec le pool. C'est un levier d'espace de recherche supplémentaire, encadré par les règles du nœud.
nBits et le hash du bloc précédent sont imposés par la chaîne courante. Aucun réglage ne les concerne.
Ce que ça implique en exploitation
Le travail utile consiste à produire des doubles SHA-256 d'en-têtes candidats jusqu'à passer soit la cible de share du pool, soit la cible réseau. La liste des transactions n'est pas re-hachée à chaque essai : elle reste figée dans la racine de Merkle jusqu'à ce que la coinbase, l'extraNonce ou le template change.
Trois conséquences concrètes :
- Un job périmé rend l'espace en cours sans valeur. La latence d'arrivée du nouveau template pèse donc plus lourd sur vos revenus qu'un nonce prétendument chanceux.
- Un extraNonce mal géré, avec des collisions entre workers ou un template incomplet, produit des shares orphelines qui n'apparaissent nulle part au crédit.
- Le midstate, traité sur une autre page, n'est qu'une optimisation interne : les premiers octets de l'en-tête ne changent pas à chaque nonce.
Trouver un nonce valide reste un tirage dans un espace énorme, sous une cible que le réseau réajuste tous les 2016 blocs. Aucun firmware ne calcule la solution plus vite ; il essaie davantage d'en-têtes par seconde, ou les mêmes en-têtes avec moins de pertes. C'est sur ces pertes, pas sur la chance, que vous avez prise.
Acheter ou comparer via The Bitcoin Bay
The Bitcoin Bay est apporteur d'affaires indépendant : nous référençons les ASIC neufs sourcés directement chez les constructeurs (Bitmain, MicroBT, Bitdeer, Canaan) et les machines reconditionnées via revendeurs partenaires vérifiés. Chaque modèle est apparié à des options de hosting professionnel chez nos sites en Europe du Nord et au Paraguay.
Pas de promesse de rendement, pas de paiement traité chez nous — la transaction se signe directement avec le partenaire choisi. Statut CIF/AMF non sollicité.
Sur le même sujet
Monitoring d'un miner : outils et métriques
Surveiller un mineur, c'est comparer ce que la machine dit à ce que le pool compte. Les six familles de signaux à suivre et la méthode pour les interpréter sans se tromper de cause.
LireLogs Bitmain et kernel panic : diagnostic
Lire les logs d'un contrôleur Bitmain dans l'ordre du temps, classer le motif en cinq familles, et traiter un kernel panic comme un arrêt du contrôleur plutôt que comme un problème de minage.
LireJobs Stratum et clean_jobs
Un job Stratum est un contrat de travail, le drapeau clean_jobs le révoque. Les cinq causes d'invalidation et ce que vous pouvez réellement corriger.
Lire