Der Skandal um OCEAN und BIP-110: Was uns die Geschichte der Hashrate eines anderen auf der Fork-Chain lehrt

Kurz gesagt: Anfang August 2026 stellten einige der mit dem OCEAN-Pool verbundenen Miner fest, dass ihre Ausrüstung etwa 18 Stunden lang Blöcke auf der Gabelkette des BIP-110-Soft-Forks abbaute, obwohl die Miner selbst diesen Soft-Fork nicht unterstützten. OCEAN hat das Problem öffentlich anerkannt. Der Grund dafür ist, dass die Standard-Stratum-Vorlage des Pools „für“ BIP-110 signalisierte und einige der Miner, die alternative Vorlagen ohne Signal wählten, dennoch an die Fork-Kette gebunden waren. Die Geschichte wirft Fragen auf, die weit über nur einen Pool hinausgehen: Wie viel Kontrolle hat ein Miner darüber, was seine Hashrate signalisiert, und worauf man bei der Auswahl eines Pools achten muss, um nicht in eine ähnliche Situation zu geraten.

POOL BTC untersucht diesen Fall nicht, um ein Urteil über einen bestimmten Pool zu fällen, sondern um daraus eine praktische Lehre für diejenigen zu ziehen, die entscheiden, wo sie ihre Hashrate verteilen möchten. Wir erzählen nur das nach, was von OCEAN selbst und unabhängigen Quellen bestätigt wird, ohne Spekulationen über die Gründe und ohne Schuldbeurteilung.

Was geschah: sachliche Chronologie

Der BIP-110 Soft Fork trat bei Block 961632 in das obligatorische Signalisierungsfenster ein. Zu diesem Zeitpunkt wurde er von etwa 2,6 % der Netzwerk-Hashrate mit dem erforderlichen Schwellenwert von 55 % unterstützt. Eine solche Lücke reicht aus, damit der Fork keine Chance hatte, aktiviert zu werden, aber die Signalmechanismen selbst führten dennoch zur Entstehung einer separaten Fork-Kette: Blöcke, die das erforderliche Signal gemäß den BIP-110-Regeln nicht empfingen, gingen zu einem Zweig, der Rest zu einem anderen.

Die Fork-Kette schaffte es, nur zwei Blöcke zu produzieren, 961.632 und 961.633, und blieb dort stehen. Die Hauptkette rückte inzwischen um mehr als 200 Blöcke vor, das heißt, der überwiegende Teil des Netzwerks funktionierte weiterhin, als ob die Gabelkette nicht existierte.

Der zweite Block der Gabelkette, 961.634, wurde von der Simple Mining-Gruppe über das DATUM-Protokoll des Ocean-Pools abgebaut. Ein bezeichnendes Detail: Simple Mining betrieb das Mining über DATUM ohne das BIP-110-Signal, obwohl der Ocean-Pool selbst standardmäßig „für“ diesen Soft Fork signalisierte. Dies wird durch die CoinDesk-Quelle bestätigt: Bitcoin Miner lehnt BIP-110 ab, obwohl Mining über einen Pool unterstützt wurde Es.

Der Hauptpunkt der Geschichte liegt woanders. OCEAN gab zu, dass ein Teil der Miner, die Nicht-BIP-110-Stratum-Vorlagen wählten und sich technisch weigerten, für den Fork zu signalisieren, etwa 18 Stunden lang tatsächlich ohne ihre Zustimmung Blöcke auf der Fork-Kette schürften. Laut BeInCrypto forderte die Community daraufhin den Rücktritt des Poolmanagements und Adam Back bezeichnete den Vorfall öffentlich als inakzeptabel. Die Roughnecks-Gruppe, die beide Blöcke der Fork-Kette abgebaut hatte, gab ihre weitere Unterstützung am 9. August auf, woraufhin die OCEAN-Hashrate stark zurückging. Quelle: Bitcoin-Miner fordern Ocean Leadership-Entlassung wegen BIP-110.

Warum ist das überhaupt technisch möglich

Der Kern des Problems liegt nicht in der Tatsache, dass mehrere Stratum-Vorlagen vorhanden sind, sondern darin, dass die Hashrate des Miners physisch in dem Moment gesteuert wird, in dem der Pool oder das Protokoll Aufgaben wechselt oder weiterleitet. Der Miner sieht nur die Vorlage, die ihm gerade zugesandt wurde, und hat normalerweise keine einfache Möglichkeit, in Echtzeit zu überprüfen, zu welcher Kette der gefundene Block letztendlich wechselt, wenn sich das interne Routing des Pools nicht wie erwartet verhält.

