Un Block Template rassemble les données permettant de construire un bloc candidat sur le réseau Bitcoin. Le mineur cherche ensuite une preuve de travail valide sur son en-tête, un résumé compact des données du bloc. Le modèle relie les transactions choisies, la récompense et les règles de construction. L’obtenir ne signifie pas qu’un bloc a été miné ou accepté par le réseau.
Chaque nouveau bloc s’appuie sur un prédécesseur précis. Le modèle le désigne par previousblockhash, son empreinte unique, tandis que height indique la position du bloc proposé dans la chaîne. Il contient aussi version, la version de l’en-tête, bits, un codage compact de la cible du résultat de minage, et des données temporelles. Ces informations servent à construire un bloc particulier, pas une liste de paiements indépendante. Les mêmes transactions placées après un autre prédécesseur constituent déjà une autre tâche. [1]
Anna reçoit du bitcoin, puis paie avec. Si les deux transferts doivent figurer dans le même bloc, la transaction qui lui attribue les fonds doit précéder celle qui les dépense. BIP 22, le document technique décrivant le format du modèle, définit le champ depends pour ces relations : le champ renvoie à des entrées antérieures de la liste transactions, avec une numérotation commençant à un. Cette liste exclut la coinbase, la première transaction particulière qui attribue la récompense au mineur. L’absence de depends signifie que les dépendances sont inconnues, pas qu’elles n’existent pas. Le logiciel ne doit pas assimiler une information manquante à une liste vide. [1]
La récompense comprend les bitcoins nouvellement émis selon les règles de cette hauteur et les frais des transactions réellement incluses. La version citée, Bitcoin Core v29.0, la calcule ainsi. Ce logiciel vérifie les blocs et les transactions et peut aussi préparer des modèles pour le minage. Dans notre exemple, les transactions apportent 10000 sats ; retirer une transaction indépendante payant 3000 sats laisse 7000 sats de frais. Les sats sont de petites unités de bitcoin. Le champ coinbasevalue indique la récompense maximale que le mineur peut s’attribuer avec la sélection initiale de transactions. Si cette sélection change, il faut recalculer le montant. Il faut partir des frais réels, pas du total calculé pour l’ancien contenu. [4] [1]
Un bloc contient aussi des empreintes cryptographiques permettant de vérifier ses données. BIP 141 décrit le witness commitment, une empreinte cryptographique liant le bloc aux données witness, qui comprennent notamment des signatures prouvant l’autorisation de dépenser. Ce commitment est dérivé des identifiants wtxid incluant ces données. Bitcoin Core 29 fournit default_witness_commitment pour un modèle inchangé. Après modification des transactions concernées ou de leur ordre, il faut vérifier ou recalculer cette empreinte. Le Merkle root, l’empreinte commune des transactions dans l’en-tête, doit aussi être calculé à partir des identifiants TXID définitifs, y compris celui de la coinbase modifiée. Un ancien sceau ne convient pas à un contenu modifié. [5] [3]
La place dans un bloc est limitée et le mineur choisit ce qu’il inclut. Bitcoin Core v29.0 examine des groupes de transactions liées, leur poids, une mesure de charge de données, et les sigops, les opérations de vérification de signatures comptabilisées pour la limite du bloc. Les réglages blockmaxweight et blockmintxfee influencent la taille du bloc construit et le taux de frais exigé. Il s’agit d’une politique de sélection. Un paiement écarté pour cette raison n’est pas nécessairement invalide selon les règles du réseau. Les réglages d’un mineur ne relèvent pas non plus les limites que les autres nœuds vérifient. [4] [3]
Dans BIP 23, mutable énumère les changements autorisés par le serveur, par exemple ajuster le temps ou ajouter des transactions. C’est un accord sur l’utilisation d’un modèle particulier. Il n’annule pas le consensus, c’est-à-dire les règles de validité que les autres participants vérifient indépendamment. Le prédécesseur, le temps, la difficulté et les transactions doivent toujours être corrects. Accéder au modèle ne signifie pas non plus que chaque appareil connecté peut en modifier librement le contenu ; cela dépend de l’organisation et de la tâche reçue. [2]
Un autre mineur peut prolonger la chaîne pendant les calculs. Pour poursuivre à partir du dernier bloc accepté, remplacer simplement l’empreinte du prédécesseur dans l’ancien modèle ne suffit pas. Certaines transactions peuvent déjà être confirmées, et la hauteur comme d’autres conditions changent. BIP 23 décrit expires comme une limite temporelle du travail et prevblock comme l’autorisation de l’utiliser avec un autre prédécesseur. Même cette autorisation ne remplace pas la validation : il faut réexaminer les transactions, la récompense et l’ensemble du nouveau contexte. [2]
Mieux vaut repérer une erreur dans son projet avant une longue recherche. Le mode proposal de BIP 23 permet de le soumettre à une vérification sans exiger de Proof of Work valide, donc sans résultat déjà trouvé démontrant le travail de calcul requis. Une réponse positive ne signifie ni qu’un bloc a été trouvé ou diffusé, ni qu’une place permanente dans la chaîne est garantie. Elle indique que le projet a passé la vérification préalable concernée. Le bloc terminé devra encore être validé à sa soumission, preuve de travail comprise. [2]
Pour une vision complète, lisez aussi Mining Pool, Block Header, Extranonce, Merkle Tree, Bitcoin, Bitcoin Core. Cette entrée est également citée par Transaction coinbase, ASIC Miner, Mining Pool, Nonce.