Block Withholding Attack

Un Mining Pool regroupe le travail de mineurs et partage les récompenses suivant des règles convenues. Il ne peut pas attendre que chaque petit participant trouve un bloc entier. Comme l’explique le Bitcoin Developer Guide, il utilise des shares : des résultats satisfaisant une condition plus facile, qui attestent régulièrement du travail fourni. Un résultat rare satisfait aussi la condition plus exigeante du réseau Bitcoin. L’attaquant transmet les shares ordinaires, mais écarte cette découverte plus précieuse. Sa machine calcule réellement et consomme de l’électricité ; elle ne simule pas gratuitement du minage. [3]

Cela dépend du modèle de paiement. Meni Rosenfeld distingue Pay Per Share (PPS), où l’opérateur paie les shares acceptées, et Pay Per Last N Shares (PPLNS), où les récompenses effectivement obtenues sont partagées selon les shares récemment acceptées dans une plage définie. Avec PPS, l’opérateur supporte donc le manque à gagner des blocs absents s’il respecte les paiements promis. Avec PPLNS, il reste moins d’argent pour les participants, attaquant compris. Une même découverte écartée peut ainsi toucher des personnes différentes. Ce sont les règles précises du pool qui comptent, pas l’étiquette « minage » du tableau de bord. [1]

Écarter des découvertes peut constituer un sabotage coûteux. L’attaquant paie matériel et électricité tout en renonçant à des revenus qu’il aurait pu obtenir honnêtement. Ittay Eyal étudie aussi un cas plus complexe : un pool concurrent consacre une partie de sa puissance au minage honnête et une autre à l’attaque d’un autre pool. Sous certaines hypothèses, cette répartition peut accroître ses revenus totaux. Un résultat mathématique ne promet pourtant pas un bénéfice après tous les coûts. La perte de la victime ne prouve pas que l’opération enrichit l’attaquant. [2]

Dans les deux cas, un bloc reste non publié, mais son sort diffère. Eyal et Emin Gün Sirer décrivent Selfish Mining comme un minage sur une branche privée de la chaîne dont les blocs sont publiés au moment jugé favorable. L’attaquant veut imposer sa branche et en recevoir les récompenses. À l’inverse, le Block Withholding Attack classique au sein d’un pool écarte les blocs trouvés ; il n’exige pas de construire une branche privée gagnante. D’autres variantes retardent seulement la remise du bloc. Il faut donc identifier la stratégie précise étudiée par une analyse. [4]

Prenons une période pendant laquelle un mineur honnête trouverait en moyenne 1 bloc compte tenu de sa puissance et de la difficulté. Le modèle de Poisson, également utilisé par Rosenfeld, décrit des découvertes aléatoires indépendantes à un rythme attendu constant. Il donne environ 37% de chances de n’en trouver aucun. Pour 3 blocs attendus, cette probabilité est proche de 5%. Ce n’est pas une probabilité de culpabilité : on calcule un résultat nul en supposant le minage honnête, pas la probabilité de fraude après avoir observé ce résultat. L’exemple suppose des conditions stables adaptées et une période fixée à l’avance. Une moyenne n’est pas une échéance obligatoire. [1]

Eyal souligne combien il est difficile d’attribuer une attaque à un petit mineur précis. Un compte sans bloc découvert ne suffit pas. Il faut comparer les shares acceptées aux blocs sur la même période, en tenant compte de leur difficulté, donc du travail qu’elles représentent. Hashrate désigne la vitesse de calcul ; son estimation à partir de ces preuves fluctue également. Il faut aussi vérifier les interruptions, les données manquantes et les changements de conditions. Un pool peut avoir matière à enquêter sans disposer de preuves suffisantes pour accuser quelqu’un. [2]

Eyal examine une prime au découvreur du bloc, la construction d’une réputation et des tâches de contrôle à solution connue. Chaque proposition modifie toutefois les conditions. La prime concentre davantage de récompense sur le découvreur et peut accentuer les fluctuations de revenus des petits mineurs. Les règles de réputation compliquent les changements de pool ; les tâches de contrôle demandent entretien et interprétation fiable. Il ne s’agit pas d’une protection universelle qu’on active simplement. L’opérateur doit évaluer effets et contreparties, puis expliquer ce que ses mesures peuvent réellement détecter. [2]

Le Bitcoin Developer Guide distingue la découverte d’un bloc de sa validation par le réseau. Cacher une découverte ne change aucune règle de validité des transactions et ne permet pas, à soi seul, de dépenser les coins d’autrui ou de réécrire l’historique confirmé. L’attaque nuit surtout à l’économie et à la confiance dans la coopération minière. Trois questions aident à garder le cap : qu’a-t-on caché, qui perd de l’argent selon les règles convenues et quelles preuves possède-t-on ? Cette description n’accuse aucun pool actuel. [3]