Transaction coinbase

Imaginons qu’Anna prépare un bloc candidat au minage. Elle rassemble les paiements des utilisateurs et place devant eux une transaction spéciale désignant les bénéficiaires de la récompense. Dans notre exemple, les règles autorisent 3,125 BTC nouveaux et les paiements sélectionnés apportent 0,075 BTC de frais. Anna peut donc réclamer au maximum 3,2 BTC. Cette première transaction est coinbase. L’inscrire ne suffit pas à gagner la récompense : le bloc doit satisfaire l’exigence de minage et toutes les autres conditions, que les nœuds destinataires vérifient eux-mêmes. Si elle réclame trop, ils rejettent le bloc entier, quelle que soit l’énergie dépensée pour le trouver. Aucun compte central ne lui envoie le paiement. Les nouvelles pièces apparaissent selon des règles communes dans un bloc accepté. Sur les 3,2 BTC de l’exemple, seuls 3,125 BTC sont nouveaux ; les utilisateurs ont payé le reste. Il s’agit d’une récompense, pas d’un bénéfice net : les coûts du minage n’ont pas été déduits. [6] [4]

L’émission nouvelle autorisée s’appelle Block Subsidy et est périodiquement divisée par deux lors du Halving. Le satoshi est la plus petite unité du bitcoin. Les frais dépendent des paiements inclus : deux blocs peuvent donc rapporter des récompenses différentes. Le plafond additionne l’émission autorisée à cette hauteur, calculée par GetBlockSubsidy dans Bitcoin Core, et les frais des autres transactions valides du bloc. Seule l’émission augmente la quantité de bitcoins ; les frais sont des satoshis existants. Le mineur peut réclamer moins, sans rattrapage ultérieur : l’émission non réclamée ne naît pas et les frais non collectés deviennent définitivement impossibles à dépenser. Un seul satoshi en trop invalide tout le bloc. [4] [6]

La récompense va souvent à un pool qui coordonne plusieurs mineurs. Un script de verrouillage est un court programme qui définit les conditions permettant de dépenser une sortie. PPS, FPPS et PPLNS désignent différentes façons de répartir les revenus du pool entre participants. Les sorties utilisent des scripts de verrouillage ordinaires. La récompense peut rejoindre une adresse commune, être répartie entre destinataires ou réserver une part à l’opérateur du pool. Les nœuds vérifient montants et conditions de dépense, pas les contrats ni les bénéficiaires réels. PPS, FPPS, PPLNS, seuils de paiement et virements ultérieurs aux participants relèvent du pool, pas du consensus Bitcoin. [6] [7]

Anna voit la récompense dans le bloc, mais ne peut pas encore payer sa facture d’électricité avec. Aucune plateforme ne la retient : les règles de Bitcoin imposent l’attente. La hauteur est le numéro de position d’un bloc ; H désigne ici la hauteur du bloc qui a créé la récompense. COINBASE_MATURITY impose au moins 100 de différence entre la hauteur du bloc contenant la dépense et celle du bloc qui a créé la sortie. Une sortie créée à H peut être dépensée pour la première fois dans un bloc valide H+100. L’affichage des confirmations peut sembler différent, car le bloc créateur compte déjà comme première confirmation. C’est la différence de hauteurs qui importe, pas une estimation en heures. La respecter ne garantit pas que le bloc restera toujours dans la chaîne. [5]

Une réorganisation fait passer le nœud à une autre branche valide possédant davantage de travail de minage cumulé. Les UTXO sont les sorties non dépensées, autrement dit les montants individuels disponibles. La récompense peut disparaître de cet ensemble avec son bloc. Une réorganisation peut retirer le bloc initial de la chaîne valide active ayant le plus de travail cumulé. Ses sorties coinbase disparaissent alors de l’ensemble UTXO actif. Les transactions dépensant la récompense peuvent aussi être touchées. Attendre 100 blocs limite les conséquences des réorganisations courtes sans offrir de garantie absolue. Le pool doit distinguer récompense active, possibilité de dépense et obligations envers ses mineurs. [4] [5]

