Problèmes d'implémentation en Python dans les pools de minage utilisant le protocole Stratum

Un développeur tente de créer un script Python pour miner des cryptomonnaies. Malgré l'utilisation d'un code simplifié et d'une connexion à un serveur de test, il rencontre des difficultés pour obtenir une réponse positive. Il partage son processus en plusieurs étapes et sollicite de l'aide pour corriger les erreurs éventuelles.

Le développeur se connecte au serveur et reçoit des données

Le développeur commence par établir une connexion avec le serveur du pool de minage. Il utilise le code simplifié fourni par NightMiner ainsi qu'un testnet identifié sous l'adresse stratum+tcp://pool.bitcoincloud.net:4008. Après avoir envoyé les requêtes suivantes : b’{ « id » : 1, « method » : « mining.subscribe » , « params » : []}\n b’{ « params » : [ « testuser » , « anything » ], « id » : 2, « method » : « mining.authorize » }\n Il reçoit en retour des informations cruciales : { « id » :1, « result » :[[[ « mining.set_difficulty » , « deadbeefcafebabea200000000000000 » ],[ « mining.notify » , « deadbeefcafebabea200000000000000 » ]], « 40000004 » ,4], « error » :null} Cette réponse lui permet de connaître la difficulté du minage ainsi que les notifications requises pour continuer.

La construction de la racine Coinbase et Merkle est entamée

Avec les données obtenues, il construit la coinbase en utilisant l'extranonce : coinbase=coinb1+extranounce1+extranounce2+coinb2 La coinbase finale est affichée comme suit : b’010000000100000000...88ac00000000’ Ensuite, il applique un double hachage SHA256 sur cette coinbase qui lui fournit le résultat suivant : b’9b9c9ab0b1c92844e4fed3f895f9443fefcda5ae02cc5a8ad4444f9303081a23’ Ce hachage devient alors sa racine Merkle.

L’en-tête est créé à partir des données reçues

Il passe ensuite à la création de l’en-tête dans lequel il intègre plusieurs valeurs importantes : - version : '20000000' (après conversion little-endian : '00000020') - prevhash : '4128bf630f57387...' (converti en ordre inverse) - racine merkle : '9b9c9ab0...3081a23' - ntime : '5e148a8c' (converti) - nbits : '1a02b098' (converti) L'en-tête complet devient donc : b’000...98b0021a’ + rare nonce Les valeurs sont soigneusement manipulées pour s'assurer qu'elles respectent le format requis.

Une recherche occasionnelle est effectuée pour valider le travail

Avec une difficulté fixée à 0,01, il définit son objectif comme étant : 000...63ff9c... À travers quelques calculs supplémentaires, il détermine ces quatre octets à utiliser : b’d0cf1040’ Son en-tête complet finalise alors comme suit : b’...d0cf1040', qui donne lieu à un hash après double-hachage SHA256. Ce hash obtenu est inférieur à son objectif ce qui indique que « d0cf1040 » devrait être valide.

Soumission du résultat au serveur sans succès

Pour clore ses opérations, il soumet ses résultats au serveur avec la requête suivante : b’{ « id » :2, « method » : « mining.submit » , ...} Malheureusement, sa réponse est négative : { « id » :2, « result » :false, « error » :null} Cette erreur soulève des questionnements concernant l'étape trois sur la construction de l'en-tête. Le développeur soupçonne que cela pourrait être lié aux erreurs dans l'ordre des octets mais peine à identifier où réside exactement le problème malgré ses multiples essais. Il conclut cet exposé en demandant activement aux membres plus expérimentés de vérifier ses calculs et lui fournir leurs conseils afin d'améliorer son script.