Rétention de blocs : l'attaque invisible dans un share
Un mineur envoie de vrais shares et cache celui qui aurait été un bloc. Ce que cela coûte, qui paie, pourquoi quelqu'un le fait et comment on le repère.
Qu'est-ce qu'une attaque par rétention de blocs ?
C'est un mineur qui envoie chaque share ordinaire mais cache celui qui aurait été un bloc. Le pool paie les shares. Le bloc n'arrive jamais.
Chaque share que vous envoyez à un pool est une vraie solution qui a manqué la cible du bloc. La cible du bloc est la barre plus haute qu'un hash doit franchir pour faire un bloc. De temps en temps, une solution la franchit aussi, et ce share est un bloc entier.
Un tel share ressemble à tous les autres jusqu'à ce que le pool le vérifie.
Un attaquant fait le travail honnêtement et envoie chaque share ordinaire. Il 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 seul share ne peut-il pas le trahir ?
Rien ne semble anormal chez l'attaquant sur un share isolé. Le matériel est réel, le hashrate aussi. Les shares sont valides et arrivent au bon rythme. Le pool peut examiner un share et ne rien voir du tout.
Ce qui manque est une absence, et une absence ne se voit qu'avec le temps. Un mineur qui a une certaine part du hashrate du pool devrait trouver à peu près cette part de ses blocs.
Sur une heure, cela ne dit rien. Trouver des blocs est aléatoire, et les périodes calmes sont normales. Sur une fenêtre assez longue, cela en dit beaucoup.
Combien cela coûte-t-il, et qui paie ?
Le pool perd la récompense de bloc qu'il aurait dû recevoir. Mais la perte ne retombe pas vraiment sur le pool. C'est la partie à comprendre, quel que soit le pool.
- Avec une méthode proportionnelle, la ronde continue jusqu'à ce que quelqu'un d'autre trouve un bloc. Tous ceux de la ronde ont travaillé sur une ronde plus longue qu'elle n'aurait dû l'être. Chacun gagne donc un peu moins par unité de travail. Le coût est réparti entre les mineurs honnêtes.
- Avec une méthode de paiement par share, c'est pire pour l'opérateur. Le pool a déjà payé chaque share de sa poche et compte sur l'arrivée des blocs. Une attaque prolongée vide directement les caisses de l'opérateur. Historiquement, c'est le cas qui inquiétait le plus.
Pourquoi quelqu'un ferait-il cela ?
L'attaquant jette lui aussi la récompense du bloc. À première vue, c'est se nuire à 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. Quelqu'un qui gère son propre pool peut louer du hashrate ou le diriger vers un rival et freiner ses résultats. Son propre pool paraît alors plus chanceux en comparaison. Les shares que l'attaquant continue d'encaisser financent le sabotage.
Dans une variante plus subtile, l'attaquant garde le bloc au lieu de le jeter. Il continue de miner dessus en privé, puis le soumet plus tard au moment qui l'arrange. C'est plus difficile à réussir. Il faut une grande part du hashrate pour que cela vaille la peine.
Comment la détecte-t-on ?
La détection est statistique, car il n'y a aucun autre signal. Comparez les blocs qu'un participant a trouvés avec ceux que son nombre de shares laisse attendre. Faites-le sur une fenêtre assez longue pour que la chance se compense.
La fenêtre est la partie difficile.
- Si elle est courte, la malchance ordinaire ressemble à une attaque. Des mineurs honnêtes seraient accusés sans cesse.
- Si elle est longue, un vrai attaquant opère un moment avant que les chiffres ne parlent.
Il n'existe aucune astuce pour éviter ce compromis. Il vient du hasard, pas du logiciel.
Un détecteur sérieux soumet donc la question à un humain au lieu d'agir seul. Un bannissement automatique fondé sur une statistique bannira un jour quelqu'un qui n'a fait qu'avoir de la malchance. Mettre hors ligne un mineur légitime est pire que l'attaque elle-même.
Qu'est-ce que cela change pour un mineur honnête ?
Presque rien, et cela 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 faute et ne peut pas l'être. Sur une fenêtre courte, la plupart des mineurs ont de la malchance.
Une série de rondes où vous avez beaucoup contribué sans que le pool trouve rien est une variance normale. Le chiffre de chance dans les statistiques du pool vous montre à quel point elle est normale.
Cette attaque est une des raisons pour lesquelles les pools font attention à qui dirige du hashrate vers eux. C'est aussi pourquoi il est plus facile de faire confiance à un pool qui publie honnêtement ses blocs et sa chance. Tout ce qu'il vous faut pour vérifier le pool est sur la page Blocs.