258 / 691BWH

Block Withholding Attack

Attaque par rétention de solutions de bloc

Block Withholding Attack nuit à un pool : un participant soumet des shares ordinaires mais retient les solutions de bloc valides. Un faible résultat ne prouve pas un sabotage ; volume de travail, hasard et autres preuves comptent.

Block Withholding Attack consiste à ne pas transmettre délibérément une solution de bloc trouvée tout en continuant les shares ordinaires. Il s’agit ici du rejet classique ; d’autres variantes retardent seulement le bloc et ont des incitations différentes.

Bitcoin Developer Guide décrit une cible plus facile pour les shares et une cible réseau plus stricte pour les blocs. Notre explication : l’attaquant calcule toujours et atteste du travail par les shares, mais le pool perd les rares solutions de bloc. Ce n’est pas du minage sans effort de calcul. [Bitcoin Developer Guide — Mining]

Rosenfeld distingue PPS et PPLNS. En PPS, si les paiements promis par share sont honorés, l’opérateur supporte les revenus de bloc manquants ; en PPLNS, les recettes moindres touchent aussi les participants, attaquant compris. Votre analyse doit suivre le régime de paiement précis. [Rosenfeld — Analysis of Bitcoin Pooled Mining Reward Systems]

Eyal distingue sabotage classique et infiltration entre pools avec une capacité supplémentaire minant honnêtement. La rentabilité de son modèle dépend de la répartition de puissance et du comportement des autres. Nous en déduisons que le dommage subi ne prouve pas un profit net de l’attaquant. [Eyal — The Miner’s Dilemma]

Eyal et Sirer analysent dans Selfish Mining la publication stratégique d’une branche privée. Le Block Withholding Attack classique contre un pool jette les solutions de bloc et n’exige pas de branche privée gagnante. Gardez ces mécanismes distincts dans votre description. [Eyal and Sirer — Majority is not Enough]

Rosenfeld modélise les découvertes par une loi de Poisson. Exemple propre à conditions constantes : pour 1 bloc attendu, la probabilité de zéro est environ 37% ; pour 3, environ 5%. Ce n’est pas une probabilité de culpabilité ; puissance, difficulté et période doivent convenir. [Rosenfeld — Analysis of Bitcoin Pooled Mining Reward Systems]

Eyal compare travail attesté par les shares et blocs réellement trouvés, et souligne la difficulté d’attribution à un petit mineur. Votre audit doit aligner périodes et pondération des shares par difficulté, puis vérifier coupures et erreurs de registre. Une faible statistique ne désigne pas un coupable. [Eyal — The Miner’s Dilemma]

Eyal examine primes de découverte, réputation et tâches de test ; une prime peut accroître la variance du revenu des petits mineurs. Évaluez détection et effets sur les participants honnêtes. Une proposition scientifique n’est pas une protection universelle à activer. [Eyal — The Miner’s Dilemma]

Bitcoin Developer Guide sépare travail du pool et acceptation réseau des blocs. Nous en déduisons qu’une solution non transmise ne réécrit pas les transactions confirmées et ne permet pas de dépenser les fonds d’autrui. Un modèle économique ne prouve pas non plus l’attaque d’un pool actuel précis. [Bitcoin Developer Guide — Mining]

Pour une vision complète, lisez aussi Mining Pool, Pay Per Last N Shares, Hashrate, Selfish mining.

DOC · 001Rosenfeld — Analysis of Bitcoin Pooled Mining Reward SystemsSource primaire ↗DOC · 002Eyal — The Miner’s DilemmaSource primaire ↗DOC · 003Bitcoin Developer Guide — MiningDocumentation ↗DOC · 004Eyal and Sirer — Majority is not EnoughSource primaire ↗
Sources d’abord · Pas un conseil financier