DigiByte : pourquoi ce share n'est pas un bloc

MultiShield de DigiByte recalcule la cible de minage SHA-256 chaque fois qu’un bloc arrive sur l’un de ses cinq algorithmes — en moyenne toutes les 15 secondes. La difficulté réseau que vous voyez sur un explorateur, un tableau de bord ou un rapport de minage est un instantané déjà dépassé. Un share qui dépasse cette valeur n’est un bloc valide que s’il dépasse la cible en vigueur à la seconde précise où il atteint le pool. C’est la raison la plus courante pour laquelle un mineur solo sur DigiByte voit un share record et ne gagne rien.

L’essentiel

• Sur DigiByte, la cible SHA-256 est recalculée chaque fois qu’un bloc arrive sur l’un des cinq algorithmes, pas seulement quand un bloc SHA-256 est trouvé.
• Dans une fenêtre de 90 minutes, la difficulté des blocs SHA-256 est allée de 418 millions à 1,12 milliard — un facteur 2,7.
• Sur un seul tronçon de deux minutes, la cible active a grimpé de 75%, de 748 millions à 1,31 milliard.
• La valeur d’un share dépend de la cible à la seconde où il arrive. Le même share peut échouer à un moment et gagner une ou deux minutes plus tard.
• Rien de tout cela ne signifie qu’un bloc a été perdu. Un share sous la cible active n’est jamais envoyé comme bloc, il n’y a donc rien à rendre orphelin, rejeter ou cacher.

Pourquoi mon share a-t-il dépassé la difficulté du réseau sans trouver de bloc ?

Un mineur solo sur DigiByte nous a envoyé un signalement soigneux et bien documenté. Son mineur avait produit un share d’environ 997 millions de difficulté. Un rapport de minage généré environ une heure plus tard affichait une difficulté réseau de 531 millions — ce qui faisait du share presque le double de la cible. Pourtant, aucun bloc n’était apparu. Il avait consulté l’API du pool, confirmé que le share avait été reçu et accepté, et n’avait trouvé aucune trace de rejet ni de share obsolète. D’après chaque chiffre qu’il pouvait voir, cela aurait dû être un bloc.

Les chiffres qu’il pouvait voir étaient réels. C’étaient aussi les mauvais chiffres.

Nous avons retrouvé le share dans les logs du pool. Il est arrivé entre 06:26:31 et 06:27:31 UTC le 4 octobre 2026. Pendant cette minute, le réseau n’exigeait pas 531 millions. Il exigeait de 1,13 à 1,21 milliard. Le share a atteint entre 82,7% et 88,1% de ce qui était nécessaire.

Le chiffre de 531 millions correspondait à la difficulté une heure plus tard, une fois le pic retombé. Et à partir de 06:28:37 — une à deux minutes après l’arrivée du share — la cible est passée sous les 997 millions. Le même share, une ou deux minutes plus tard, aurait été un bloc.

Pourquoi la difficulté de DigiByte bouge-t-elle autant ?

DigiByte répartit la production de blocs entre cinq algorithmes de minage indépendants — SHA-256, Scrypt, Skein, Qubit et Odocrypt — chacun minant environ un bloc sur cinq, chacun avec sa propre difficulté. La chaîne vise un bloc toutes les 15 secondes au total, si bien que la voie SHA-256 produit en moyenne un bloc toutes les 75 secondes.

La difficulté de chaque voie est gérée par MultiShield, l’extension multi-algorithme de DigiShield que DigiByte a introduite en 2014. Là où Bitcoin réajuste une fois tous les 2 016 blocs, MultiShield recalcule la difficulté à chaque bloc.

Le détail qui surprend les mineurs, c’est qu’il recalcule toutes les voies à chaque bloc, pas seulement celle qui l’a trouvé. Le code de consensus de DigiByte le dit explicitement, dans un commentaire au-dessus des paramètres de difficulté : la difficulté d’un algorithme peut baisser quand un algorithme différent résout un bloc. La cible SHA-256 ne reste donc pas immobile entre deux blocs SHA-256. Chaque bloc trouvé sur Scrypt, Skein, Qubit ou Odocrypt la déplace aussi, et le résultat est une cible qui change environ toutes les 15 secondes. Notre explication de DigiByte couvre l’algorithme complet, lu directement dans le code de consensus.

Qu’a réellement fait la cible pendant cette minute ?

Chaque fois qu’un nouveau bloc arrive, le pool construit un nouveau job de minage et enregistre la cible que ce job doit atteindre. Voici les valeurs exactes enregistrées par les logs du pool autour du share :