Im Fall von OCEAN wurde die Situation durch die Tatsache erschwert, dass der Pool den Minern die Wahl bot: Signal für BIP-110 über die Standardvorlage oder wählen Sie eine alternative Stratum-Vorlage ohne ein solches Signal. Allein die Tatsache der Wahl sollte abweichende Bergleute davon abhalten, sich an der Abspaltung zu beteiligen. Nach Angaben des Pools schützte dies in der Praxis nicht alle: Ein Teil der Hashrate, die nominell den Nicht-BIP-110-Pfad wählte, landete dennoch etwa 18 Stunden lang in der Fork-Kette.

Hier ist eine allgemeinere Schlussfolgerung, die nicht von den Details eines bestimmten Vorfalls abhängt. Das Vorhandensein einer Auswahloption in der Poolschnittstelle garantiert nicht, dass die Auswahl auf allen Ebenen der Verkehrsweiterleitung technisch erzwungen wird. Der Unterschied zwischen „ein Pool bietet eine Auswahl“ und „ein Pool garantiert technisch die Thread-Isolation“ ist von außen möglicherweise erst dann erkennbar, wenn ein Fehler auftritt.

Die Rolle des DATUM-Protokolls in dieser Geschichte

Besonderes Augenmerk wird auf die Tatsache gelegt, dass Block 961 634 auf der Fork-Chain vom Simple Mining-Team über das DATUM-Protokoll des Ocean-Pools abgebaut wurde, ohne das BIP-110-Signal, obwohl der Pool selbst standardmäßig „für“ signalisierte. Dies bedeutet, dass Miner, die DATUM verwenden, die technische Möglichkeit hatten, die Blockvorlage und ihre Signalisierung unabhängig von der Standard-Pool-Richtlinie zu konfigurieren.

DATUM steht in diesem Sinne im Geiste der Idee der dezentralen Blockkonstruktion nahe, über die POOL BTC in der Analyse von Stratum V2 und Job Declaration im Abschnitt Pool-Vergleiche ausführlich geschrieben hat: Je mehr die Entscheidung über den Inhalt und die Signalisierung des Blocks auf der Seite bleibt Die Miner-Seite wird nicht vollständig an den Pool delegiert, desto weniger ist der Miner in kontroversen Situationen wie der Aktivierung eines Soft Forks von den Standardeinstellungen des Pools abhängig.

Aber auch diese Anpassungsoption hat nicht vollständig gerettet. Der Vorfall mit der 18-stündigen Bindung einiger abweichender Bergleute an die Fork Chain ereignete sich parallel zu der Tatsache, dass ein Teil der Gemeinschaft grundsätzlich über die technische Möglichkeit verfügte, zu wählen. Ein fortschrittliches Protokoll verringert das Risiko, beseitigt es jedoch nicht vollständig, wenn die Weiterleitung des Datenverkehrs innerhalb des Pools nicht transparent genug ist.

Was bedeutet das für die Auswahl eines Pools: Fragen vor der Verbindung

Die Geschichte mit OCEAN und BIP-110 ist kein Grund, eine Schlussfolgerung über die Fehlerhaftigkeit eines bestimmten Pools zu ziehen. Dies ist ein Grund, eine Liste von Fragen zu formulieren, die jedem Pool gestellt werden sollten, bevor Hashrate dorthin gesendet wird, insbesondere in Zeiten kontroverser Protokollaktualisierungen wie der Aktivierung von Soft Forks.

Es lohnt sich zu verstehen, welche Stratum-Vorlagen verfügbar sind und wie sie sich standardmäßig unterscheiden: Wenn der Pool mehrere Verbindungsoptionen bietet, informieren Sie sich im Voraus, welche Signalisierung in der Standardvorlage enthalten ist und was in der Konfiguration geändert werden muss, um eine andere zu erhalten. Überprüfen Sie separat, ob der Pool die technische Isolierung von Miner-Flüssen mit unterschiedlichen Einstellungen gewährleistet, denn die Auswahl besteht nicht nur in der Schnittstelle, sondern es ist auch wichtig zu verstehen, ob der Datenverkehr von Minern mit unterschiedlichen Mustern tatsächlich separat auf der Ebene der Pool-Infrastruktur weitergeleitet wird. Es ist nützlich herauszufinden, ob der Pool Protokolle wie DATUM oder Stratum V2 mit Job Declaration unterstützt, denn je mehr Kontrolle ein Miner über den Inhalt und die Signalisierung eines Blocks haben kann, desto weniger ist er von den Standardentscheidungen des Pools abhängig.

Es lohnt sich auch, einen Blick darauf zu werfen, wie der Pool kontroverse Protokollaktualisierungen im Voraus kommuniziert. Durch die öffentliche und frühzeitige Bekanntgabe der Position des Pools zu einem bestimmten Soft Fork und dessen Auswirkungen auf verschiedene Kategorien von Minern verringert sich das Risiko von Überraschungen zum Zeitpunkt der Aktivierung. Und schließlich ist es sinnvoll zu prüfen, wie der Pool nach dem Vorfall reagiert: Die Anerkennung des Problems, eine öffentliche Erläuterung der Gründe und eine technische Korrektur sprechen viel mehr für die Bereitschaft des Pools, gegenüber der Community Rechenschaft abzulegen als Schweigen oder vage Formulierungen.

