getblocktemplate est une interface permettant à un logiciel d’obtenir, auprès d’un nœud Bitcoin, les données nécessaires pour assembler un bloc candidat. Elle utilise JSON-RPC : une requête et une réponse structurée échangées entre programmes. Le mode habituel fournit un modèle ; un autre peut examiner une proposition de bloc au préalable. Aucun ne recherche lui-même une preuve de travail.
Dans le mode habituel mode=template, le programme de Pierre reçoit notamment le bloc précédent, les transactions et la récompense autorisée. C’est une proposition de travail, pas un bloc déjà trouvé. Le logiciel doit construire coinbase, la première transaction particulière qui attribue la récompense, puis achever le bloc. L’en-tête résume les données du bloc sous une forme compacte. Le logiciel cherche ensuite un hash, une empreinte cryptographique numérique de cet en-tête, qui respecte la cible de minage et constitue le Proof of Work, la preuve du travail de calcul. getblocktemplate ne reçoit aucune adresse de paiement et ne lance aucun calcul de machine de minage. Une réponse réussie ne signifie donc pas encore que Pierre mine. [1]
Imaginons que le nœud envoie des données sous une forme que le programme de Pierre ne comprend pas. La requête indique donc les règles prises en charge dans rules. Bitcoin Core v29.0, la version vérifiée ici, exige segwit, ainsi que signet pour le réseau de test Signet. SegWit modifie notamment le traitement des données servant à vérifier les transactions. Inscrire le bon mot ne suffit pas : le logiciel doit savoir les traiter. capabilities annonce d’autres fonctions de l’interface et ne remplace pas rules. Les exigences précises dépendent de l’implémentation et de la version utilisées. [2]
Le champ data contient la transaction complète, organisée pour être transmise entre programmes. Cette mise en forme s’appelle la sérialisation. Les octets, les unités de base de ces données, sont représentés en hexadécimal avec les chiffres 0–9 et les lettres a–f. La réponse contient aussi de courts identifiants de transaction. Selon le document technique BIP 145, txid est calculé sans les données witness, tandis que hash les inclut. Witness contient notamment des signatures prouvant l’autorisation de dépenser. La Merkle root principale, l’empreinte regroupant les transactions dans l’en-tête du bloc, utilise txid, et non le witness hash. Confondre ces champs dépasse une simple erreur de nom : cela peut produire une empreinte globale incorrecte et rendre le bloc assemblé invalide. [3]
Pierre n’a pas besoin de bombarder le nœud de demandes pour savoir si quelque chose a changé. Le long polling garde une requête ouverte jusqu’à ce que le serveur veuille remplacer les données précédentes. Le programme récupère longpollid et le renvoie sans le modifier. Cette valeur indique au serveur quelle mise à jour le programme attend. Le programme ne doit pas chercher à interpréter les caractères de cette valeur. BIP 22 prévoit un long délai d’attente. Des réponses incomplètes ou invalides répétées exigent d’espacer les tentatives, plutôt que de réessayer immédiatement en boucle. Une attente silencieuse n’est donc pas, à elle seule, une panne. [4]
Même une requête ordinaire répétée ne garantit pas un contenu nouvellement sélectionné. Bitcoin Core v29.0 garde un modèle préparé en cache. Il le reconstruit si le prédécesseur change, ou si le mempool, l’ensemble local des transactions non confirmées, a changé et que plus de cinq secondes se sont écoulées depuis la préparation. Il peut mettre à jour séparément l’heure de l’en-tête. Pierre peut donc recevoir la même sélection de transactions ; cela ne signifie pas que le nœud est bloqué. Ce fonctionnement propre à une version ne promet pas non plus une tâche de minage unique à chaque appel. [2]
Pierre a modifié la construction du bloc et veut repérer les erreurs avant une recherche coûteuse. En mode proposal, il fournit le bloc complet en hexadécimal dans data. Bitcoin Core v29.0 vérifie aussi la Merkle root, mais n’exige pas qu’un Proof of Work valide, la preuve du travail de calcul, soit déjà trouvé. Si la proposition ne prolonge pas le dernier bloc de la chaîne suivie par le nœud, il renvoie inconclusive-not-best-prevblk. Une condition préalable à cette vérification manque ; ce n’est pas un examen complet de validité. Cet examen préalable ne diffuse pas non plus le bloc sur le réseau. [2]
Une fois la preuve de travail nécessaire trouvée, le logiciel peut soumettre le bloc complet avec submitblock. hexdata contient tout le bloc sérialisé en hexadécimal, et non son seul en-tête ou son empreinte. La documentation de Bitcoin Core 29 indique null en cas d’acceptation et sinon un résultat textuel conforme à la spécification. Le second paramètre facultatif, dummy, est ignoré ; il ne fixe pas la récompense. L’acceptation par un nœud ne garantit pas une confirmation définitive : l’évolution ultérieure de la chaîne peut changer la branche qui reste principale. [5]
Un nœud qui vient de démarrer n’a pas forcément téléchargé et vérifié l’historique nécessaire. Sur le réseau principal, mainnet, Bitcoin Core v29.0 refuse de fournir un modèle sans pairs connectés ou pendant la synchronisation initiale IBD (initial block download). Cela concerne sa capacité à travailler avec l’état actuel du réseau, pas le rejet d’un bloc particulier. Pour diagnostiquer un problème, on distingue donc un long poll en attente, un nœud pas encore prêt et le résultat de l’examen d’une proposition. Tous peuvent ressembler à « je n’ai pas de nouveau travail », mais appellent des réponses différentes. [2]
Pour une vision complète, lisez aussi Block Template, Minage, Stratum V2, Extranonce, Bitcoin, Bitcoin Core. Cette entrée est également citée par ASIC Miner, Solo Mining, Job Negotiation.