Le share est arrivé entre 06:26:31 et 06:27:31, alors que la cible était à 1 205 245 749 puis à 1 130 849 418. À 996 739 624, il a atteint entre 82,7% et 88,1% de l’exigence. La cible est passée pour la première fois sous le share à 06:28:37.

Ce qui a provoqué cette vague devient clair une fois qu’on ajoute les blocs SHA-256 que la chaîne a réellement produits dans la même fenêtre :

Trois blocs SHA-256 sont arrivés en 99 secondes — un toutes les 33 secondes, contre un rythme attendu d’un toutes les 75. La voie SHA-256 avait nettement pris de l’avance sur les quatre autres, et MultiShield a relevé sa difficulté en réponse, jusqu’à un pic de 1,31 milliard. Puis aucun bloc SHA-256 n’est arrivé pendant quatre minutes et vingt-quatre secondes. À mesure que des blocs arrivaient sur les autres algorithmes, la cible est redescendue, marche après marche. Le share est arrivé juste après la crête, alors que la cible était encore en train d’en redescendre.

Les valeurs enregistrées sont l’exigence réelle du réseau, pas une estimation. Chacun des quatre blocs SHA-256 ci-dessus a été miné exactement à la cible que le pool avait enregistrée quelques instants plus tôt, à l’unité près. Tous les quatre sont vérifiables publiquement sur n’importe quel explorateur DigiByte.

Pourquoi la difficulté du rapport ne correspondait-elle pas à la cible ?

Parce que le rapport a capturé un moment une heure plus tard, et sur DigiByte, une heure, c’est long.

Toute valeur de difficulté que vous regardez — sur un explorateur, un tableau de bord de pool, un rapport de minage ou un calculateur de rentabilité — est la valeur à l’instant où elle a été lue. Sur Bitcoin, cette valeur tient deux semaines. Sur DigiByte, la cible SHA-256 est recalculée chaque fois que l’un des cinq algorithmes trouve un bloc, donc une valeur relevée à 07:34 ne dit presque rien de ce qui était exigé à 06:27.

Sur les quatre-vingt-dix minutes autour de ce share, la difficulté des blocs SHA-256 sur la chaîne est allée d’environ 418 millions à 1,12 milliard — un facteur 2,7. Un share de 997 millions était largement un bloc en bas de cette fourchette et largement insuffisant en haut.

Il y a un autre piège. Les explorateurs publient la difficulté de chaque bloc tel qu’il a été miné — la valeur qui s’appliquait au gagnant. Il n’existe aucun registre public de la cible en vigueur dans les secondes entre deux blocs. La cible la plus haute du log ci-dessus, 1,31 milliard, n’apparaît sur aucun explorateur, parce qu’aucun bloc SHA-256 n’a été miné pendant qu’elle était en vigueur. Et pourtant, c’est précisément dans un tel moment que surviennent les quasi-réussites.

Pourquoi la cible peut-elle sauter au-delà de la limite de 8% de MultiShield ?

Notre explication de DigiByte indique que MultiShield borne son retarget : la difficulté peut chuter jusqu’à 16% en un pas mais monter au plus de 8%. Pourtant, après chacun des trois blocs SHA-256 rapides de cette fenêtre, la cible a grimpé de plus de 20% — de 22,9%, 22,7% et 21,7%.

Les deux faits ne se contredisent pas, car MultiShield déplace une voie de deux façons distinctes. Les bornes de 8% et 16% limitent le retarget moyenné de la voie elle-même. S’y ajoute un ajustement par algorithme de 4% qui déplace la voie selon qu’elle est en retard ou en avance sur les quatre autres.

Dans cette fenêtre, le second mécanisme a produit un net motif en dents de scie. Chaque bloc sur un autre algorithme a abaissé la cible SHA-256 d’environ 4–5%. Chaque bloc SHA-256, arrivé alors que la voie était déjà en avance, l’a de nouveau propulsée vers le haut. Relisez le log des cibles avec cela en tête et le motif est sans équivoque : trois grandes marches vers le haut, chacune après un bloc SHA-256, puis un long escalier vers le bas.

En quoi est-ce différent du Real-Time Targeting d’eCash ?

Le symptôme est identique — un share dépasse la difficulté publiée et ne gagne rien — mais pas le mécanisme.

Sur eCash, le sort d’un share dépend du temps écoulé depuis le dernier bloc ; nous l’avons documenté en détail dans eCash RTT : pourquoi votre share solo n’était pas un bloc. Sur DigiByte, il dépend de l’endroit où se trouvait la cible SHA-256 après le bloc le plus récent sur n’importe quel algorithme. Les deux produisent des quasi-réussites qui, du côté du mineur, ressemblent exactement à un bloc manqué.

