Job Negotiation est l’accord entre un mineur et un pool sur une tâche de minage personnalisée. Stratum V2 définit les règles de communication entre les appareils de minage et le pool. Job Declaration Protocol en est la partie consacrée aux propositions personnalisées, en lien avec la distribution des modèles et des tâches. Le but est de laisser choisir les transactions pendant que le pool continue à comptabiliser le travail et à payer les récompenses. C’est la configuration réelle qui compte, pas seulement le nom de la connexion.
Anna passe à Stratum V2, mais reçoit toujours la liste des transactions du pool. Il n’y a pas de contradiction. Mining Protocol, qui transporte le travail et les résultats, peut fonctionner sans Job Declaration ni Template Distribution. Ce dernier fournit les modèles de blocs ; Job Declaration traite les propositions personnalisées. Pour qu’Anna puisse choisir, ces rôles doivent aussi être présents et le pool doit les prendre en charge. Un transport plus moderne ne dit donc pas, à lui seul, qui décide du contenu d’un bloc sur le réseau Bitcoin. [1] [4]
Les paiements sélectionnés ne doivent pas remplir le bloc au point que sa transaction de récompense, coinbase, ne rentre plus. Le fournisseur du modèle, Template Provider, doit donc connaître la réserve nécessaire. Anna utilise un programme appelé JDC, abréviation de Job Declarator Client. Il recueille les exigences des pools utilisés et les envoie au fournisseur du modèle dans un message de données appelé CoinbaseOutputConstraints. On réserve de l’espace de données et des sigops, les opérations de vérification des signatures comptabilisées dans la limite du bloc. Sinon, les sorties ajoutées à coinbase, qui attribuent les fonds, pourraient dépasser les limites du bloc. Le choix personnalisé doit tenir compte dès le départ de la validité de l’ensemble. [3]
En mode Full-Template, JDC envoie DeclareMiningJob à JDS, le Job Declarator Server du côté du pool ou d’un service auquel celui-ci fait confiance. Le message donne les identifiants des transactions retenues. Si le serveur ne dispose pas d’une de ces transactions, il peut demander ses données avec ProvideMissingTransactions. Anna partage ainsi les informations permettant de vérifier sa sélection. L’accusé de réception de la déclaration et l’acceptation ultérieure de la tâche par le pool sont deux étapes distinctes. Le premier message positif ne termine pas tout l’accord. [2]
En mode Coinbase-only, JDC ne révèle pas l’ensemble des transactions et DeclareMiningJob n’est pas utilisé. Le pool estime le revenu à partir de la coinbase fournie. Cela cache la sélection d’Anna au pool, mais ne prouve pas à lui seul la validité des transactions cachées ni leurs frais réels. La spécification signale expressément ce risque. Partager moins d’informations change aussi ce qui peut être vérifié ; le nom du mode ne garantit pas que toutes les conditions de rémunération soient suffisamment établies. Cette confidentialité concerne la proposition pendant le minage. Si Anna trouve un bloc valide et le diffuse sur le réseau, ses transactions deviennent visibles. [2]
Plusieurs références ressemblantes apparaissent dans les échanges techniques. JDS attribue mining_job_token, que le client cite dans SetCustomMiningJob. Quand le pool accepte la tâche, il répond avec SetCustomMiningJob.Success et son propre job_id. Le jeton et job_id ont des rôles différents : le premier relie les échanges sur la proposition, le second identifie le travail lors de l’envoi des résultats. C’est un peu comme un numéro de demande et un numéro de commande approuvée. Les confondre empêcherait le pool de rattacher le résultat à la bonne tâche acceptée. [1]
Attendre chaque échange réseau retarderait inutilement les appareils. Dès que le client dispose du jeton et du modèle nécessaires, il peut commencer le minage optimiste avant SetCustomMiningJob.Success. Les shares trouvées, des résultats partiels attestant le travail selon la cible du pool, sont conservées jusqu’à confirmation. Une fois la tâche acceptée, elles peuvent être envoyées avec l’identifiant attribué. Une machine en marche ne prouve donc pas encore que le pool a accepté ou comptabilisé ce travail. Le début des calculs et l’engagement de rémunérer la tâche sont deux moments différents. [1] [2]
Si Anna reçoit SetCustomMiningJob.Error ou n’obtient pas de réponse dans un délai raisonnable, la spécification recommande un autre pool, voire le minage en solo. La résistance dépend donc d’un fallback opérationnel, une solution de repli préparée. Si le logiciel reprenait silencieusement le modèle initial du pool qui l’a refusée, il pourrait continuer à tourner, mais perdrait la sélection d’Anna. Il faut donc savoir ce que fait réellement le système en cas de refus. Une capacité décrite dans un protocole ne prouve pas que chaque service la propose. [1] [4]
Anna veut choisir les transactions et conserver les récompenses mutualisées. Son JDC doit donc attribuer une valeur à la sortie coinbase désignée par le pool pour remplir les conditions de ces récompenses. Si elle dirige une partie du revenu ailleurs, le pool peut réduire proportionnellement la rémunération de cette tâche. Job Declaration ne crée pas de paiement direct automatique au mineur et ne supprime pas les conditions comptables du service. Il change surtout qui peut proposer le contenu du bloc ; les règles de validité et la répartition du revenu doivent être examinées séparément. [2]
Pour une vision complète, lisez aussi Stratum V2, getblocktemplate, Mining Pool, Block Template, Bitcoin. Cette entrée est également citée par Stratum V2, Mining Pool Centralization.