Causes des shares rejetées

Une share rejetée est une preuve que le pool, ou l'agent local, refuse de compter. Les tableaux de bord ne la nomment pas tous pareil : certains fusionnent stale et rejected, d'autres les séparent. Commencez donc par lire la légende de votre pool, sinon vous comparerez deux compteurs différents. Les rejets se rangent ensuite dans quatre familles, plus un fourre-tout de règles de pool.

Stale (job trop vieux)

Le mineur a produit une preuve correcte sur un job déjà remplacé. Le réseau a avancé, ou le pool a poussé un nouveau template. Le hash peut être mathématiquement valide, il arrive trop tard pour le job courant.

Un taux de stale non nul est normal, puisque les blocs arrivent en permanence. Ce qui compte est la comparaison : si une machine diverge nettement des autres du même site et du même pool, la cause est dans le chemin réseau, dans le firmware (file d'attente trop longue, submit tardif), ou dans un failover mal réglé. Voir aussi l'article sur les jobs Stratum et les clean jobs.

Duplicate

Le pool reçoit deux fois la même share : même job, même nonce et extra-nonce, même preuve. Les causes habituelles :

• double soumission, quand un agent réessaie trop vite ou que deux sessions restent ouvertes ;
• bascule de pool mal gérée, deux endpoints stratum recevant le même travail ;
• horloge ou file d'attente qui rejoue un submit déjà envoyé.

Un duplicate ne rapporte rien : c'est du travail déjà compté une fois, et le pool ne le comptera pas deux fois.

Difficulté trop basse (cible de share non atteinte)

Le pool assigne une difficulté de share, une cible plus facile que la cible réseau. Si le hash soumis ne bat pas cette cible, le pool refuse, parce que la preuve n'est pas assez dure pour le contrat en cours.

Les causes tournent toujours autour d'un désaccord sur la cible : firmware qui soumet trop tôt, job mal lu, agent qui mélange deux difficultés après une bascule, ou réglage local qui ignore la difficulté que le stratum vient d'annoncer. Attention à ne pas confondre avec la difficulté Bitcoin recalculée tous les 2016 blocs : ici, il s'agit du compteur du pool. Voir l'article sur la difficulté.

Difficulté trop haute (incohérence de cible)

Moins visible dans le vocabulaire des dashboards, c'est la même famille à l'envers : le mineur croit encore à une ancienne difficulté alors que le pool en a annoncé une autre, ou l'opérateur calcule un hashrate effectif avec la mauvaise difficulté de share.

Le symptôme est reconnaissable : le nombre de shares explose ou s'effondre alors que le hashrate local ne bouge pas. Avant de conclure à une hashboard morte, vérifiez que la difficulté de share affichée côté pool et côté machine parle de la même fenêtre.

Horloge (time / nTime)

L'en-tête porte un horodatage. Certains pools ou agents rejettent une share dont le nTime est trop éloigné de leur horloge, ou sort de la fenêtre du job. Une horloge système dérivée entre dans cette catégorie : contrôleur sans NTP, pile CMOS morte, firmware qui fige l'heure.

Si les rejets portent un motif « time », « ntime » ou « timestamp », comparez l'heure du contrôleur à une source de confiance sur le même VLAN, puis à celle du pool. Les tolérances exactes dépendent du pool et de l'agent, et figurent dans leur documentation.

Les autres rejets

Hors de ces familles restent les règles propres au pool : worker inconnu, share mal formée, extra-nonce hors plage, job id inconnu, IP non autorisée, ban temporaire. Ce sont des messages d'identité et de protocole, pas des statistiques de salle, et ils se corrigent dans la configuration du compte ou du réseau.

Procédure pour isoler la cause

Quand un taux de rejet grimpe, cette séquence évite les diagnostics à l'aveugle :

1. Relever le motif exact du rejet dans les logs du miner et dans l'interface du pool. Sans motif, il n'y a pas de diagnostic, seulement des hypothèses.
2. Comparer la machine à ses voisines immédiates : même pool, même switch, même firmware. Un problème isolé sur une machine et un problème général sur le site n'ont pas les mêmes causes.
3. Changer une seule variable à la fois : URL du pool, câble, port du switch, nom du worker, synchronisation NTP.
4. Attendre une fenêtre d'observation suffisante avant de conclure. Sur quelques minutes, la variance de share domine tout ce que vous mesurez.
5. Ne remonter au matériel qu'après avoir écarté job, réseau et horloge. Un stale isolé après un bloc n'est pas une hashboard morte.

Un dernier réflexe à éviter : reprendre un « taux normal » en pourcentage lu ailleurs. La variance courte, le temps d'aller-retour réseau, le pool et le firmware pèsent trop pour qu'un chiffre générique veuille dire quoi que ce soit sur votre site. Votre référence utile, c'est votre propre parc la semaine précédente.