Le scandale autour d'OCEAN et du BIP-110 : ce que nous apprend l'histoire du hashrate de quelqu'un d'autre sur la chaîne de fourche
En bref : début août 2026, certains des mineurs connectés au pool OCEAN ont découvert que leur équipement minait des blocs sur la chaîne de fourche du soft fork BIP-110 pendant environ 18 heures, alors que les mineurs eux-mêmes ne supportaient pas ce soft fork. OCEAN a reconnu publiquement le problème. La raison en est que le modèle de strate par défaut du pool signalait « pour » BIP-110, et certains des mineurs qui ont choisi des modèles alternatifs sans signal se sont quand même retrouvés liés à la chaîne fork. L'histoire soulève des questions qui vont bien au-delà d'un seul pool : quel contrôle un mineur a-t-il sur ce que signale son hashrate, et que rechercher lors du choix d'un pool pour éviter de se retrouver dans une situation similaire.
POOL BTC examine ce cas non pas pour porter un jugement sur un pool particulier, mais pour en tirer une leçon pratique pour ceux qui choisissent où allouer leur hashrate. Nous ne rapportons que ce qui est confirmé par OCEAN lui-même et par des sources indépendantes, sans spéculer sur les raisons et sans évaluer la culpabilité.
Ce qui s'est passé : chronologie factuelle
Le soft fork BIP-110 est entré dans la fenêtre de signalisation obligatoire au niveau du bloc 961632. À ce stade, il était pris en charge par environ 2,6 % du hashrate du réseau avec le seuil requis de 55 %. Un tel écart est suffisant pour que la fourche n'ait pas eu la chance de s'activer, mais la mécanique de signalisation elle-même a quand même conduit à l'émergence d'une chaîne de fourche séparée : les blocs qui n'ont pas reçu le signal requis selon les règles BIP-110 sont allés dans une branche, le reste dans une autre.
La chaîne de fourche n'a réussi à produire que deux blocs, 961 632 et 961 633, et s'est arrêtée là. La chaîne principale, quant à elle, a avancé de plus de 200 blocs, c'est-à-dire que la grande majorité du réseau a continué à fonctionner comme si la chaîne fork n'existait pas.
Le deuxième bloc de la chaîne fork, 961 634, a été miné par le groupe Simple Mining via le protocole DATUM du pool Ocean. Un détail indicatif : Simple Mining exploitait via DATUM sans le signal BIP-110, bien que le pool Ocean lui-même ait signalé « pour » ce soft fork par défaut. Ceci est confirmé par la source CoinDesk : Bitcoin Miner rejette BIP-110 malgré l'exploitation minière via un pool pris en charge C'est.
Le point principal de l’histoire est ailleurs. OCEAN a admis que pendant environ 18 heures, une partie des mineurs qui ont choisi des modèles de strate non BIP-110 et ont techniquement refusé de signaler le fork exploitaient toujours des blocs sur la chaîne du fork sans leur consentement. Selon BeInCrypto, la communauté a alors exigé la démission de la direction du pool, et Adam Back a publiquement qualifié l'incident d'inacceptable. Le groupe Roughnecks, qui a exploité les deux blocs de la chaîne fork, a abandonné son support supplémentaire le 9 août, après quoi le hashrate OCEAN a fortement chuté. Source : Les mineurs de Bitcoin exigent que le leadership océanique tire sur le BIP-110.
Pourquoi est-ce techniquement possible
L'essence du problème n'est pas le fait même de l'existence de plusieurs modèles de strate, mais le fait que le hashrate du mineur est physiquement dirigé au moment où le pool ou le protocole change ou achemine les tâches. Le mineur ne voit que le modèle qui lui a été envoyé pour le moment et n'a généralement pas de moyen simple de vérifier en temps réel vers quelle chaîne le bloc trouvé ira finalement si le routage interne du pool ne se comporte pas comme prévu.
Dans le cas d'OCEAN, la situation était compliquée par le fait que le pool offrait aux mineurs le choix : signaler pour BIP-110 via le modèle par défaut ou choisir un modèle de strate alternatif sans un tel signal. Le fait même du choix était censé empêcher les mineurs dissidents de participer au fork. Selon le pool, dans la pratique, cela n'a pas protégé tout le monde : une partie du hashrate qui a nominalement choisi le chemin non-BIP-110 s'est quand même retrouvée sur la chaîne fork pendant environ 18 heures.
Voici une conclusion plus générale qui ne dépend pas des détails d'un incident spécifique. La présence d'une option de sélection dans l'interface du pool ne garantit pas que la sélection soit techniquement appliquée à tous les niveaux de routage du trafic. La différence entre « un pool offre un choix » et « un pool garantit techniquement l'isolation des threads » peut ne pas être perceptible de l'extérieur jusqu'à ce qu'une panne se produise.
Le rôle du protocole DATUM dans cette histoire
Une attention particulière est accordée au fait que le bloc 961 634 sur la chaîne fork a été miné par l'équipe Simple Mining via le protocole DATUM du pool Ocean, sans le signal BIP-110, malgré le fait que le pool lui-même a signalé « pour » par défaut. Cela signifie que les mineurs utilisant DATUM avaient la capacité technique de configurer indépendamment le modèle de bloc et sa signalisation séparément de la politique de pool par défaut.
DATUM, dans ce sens, est proche dans son esprit de l'idée de construction de bloc décentralisée, dont POOL BTC a parlé en détail dans l'analyse de Stratum V2 et de la déclaration de travail dans la section comparaisons de pool : plus la décision concernant le contenu et la signalisation du bloc appartient au Du côté du mineur, et pas complètement délégué au pool, moins le mineur dépend des paramètres par défaut du pool dans des situations controversées telles que l'activation d'un soft fork.
Mais même cette option de personnalisation n'a pas complètement sauvé. L'incident avec la liaison pendant 18 heures de certains mineurs dissidents à la chaîne à fourche s'est produit parallèlement au fait qu'une partie de la communauté avait en principe la capacité technique de choisir. Un protocole avancé réduit le risque, mais ne l'élimine pas complètement si le routage du trafic au sein du pool n'est pas suffisamment transparent.
Qu'est-ce que cela signifie pour le choix d'une piscine : questions avant de se connecter
L'histoire avec OCEAN et BIP-110 n'est pas une raison pour tirer une conclusion sur la faute d'une piscine en particulier. C'est une raison pour formuler une liste de questions qui devraient être posées à n'importe quel pool avant d'y envoyer du hashrate, en particulier pendant les périodes de mises à jour de protocole controversées telles que l'activation de soft forks.
Il convient de comprendre quels modèles de Stratum sont disponibles et en quoi ils diffèrent par défaut : si le pool propose plusieurs options de connexion, renseignez-vous à l'avance quelle signalisation est incluse dans le modèle par défaut et ce qui doit être modifié dans la configuration pour en obtenir un autre. Par ailleurs, vérifiez si le pool garantit l'isolation technique des flux de mineurs avec des paramètres différents, car non seulement le choix existe dans l'interface, mais il est important de comprendre si le trafic des mineurs avec des modèles différents est réellement acheminé séparément au niveau de l'infrastructure du pool. Il est utile de savoir si le pool supporte des protocoles comme DATUM ou Stratum V2 avec Job Déclaration, car plus un mineur peut avoir de contrôle sur le contenu et la signalisation d'un bloc, moins il est dépendant des décisions par défaut du pool.
Il vaut également la peine d'examiner la manière dont le pool communique à l'avance les mises à jour controversées du protocole. L'annonce publique et précoce de la position du pool sur un soft fork particulier et de la manière dont cela affectera différentes catégories de mineurs réduit le risque de surprises au moment de l'activation. Et enfin, il est logique de vérifier comment le pool réagit après l'incident : la reconnaissance du problème, une explication publique des raisons et une correction technique témoignent de la volonté du pool de rendre des comptes à la communauté bien plus que le silence ou le langage vague.
Un ensemble similaire de critères doit être gardé à l'esprit lors du choix d'un système de paiement, dont POOL BTC a parlé dans un guide complet des systèmes de paiement pour les pools miniers de PPS à PPS TIDES : plus la piscine explique ses propres mécanismes de manière transparente, moins de surprises attendent le mineur plus tard.
Que doit faire un mineur dès maintenant
Si le sujet des mises à jour de protocole et du routage du trafic n'est pas abstrait pour vous, mais est important dans la pratique, voici ce à quoi il faut prêter attention.
Vérifiez les modèles Stratum actuels et les paramètres de signalisation du pool avant de vous connecter, en particulier pendant les périodes de discussions actives sur les soft forks dans la communauté. Privilégiez les pools qui expliquent publiquement à l'avance leur position sur les changements controversés du protocole, plutôt que de vous en informer après l'incident. Envisagez des protocoles avec un contrôle avancé côté mineur, tels que DATUM ou Stratum V2 avec déclaration de travail, comme moyen de réduire la dépendance aux paramètres de pool par défaut. Surveillez les signaux de réputation de la communauté : les demandes publiques de la communauté ou les commentaires de personnalités éminentes de l'industrie apparaissent souvent plus rapidement que les post-mortems officiels du pool.
Si vous répartissez le hashrate entre plusieurs pools, l'incident OCEAN est une autre raison de comparer leurs approches en matière de transparence du routage du trafic, et pas seulement en matière de commission. Il est pratique de visualiser une comparaison des pools basée sur des paramètres clés dans la section comparaison des pools POOL BTC. Pour ceux qui souhaitent estimer à l'avance comment un changement dans le pool ou sa politique affectera les revenus, il est utile de garder un calculateur de rentabilité minière à portée de main, et pour que les titulaires de cartes puissent retirer des récompenses, un examen des cartes cryptographiques dans la section POOL BTC sera utile.
Questions fréquemment posées
Cet incident signifie-t-il qu'OCEAN a agi de manière malveillante ?
Non, les sources disponibles ne font pas une telle déclaration. OCEAN a publiquement reconnu le problème, et des personnalités de la communauté et de l'industrie comme Adam Back ont qualifié l'incident d'inacceptable, mais il s'agit ici des conséquences de l'incident et non d'une intention prouvée. POOL BTC ne rapporte que des faits confirmés et ne tire pas de conclusions sur des raisons allant au-delà de ce que les sources elles-mêmes ont dit.
Qu'est-il finalement arrivé à la chaîne fork BIP-110 ?
La chaîne fork n'a produit que deux blocs, 961 632 et 961 633, et s'est arrêtée alors que la chaîne principale était en avance de plus de 200 blocs. Avec le support d'environ 2,6 % seulement du hashrate contre les 55 % requis, le fork n'avait initialement aucune chance d'être activé.
Comment puis-je comprendre que mon hashrate ne se retrouvera pas dans une situation similaire sur un autre pool ?
Il n'y a pas de test universel direct, mais vérifier les modèles Stratum disponibles, interroger directement le support du pool sur l'isolation technique du trafic et préférer les protocoles avec contrôle étendu sur du côté des mineurs, tels que DATUM ou Stratum V2, réduisent la probabilité d'un tel scénario.
Avertissement
Le matériel est à titre informatif uniquement et est basé sur les données publiées par CoinDesk et BeInCrypto au 10 août 2026. POOL BTC est un site indépendant de comparaison de pools, de calculateurs et de services et n'est pas affilié à OCEAN Pool. La situation entourant l'incident peut évoluer, nous vous recommandons donc de consulter les déclarations officielles actuelles de l'OCEAN et les sources indépendantes avant de prendre une décision.