Coinbase et work : construction du travail de minage

La transaction coinbase est la première du bloc. Elle crée les bitcoins de la subvention et y agrège les frais, selon les règles en vigueur. Pour le mineur, elle est aussi le levier qui fait bouger la racine de Merkle, donc l'en-tête, une fois le nonce de 32 bits épuisé.

Ce qui distingue la coinbase

Une transaction classique dépense des sorties existantes. La coinbase, elle, n'a pas d'entrée réelle au même sens : elle ancre la création monétaire du bloc. Elle doit respecter des règles de consensus précises, notamment la hauteur du bloc, l'encodage, le plafond de récompense et la maturité avant dépense. Le détail applicable est celui qu'appliquent les nœuds, à vérifier dans leur implémentation plutôt que dans un article.

Elle peut porter un message sous forme de chaîne dans le script, un identifiant de pool, et surtout un extraNonce. Aucun de ces champs ne constitue le proof-of-work : ce sont des données qui entrent dans le hash de la coinbase.

En pool, vous ne rédigez généralement pas la coinbase entière. Le pool envoie deux morceaux, un préfixe et un suffixe, entre lesquels le firmware glisse l'extraNonce qui distingue votre worker. En solo, votre nœud compose la coinbase avec votre adresse et le template local.

De la coinbase à la racine de Merkle

Chaque transaction du bloc a un hash. Ces hashes sont combinés deux à deux dans un arbre de Merkle jusqu'à obtenir une racine de 32 octets, troisième grand champ de l'en-tête après la version et le prevhash.

La coinbase occupe la feuille tout à gauche de cet arbre. Changer un seul octet de la coinbase change son hash, donc tous les nœuds parents jusqu'à la racine. Les autres transactions n'ont pas besoin d'être re-hachées une à une dès lors qu'on possède les branches de l'arbre, et c'est précisément pour cela que Stratum envoie des branches de Merkle plutôt que le bloc entier.

Le mineur peut donc renouveler son en-tête sans retélécharger la liste des transactions, tant que le template reste le même.

Ce que le mineur hashe réellement

Le proof-of-work porte sur le double SHA-256 des 80 octets d'en-tête, jamais sur le hash de chaque transaction à chaque nonce. La séquence complète :

1. Le template fixe les transactions hors coinbase, ainsi que nBits et prevhash.
2. La coinbase est finalisée : récompense, extraNonce, message.
3. La racine de Merkle est calculée.
4. L'en-tête est assemblé : version, prevhash, racine, nTime, nBits, nonce de départ.
5. Le nonce tourne. Chaque essai produit un nouvel en-tête et un nouveau double hash.
6. Quand l'espace de nonce est épuisé, l'extraNonce est incrémenté, ou nTime, ou des bits de version autorisés, et le calcul repart de l'étape 3, parfois de l'étape 2.
7. Un hash sous la cible de share part au pool ; un hash sous la cible réseau est un candidat de bloc.

Les signatures des autres transactions ne sont pas minées : elles ont été vérifiées au moment de la construction du template. Si ce template est invalide, aucun nonce ne rendra le bloc acceptable.

Qui choisit quoi

• Pool Stratum v1 classique : le pool choisit les transactions et la structure de la coinbase ; vous choisissez l'extraNonce dans une plage imposée, et le nonce.
• Solo, ou certains modes Stratum v2 : votre nœud choisit les transactions, construit la coinbase, et vous hashez.
• Adresse de paiement : elle se trouve dans la coinbase, ou dans une transaction de payout ultérieure selon le pool. Ce n'est jamais un champ de l'en-tête.

Deux workers qui utiliseraient le même extraNonce sur le même job produiraient un travail dupliqué, donc des shares rejetées. Une erreur d'adresse de paiement relève en revanche de la configuration du compte, pas du hachage.

Ce que vous surveillez

• Le pool accepte-t-il encore le job ? Un template périmé porte une racine de Merkle correspondant à un état du réseau déjà dépassé.
• La coinbase encodée par le firmware est-elle bien celle du job ? Un octet de travers et la racine ne correspond plus, les shares tombent en série.
• Le montant de la récompense correspond-il aux règles en vigueur ? Un nœud rejette tout bloc dont la coinbase réclame plus que le plafond autorisé, quelle que soit la qualité du hash.

Une coinbase correctement formée ne rend pas les hashes plus probables. Elle les rend recevables, ce qui est la seule chose qui compte au moment où le pool valide votre share.