Bei der Auswahl eines Zahlungsschemas sollten ähnliche Kriterien berücksichtigt werden, über die POOL BTC in einen vollständigen Leitfaden zu Zahlungsschemata für geschrieben hat Mining-Pools von PPS bis PPS TIDES: Je transparenter der Pool seine eigene Mechanik erklärt, desto weniger Überraschungen erwarten den Miner später.

Was sollte ein Miner jetzt tun?

Wenn das Thema Protokollaktualisierungen und Traffic-Routing für Sie nicht abstrakt, aber in der Praxis wichtig ist, sollten Sie Folgendes beachten.

Überprüfen Sie die aktuellen Stratum-Vorlagen und Pool-Signalisierungseinstellungen, bevor Sie eine Verbindung herstellen, insbesondere in Zeiten aktiver Diskussionen über Soft Forks in der Community. Bevorzugen Sie Pools, die ihre Position zu umstrittenen Protokolländerungen im Voraus öffentlich darlegen, anstatt sie erst nach dem Vorfall von Ihnen zu erfahren. Erwägen Sie Protokolle mit erweiterter Kontrolle auf Miner-Seite, wie z. B. DATUM oder Stratum V2 mit Job-Deklaration, um die Abhängigkeit von Standard-Pool-Einstellungen zu verringern. Überwachen Sie die Reputationssignale der Community: Öffentliche Forderungen der Community oder Kommentare prominenter Branchenvertreter erscheinen oft schneller als die offiziellen Postmortems des Pools.

Wenn Sie die Hashrate auf mehrere Pools verteilen, ist der OCEAN-Vorfall ein weiterer Grund, ihre Ansätze zur Transparenz der Verkehrsführung zu vergleichen, und nicht nur die Provision. Es ist praktisch, einen Vergleich von Pools basierend auf Schlüsselparametern im Abschnitt Vergleich von POOL-BTC-Pools anzuzeigen. Für diejenigen, die im Voraus abschätzen möchten, wie sich eine Änderung des Pools oder seiner Richtlinien auf das Einkommen auswirken wird, ist es nützlich, einen Mining-Rentabilitätsrechner zur Hand zu haben, und für Karteninhaber, die Belohnungen abheben möchten, ist eine Überprüfung der Kryptokarten im Bereich POOL BTC hilfreich.

Häufig gestellte Fragen

Bedeutet dieser Vorfall, dass OCEAN böswillig gehandelt hat?

Nein, die verfügbaren Quellen geben eine solche Aussage nicht ab. OCEAN hat das Problem öffentlich anerkannt, und Persönlichkeiten aus Community und Industrie wie Adam Back haben den Vorfall als inakzeptabel bezeichnet, aber hier geht es um die Folgen des Vorfalls, nicht um die nachgewiesene Absicht. POOL BTC erzählt nur bestätigte Fakten und zieht keine Schlussfolgerungen über Gründe, die über die Angaben der Quellen selbst hinausgehen.

Was ist am Ende mit der BIP-110-Fork-Kette passiert?

Die Fork-Kette produzierte nur zwei Blöcke, 961.632 und 961.633, und stoppte, während die Hauptkette mehr als 200 Blöcke vorne lag. Mit der Unterstützung von nur etwa 2,6 % der Hashrate gegenüber den erforderlichen 55 % hatte der Fork zunächst keine Chance auf Aktivierung.

Wie kann ich nachvollziehen, dass meine Hashrate nicht in einem anderen Pool in eine ähnliche Situation geraten wird?

Es gibt keinen direkten universellen Test, sondern prüft die verfügbaren Stratum-Vorlagen, fragt den Pool-Support direkt nach der technischen Isolierung des Datenverkehrs und bevorzugt Protokolle mit erweiterter Kontrolle auf Miner-Seite, wie z B. DATUM oder Stratum V2, verringern die Wahrscheinlichkeit eines solchen Szenarios.

Haftungsausschluss

Das Material dient nur zu Informationszwecken und basiert auf Daten, die von CoinDesk und BeInCrypto mit Stand vom 10. August 2026 veröffentlicht wurden. POOL BTC ist eine unabhängige Pool-, Rechner- und Service-Vergleichsseite und ist nicht mit OCEAN Pool verbunden. Die Situation im Zusammenhang mit dem Vorfall kann sich weiterentwickeln. Wir empfehlen Ihnen daher, die aktuellen offiziellen Stellungnahmen von OCEAN und unabhängige Quellen zu konsultieren, bevor Sie Entscheidungen treffen.