Vous
Politiques du pool

Rétention de blocs : l'attaque qu'un pool ne peut pas voir dans un seul share

Dernière mise à jour : 15 août 2026

Un mineur envoie de vrais shares et cache celui qui aurait été un bloc. Voici ce que cela coûte, qui le paie et comment on le détecte.

En quoi consiste l'attaque

Chaque share que vous envoyez à un pool est une vraie solution qui n'a pas atteint la cible du bloc. De temps en temps, une solution tombe aussi sous la cible du bloc, et ce share est un bloc entier. Il ressemble à n'importe quel autre share jusqu'au moment où le pool le vérifie.

Une attaque par rétention de blocs, c'est un mineur qui fait honnêtement le travail, envoie tous les shares normaux et jette discrètement celui qui aurait été un bloc. Le pool compte les shares et les paie. Le bloc qu'il aurait dû recevoir n'arrive jamais.

Pourquoi un share ne le trahit jamais

C'est ce qui rend l'attaque intéressante et pas seulement malveillante. Rien chez l'attaquant ne paraît anormal sur aucun share pris seul. Le matériel est réel, le hashrate est réel, les shares sont valides et arrivent au bon rythme. Le pool peut examiner un share et ne rien y voir du tout.

Ce qui manque est une absence, et une absence ne devient visible qu'avec le temps. Un mineur qui détient une certaine part du hashrate du pool devrait trouver à peu près la même part de ses blocs. Sur une heure, cela ne dit rien, car trouver des blocs est un processus aléatoire et les périodes sans bloc sont normales. Sur une fenêtre assez longue, cela en dit énormément.

Un mineur attaquant envoie un flux régulier de shares normaux à un pool, tandis que la seule solution qui atteint la cible du bloc s'arrête avant d'atteindre le pool et est jetée
Les shares circulent normalement. Le seul envoi qui comptait est jeté, et rien dans un share isolé ne le révèle.

Ce que cela coûte, et qui paie vraiment

Le pool perd la récompense de bloc qu'il aurait dû recevoir. Mais ce n'est pas vraiment sur le pool que tombe la perte, et c'est la partie à comprendre si vous minez dans n'importe quel pool.

Avec un mode proportionnel, la ronde continue simplement jusqu'à ce que quelqu'un d'autre trouve un bloc. Tous les participants de la ronde ont apporté du travail à une ronde qui a duré plus longtemps qu'il n'aurait dû, donc tous gagnent un peu moins par unité de travail. Le coût est réparti entre les mineurs honnêtes.

Avec un mode de paiement par share, c'est pire pour l'opérateur, car le pool a déjà payé chaque share de sa poche et compte sur l'arrivée des blocs. Une attaque prolongée contre un pool à paiement par share est une hémorragie directe pour l'opérateur, et historiquement c'est le cas qui a le plus inquiété.

Pourquoi quelqu'un ferait cela

L'attaquant jette aussi la récompense de bloc, donc à première vue c'est un pur sabotage de soi-même. Cela n'a de sens que si l'attaquant gagne quelque part où le pool ne peut pas voir.

Le motif habituel est la concurrence. Un opérateur qui gère son propre pool peut louer ou diriger du hashrate vers un rival, supprimer ses résultats et faire paraître son propre pool plus chanceux par comparaison. L'attaquant paie le sabotage avec les shares qu'il continue d'encaisser.

Il existe une variante plus subtile où l'attaquant garde le bloc au lieu de le jeter, continue de miner dessus en privé et l'envoie plus tard au moment qui l'arrange. Elle est plus difficile à mener et demande une grande part du hashrate pour valoir la peine d'être tentée.

Comment on la détecte en pratique

La détection est statistique, et doit l'être, car aucun autre signal n'est disponible. La mesure est simple à énoncer : comparer les blocs qu'un participant a trouvés avec les blocs que, selon son nombre de shares, il aurait dû trouver, sur une fenêtre assez longue pour que la chance s'équilibre.

La fenêtre est la partie difficile. Courte, la malchance normale ressemble à une attaque, ce qui reviendrait à accuser sans cesse des mineurs honnêtes. Longue, un véritable attaquant opère un moment avant que les chiffres ne parlent. Il n'existe aucune astuce pour éviter ce compromis ; c'est une propriété du hasard, pas du logiciel.

C'est pourquoi un détecteur sérieux soumet la question à une personne au lieu d'agir de lui-même. Un bannissement automatique guidé par une statistique finira par bannir quelqu'un qui a simplement eu de la malchance, et écarter un mineur légitime est un pire résultat que l'attaque elle-même.

Ce que cela signifie si vous êtes un mineur honnête

Presque rien, et c'est justement pourquoi il vaut la peine de le dire clairement.

Vos shares sont comptés et payés de la même façon dans tous les cas. Avoir de la malchance n'est pas une infraction et ne peut pas l'être, car sur n'importe quelle fenêtre courte la plupart des mineurs ont de la malchance. Une série de rondes où vous avez beaucoup apporté et où le pool n'a rien trouvé est une variance normale, et le chiffre de chance dans les statistiques du pool existe précisément pour vous montrer à quel point c'est normal.

La seule chose à savoir, c'est que c'est une raison pour laquelle les pools tiennent à savoir qui dirige du hashrate vers eux, et une raison pour laquelle un pool qui publie honnêtement ses blocs et sa chance inspire plus confiance qu'un pool qui ne le fait pas. Tout ce qu'il faut pour vérifier le pool se trouve sur la page Blocs.

Prêt à passer à la pratique ?
Le guide Comment miner choisit le serveur le plus proche de vous et génère la commande exacte pour votre logiciel de minage.
Commencer à miner Quantus