Quelques termes décrivent le format : une entrée désigne normalement les fonds dépensés ; une sortie fixe un montant et ses conditions de dépense. Le txid identifie la transaction, sa version précise le format et locktime peut limiter le moment de son inclusion. Un bloc doit contenir au moins une transaction ; seule la première peut être coinbase. Elle possède une seule entrée avec une référence nulle à une sortie antérieure : un hash de 32 octets nuls et l’index 0xffffffff. Cette référence, appelée outpoint, ne dépense rien d’existant : il n’y a donc pas de signature ordinaire à vérifier pour autoriser une dépense antérieure. La transaction conserve txid, version, locktime et une ou plusieurs sorties. [1] [2] [3]

La hauteur est le numéro de position d’un bloc. BIP34 désigne une proposition dont Bitcoin a adopté la règle ; scriptSig est un champ de l’entrée et CScript représente les instructions et nombres des scripts. BIP34 exige que scriptSig commence par la hauteur du bloc sous forme de nombre CScript encodé au minimum. Le champ entier mesure 2–100 octets. Peuvent suivre une extra nonce, l’identifiant du pool ou des données de minage fusionné. Une hauteur ou longueur incorrecte entraîne le rejet. Bien que l’entrée ne soit pas exécutée comme un script ordinaire de déverrouillage, ses opcodes de signature peuvent compter dans la limite sigops, qui plafonne le nombre d’opérations de signature. [1] [9]

Le minage calcule sans cesse un hash, l’empreinte numérique du résumé du bloc appelé en-tête. Un nonce est un nombre que l’on fait varier ; la racine de Merkle résume les transactions en une empreinte. Modifier une transaction ouvre ainsi de nouveaux essais. Le nonce de l’en-tête ne compte que 32 bits, rapidement explorés par le matériel de minage. Le logiciel modifie donc aussi une extra nonce dans coinbase. Cela change le txid, la racine de Merkle puis l’en-tête, ouvrant un nouvel espace de recherche de hashes. Le pool répartit le travail entre appareils pour éviter de tester inutilement les mêmes variantes. L’extra nonce ne crée aucune monnaie supplémentaire. [6] [7] [12]

SegWit sépare certaines données de vérification, comme les signatures, dans une partie appelée witness. Un commitment relie des données de manière vérifiable ; ce n’est pas un autre paiement. Le format ci-dessous en donne la référence technique. Si le bloc contient des données witness, BIP141 exige une sortie coinbase avec un witness commitment, un engagement cryptographique sur ces données. Son script commence par 6a24aa21a9ed : OP_RETURN, insertion de 36 octets et marqueur aa21a9ed. Suit un double hash SHA-256 de 32 octets calculé sur la racine de Merkle witness concaténée à la valeur réservée. Le witness de l’entrée coinbase doit contenir cette seule valeur réservée de 32 octets. Si plusieurs sorties correspondent, l’index le plus élevé prévaut. Ce n’est pas un paiement dépensable ; sans données witness dans le bloc, l’engagement est facultatif. [10]

Un Full Node est un ordinateur vérifiant lui-même les règles de Bitcoin. Le poids mesure l’utilisation de la capacité de données autorisée du bloc ; le Mempool conserve localement les transactions ordinaires non confirmées. Vérifier la récompense fait partie de la vérification du bloc entier. Un Full Node exige coinbase en première position et refuse toute coinbase supplémentaire dans ce bloc. Il vérifie scriptSig, hauteur BIP34, plages de montants, poids du bloc, frais et witness commitment requis. La somme des sorties ne peut dépasser émission autorisée plus frais ; une dépense ultérieure doit respecter la maturité. Le mineur ne peut donc pas s’attribuer valablement n’importe quel montant. Sans son bloc, coinbase n’entre pas dans le Mempool. [3] [4] [10]

Genesis Block est le bloc de départ de Bitcoin. Son statut particulier et les anciens identifiants répétés expliquent pourquoi les règles ordinaires actuelles ne s’appliquent pas indistinctement à tous les cas historiques. Avant que la hauteur soit obligatoire, plusieurs coinbase pouvaient avoir le même txid. BIP30 empêche d’écraser d’anciennes sorties encore non dépensées ; BIP34 ajoute une hauteur distinctive dans les blocs modernes ordinaires. Genesis Block est particulier : sa coinbase figure bien dans le bloc enregistré, mais l’initialisation n’a pas rendu sa sortie dépensable. Les 50 BTC d’origine ne peuvent donc être dépensés ; ce n’est pas une attente normale de 100 blocs. [8] [9] [11]