Cela arrive-t-il sur Bitcoin ou les autres chaînes SHA-256 ?

Pas sous cette forme. Sur la plupart des chaînes SHA-256, la cible reste fixe pendant toute la durée d’un intervalle de bloc et ne change que lorsque cette chaîne trouve son bloc suivant.

Sur Bitcoin et Bitcoin Cash, la difficulté que vous consultez est celle que vous deviez battre. Sur DigiByte, la cible qui a tranché le sort de votre share n’a existé que quelques secondes et n’a jamais été publiée nulle part.

Le bloc a-t-il été perdu, rendu orphelin ou caché ?

Non — parce qu’il n’y a jamais eu de bloc.

Le pool enregistre un événement de résolution de bloc chaque fois qu’un share atteint la cible réseau de son job. Pour ce share, il n’y en a eu aucun. Le pool l’a évalué par rapport à la cible active, l’a trouvé insuffisant et l’a accepté comme un share ordinaire. Aucun bloc n’a été assemblé, aucun appel submitblock n’a été effectué et rien n’a été envoyé au réseau. Il n’y avait rien à rendre orphelin, à rejeter ou à perdre.

Sur un pool non custodial, cela se vérifie de l’extérieur. L’adresse de paiement du mineur est inscrite dans la transaction coinbase du modèle de bloc avant le début du hachage, donc tout bloc réel apparaît on-chain au nom du mineur, de façon permanente. Un share qui n’est jamais devenu un bloc ne laisse aucune trace de ce genre — et un bloc réel ne pourrait pas être caché s’il avait existé.

Que doit réellement faire un mineur solo sur DigiByte ?

Presque rien — mais lisez correctement vos chiffres.

• Considérez toute valeur de difficulté comme un instantané. Un best share au-dessus de la difficulté sur votre tableau de bord ou dans le rapport n’est pas la preuve d’un bloc manqué. C’est la preuve que la cible était plus haute quand votre share est arrivé.
• Le best share affiché par le mineur est calculé localement. Les mineurs enregistrent la difficulté d’un hash à l’instant où ils le trouvent, avant que le pool ait répondu, et conservent souvent une valeur historique qui ne se réinitialise jamais. Elle vous dit que votre matériel a eu un bon moment, pas si ce moment était gagnant.
• Laissez le vardiff gérer la difficulté des shares. DigiByte réajuste à chaque bloc, donc une difficulté fixe des shares adaptée à une heure peut être fausse l’heure suivante. Notre guide de configuration DigiByte couvre le réglage.
• Gardez une latence faible. Sur une chaîne à 15 secondes, un serveur proche réduit l’écart entre l’apparition d’un nouveau job et le moment où votre mineur y travaille.
• Vérifiez la coinbase, pas le compteur. Pour savoir si vous avez trouvé un bloc, cherchez votre adresse dans une transaction coinbase on-chain.

Rien de tout cela ne change vos chances à long terme. Les variations se compensent avec le temps, c’est pourquoi une probabilité fondée sur la difficulté moyenne — comme dans notre calculateur de probabilités solo — reste la bonne base pour vos attentes. Les variations décident seulement quelles quasi-réussites deviennent des blocs.

Sources

• Paramètres de consensus de DigiByte Core — la note indiquant que la difficulté est mise à jour pour chaque algorithme à chaque bloc, et les constantes MultiShield nMaxAdjustUpV4 = 8, nMaxAdjustDownV4 = 16 et nLocalTargetAdjustment = 4
• DigiByte Core — pow.cpp, l’ajustement de difficulté MultiShield (GetNextWorkRequiredV4)
• DigiByte (DGB) expliqué pour les mineurs — notre profil complet de MultiShield, lu directement dans le code de consensus
• Measuring expected block timing for Difficulty Adjustment — Josiah Spackman sur MultiShield et le retarget à chaque bloc

Les valeurs de cible de cet article proviennent des logs du pool du 4 octobre 2026, enregistrées chaque fois qu’un nouveau job de minage était construit. Les quatre blocs SHA-256 minés dans la fenêtre — 24 323 739, 24 323 740, 24 323 742 et 24 323 752 — correspondent exactement à la cible que le pool avait enregistrée quelques instants avant chacun d’eux, ce qui confirme que les valeurs enregistrées sont l’exigence réelle du réseau. Toutes les difficultés de bloc citées sont vérifiables publiquement sur n’importe quel explorateur DigiByte.