Backup-Pool und Failover: wozu der zweite und dritte Slot im ASIC gut sind

In fast jeder ASIC-Firmware gibt es drei Felder für die Pool-Adresse. Meist ist nur eines ausgefüllt. Das zweite und dritte bleiben leer oder enthalten dieselbe Adresse, was sie nutzlos macht. Das ist die billigste Versicherung im Mining: Die Einrichtung dauert fünf Minuten, kostet nichts und rettet vor Ausfallzeit, wenn der Hauptpool in die Knie geht.

Im Folgenden zerlegen wir die Umschaltmechanik, berechnen die Kosten des Stillstands mit unserer Formel und gehen separat auf einen Punkt ein, den kaum jemand erklärt: was mit Ihrem PPLNS-Beitrag passiert, wenn der Miner auf den Backup wechselt.

Was die drei Pool-Slots im ASIC sind

Die drei Slots bilden eine Prioritätsliste. Der Miner hält die Stratum-Verbindung zur ersten Adresse. Reißt die Verbindung ab oder liefert der Pool keine Aufgaben mehr, probiert die Firmware die zweite Adresse, dann die dritte. Mehr Intelligenz steckt nicht dahinter: Es ist ein sequenzielles Durchprobieren von oben nach unten, ohne Lastverteilung und ohne Aufteilung der Hashrate zwischen Pools.

Entscheidend beim Umschalten: Es geschieht nicht sofort. Der Miner muss erst feststellen, dass wirklich keine Verbindung besteht. Er wartet den Ablauf eines Timeouts ab, versucht manchmal mehrmals, sich mit der ersten Adresse neu zu verbinden, und wechselt erst danach zur nächsten. Die Dauer dieses Fensters hängt von Firmware und Version ab, einen einheitlichen Standard gibt es nicht. Den konkreten Wert finden Sie im Webinterface Ihres Geräts, im Bereich der Pool-Einstellungen, oder in den Logs: Dort sieht man, nach wie vielen Sekunden nach dem Abbruch der Miner begann, an der zweiten Adresse anzuklopfen.

Daraus ergibt sich eine praktische Schlussfolgerung. Failover schützt nicht vor kurzen Ausfällen von ein paar Sekunden. Er schützt vor Situationen, die Minuten bis Stunden dauern: Der Pool ist ausgefallen, hat DNS-Probleme, Ihr Provider hat die Route zu einem bestimmten Rechenzentrum verloren. Wie man ein Problem auf Pool-Seite von einem auf der eigenen Seite unterscheidet, wird ausführlich im Artikel Pool ist down: Schritt-für-Schritt-Diagnose erklärt.

Zweiter Punkt: Die meisten Firmwares kehren automatisch zum ersten Pool zurück, sobald dieser wiederhergestellt ist. Der Backup funktioniert also als temporäre Zwischenlösung, nicht als Umzug. Dieses Verhalten sollte man aber am eigenen Modell separat prüfen, da es ebenfalls von der Firmware abhängt.

Was eine Stunde Stillstand kostet

Wir rechnen von der Basisformel der erwarteten Förderung aus. Einnahme pro Zeitraum bei gegebener Hashrate:

```

BTC = H * 86400 * R / (D * 2^32)

```

wobei H die Hashrate in Hashes pro Sekunde ist, 86400 die Sekunden pro Tag, R die Blockbelohnung in BTC, D die Netzwerk-Difficulty. Die Formel liefert einen mathematischen Erwartungswert, keine Garantie: Bei kleinen Volumina schwankt die tatsächliche Förderung um diese Zahl herum.

Wir setzen das Netzwerk zum 08.09.2026 ein: Difficulty von 127,45 Billionen, Belohnung von 3,125 BTC, Netzwerk-Hashrate von 930,73 EH/s, Gebührenanteil im Block von 0,66 Prozent. Bei diesen Parametern liefern 100 TH/s 0,00004932 BTC pro Tag. Beim Kurs von 78.349 Dollar sind das 3,86 Dollar am Tag, also 16,1 Cent in der Stunde.

Weiter einfache Arithmetik nach Skalierung:

HashrateStunde StillstandTag StillstandMonat bei 1% Ausfall (ca. 7,3 h)Monat bei 5% Ausfall (ca. 36 h)
100 TH/s0,16 $3,86 $1,16 $5,80 $
1 PH/s1,61 $38,65 $11,60 $58 $
10 PH/s16,10 $386 $116 $580 $
100 PH/s161 $3865 $1160 $5800 $
Stillstand kostet mehr, als es scheint
Stillstand kostet mehr, als es scheint

Bei einem heimischen S21 misst sich der Unterschied zwischen 1 und 5 Prozent Stillstand im Monat in ein paar Dollar, und auf dieser Ebene ist Failover eher eine Frage der Hygiene als des Geldes. Bei zehn Petahash werden aus denselben Prozentsätzen hunderte Dollar im Monat, und die Einrichtung des zweiten Slots amortisiert sich schon beim ersten Ausfall. Eigene Zahlen können Sie über den Rentabilitätsrechner durchrechnen, indem Sie Ihre Hashrate und den Strompreis eintragen.

Es lohnt sich außerdem zu bedenken, dass Stillstand auch bei den Ausgaben nicht kostenlos ist: Die Hardware, die beim Pool im Down ist, verbraucht weiterhin Strom, wenn der Miner im Leerlauf dreht und versucht, sich neu zu verbinden.

Was mit dem PPLNS-Beitrag beim Wechsel auf den Backup passiert

Direkte Antwort: Bei PPLNS werden Ihre bereits eingereichten Shares beim Verbindungsabbruch nicht sofort nullgesetzt. Sie bleiben im Fenster und nehmen weiterhin an der Aufteilung der Blöcke teil, die der Pool demnächst findet, und werden dann allmählich durch neue Shares anderer Miner verdrängt. Ein kurzer Wechsel auf den Backup kostet deutlich weniger, als man gemeinhin denkt. Ein langer frisst den Beitrag komplett auf.

Die Mechanik ist folgende. PPLNS zahlt nicht für den Share an sich, sondern für den Anteil Ihrer Shares an den letzten N Shares des Pools zum Zeitpunkt des Blockfunds. Solange Ihre Shares innerhalb dieses Fensters liegen, bringt jeder gefundene Block einen Teil der Belohnung. Sobald der Strom fremder Shares Ihre über die Fenstergrenze hinausdrängt, zählen sie nicht mehr mit. Das ist keine Strafe und kein Verfall, sondern eine natürliche Verschiebung des Fensters.

Die Fenstergröße unterscheidet sich zwischen Pools, und auch die Formulierung. Nach unserer Auswertung der Dokumentation:

PoolWie das Fenster beschrieben wirdWas das in der Praxis bedeutet
ViaBTCletzte 5 Difficulty-Rundendas Fenster ist durch eine explizite Zahl gegeben, die Lebensdauer eines Shares lässt sich abschätzen
OceanTIDES-Schema, das Fenster entspricht 8 Netzwerk-Difficulties in Sharesdas am ausführlichsten dokumentierte Fenster überhaupt, Shares werden nie aus dem Log gelöscht, sie fallen nur aus dem Fenster heraus
AntPoolletzte N Difficulty-Rundendie Zahl N ist in der offiziellen Dokumentation nicht veröffentlicht, die Lebensdauer eines Shares lässt sich nicht genau abschätzen

Daraus ergibt sich eine praktische Regel: Je breiter das Fenster des Hauptpools, desto ruhiger lassen sich kurze Wechsel auf den Backup überstehen. Bei Ocean bedeutet ein Fenster von acht Netzwerk-Difficulties, dass ein Share im Schnitt mehrfach an der Aufteilung teilnimmt, und ein zehnminütiger Verbindungsausfall kostet fast nichts. Bei einem kurzen Fenster kostet derselbe Ausfall mehr.

Und umgekehrt: Ein mehrstündiger Wechsel auf den Backup bedeutet, dass zum Zeitpunkt der Rückkehr von Ihrem Beitrag im Fenster des Hauptpools fast nichts mehr übrig ist und die Ansammlung von vorn beginnt. Genau deshalb sind lange Ausfälle bei PPLNS schmerzhafter als bei PPS und FPPS, wo die Auszahlung nicht davon abhängt, ob der Pool einen Block gefunden hat.

Wichtiger Vorbehalt: Die meisten großen BTC-Pools arbeiten standardmäßig nicht mit PPLNS, sondern mit FPPS oder PPS+. Wenn Sie auf FPPS sind, betrifft Sie diese ganze Fenster-Arithmetik nicht, und der Wechsel auf den Backup kostet genau so viel, wie Sie während des Stillstands nicht geschürft haben, nicht mehr und nicht weniger.

Wie man einen Backup-Pool auswählt

Direkte Antwort: Wählen Sie einen Backup mit demselben Auszahlungsschema wie der Hauptpool, versuchen Sie aber nicht, einen Pool derselben Größe zu finden. Die Übereinstimmung des Schemas ist wichtig, weil davon abhängt, wie die Einnahme während des Stillstands berechnet wird und ob Sie sich innerhalb einer Woche mit zwei unterschiedlichen Auszahlungsmodellen auseinandersetzen müssen. Die Pool-Größe spielt dabei keine Rolle.

Warum das Schema wichtiger ist als die Größe. Wenn der Hauptpool auf FPPS läuft und der Backup auf PPLNS, beginnt jede Umschaltung, den Beitrag in einem fremden Fenster von null an aufzubauen, und bei der Rückkehr bleibt dieser Beitrag ungenutzt. Zudem ist der Abgleich der Reports schwieriger: Bei FPPS ist die Einnahme gleichmäßig, bei PPLNS an Blockfunde gebunden. Ein identisches Schema macht die beiden Plattformen vergleichbar.

Warum die Größe nicht kritisch ist. Die Pool-Hashrate beeinflusst die Varianz der Auszahlungen: Ein kleiner Pool findet Blöcke seltener, die Einnahme ist also unregelmäßiger. Aber der Backup läuft per Definition in kurzen Episoden. Über zwei Stunden Stillstand wird Ihnen die Varianz eines kleinen Pools nichts verderben, weil sie bei FPPS gar nicht existiert und der Beitrag über ein paar Stunden bei PPLNS ohnehin bescheiden ist.

Worauf man bei der Wahl des Backups wirklich achten sollte:

  1. Das Auszahlungsschema entspricht dem des Hauptpools.
  2. Die Auszahlungsschwelle ist erreichbar. Das ist die Hauptfalle, dazu unten mehr.
  3. Die Serverstandorte unterscheiden sich vom Hauptpool. Ein Backup im selben Rechenzentrum wie der Hauptpool rettet nicht vor einem Ausfall des Rechenzentrums.
  4. Die Registrierung erfordert keine wochenlange KYC-Prozedur, sonst lässt sich der Backup nicht schnell einrichten.
  5. Gebühr und Schwellen sind vorab bekannt. Vergleichen lassen sie sich pro Pool in unseren Analysen zu Gebühren und Mindestauszahlungen.

Ob sich ein Poolwechsel überhaupt lohnt und warum häufige Umzüge nicht kostenlos sind, dazu gibt es eine eigene Analyse: Der Preis des Poolwechsels.

Drei Pool-Slots hat jeder ASIC
Drei Pool-Slots hat jeder ASIC

Lohnt es sich, Solo oder einen anderen Pool in den dritten Slot zu setzen

Direkte Antwort: Der dritte Slot macht Sinn, wenn er keine Kopie des zweiten ist, sondern eine Absicherung gegen eine andere Ausfallklasse. Der zweite Slot deckt den Ausfall eines konkreten Pools ab. Der dritte soll die Situation abdecken, in der beide nicht erreichbar sind, etwa wegen eines Routing-Problems zu einer Region oder einer Sperre auf Provider-Seite.

Vernünftige Optionen für den dritten Slot:

  1. Ein Pool aus einer anderen Jurisdiktion mit anderer Netzwerkinfrastruktur. Die praktischste Wahl für die meisten.
  2. Ein Solo-Pool. Sinnvoll, wenn Sie grundsätzlich bereit sind, die meiste Zeit null Einnahme für die Lotteriechance auf einen Block in Kauf zu nehmen. Als Dauerbetrieb bei kleiner Hashrate ist das eine bewusste Wette, keine Kalkulation. Als dritter Slot, der nur an seltenen Ausfallstunden aktiviert wird, kostet Solo ungefähr den Preis eben jener Ausfallstunden aus der Tabelle oben.
  3. Derselbe Pool, aber eine andere Adresse seines Stratum-Endpoints in einer anderen Region. Das schützt vor einem regionalen Ausfall, aber nicht vor einem Ausfall des gesamten Pools.

Option 3 nutzen viele als zweiten Slot, und das ist nicht schlecht. Dann muss der dritte Slot aber zwingend ein fremder Pool sein, sonst hängt die gesamte Liste an einem einzigen Betreiber.

Typische Fehler bei der Failover-Einrichtung

  1. Dieselbe Adresse in allen drei Slots. Der häufigste Fall. Die Liste wirkt ausgefüllt, aber es gibt keinen Schutz: Fällt der Pool aus, fallen alle drei Einträge aus.
  2. Backup mit ungeprüftem Worker. Der Login wurde aus dem Gedächtnis eingetragen, mit einem Tippfehler oder für ein nicht existierendes Unterkonto. Solange der Hauptpool läuft, zeigt sich der Fehler nicht. Im Moment des Ausfalls wechselt der Miner und erhält eine Autorisierungsablehnung.
  3. Eine Auszahlungsschwelle, die Sie nie erreichen. Wenn der Backup erst ab einer Summe auszahlt, die Ihre Hashrate erst über Jahre seltener Ausfälle erreicht, sammelt sich das Geld einfach auf dem Guthaben. Bei manchen Pools verfällt der Restbetrag unter der Schwelle nicht und wartet auf den nächsten Zyklus, bei anderen gibt es aber Regeln zu inaktiven Konten und nicht gesetzten Auszahlungsadressen, bis hin zum Verlust der Rechte am Angesammelten gemäß Nutzungsbedingungen. Lesen Sie die Bedingungen des konkreten Pools, bevor Sie ihn als Backup einsetzen.
  4. Failover eingerichtet, aber nie getestet. Die ärgerlichste Kategorie, weil die Person überzeugt ist, geschützt zu sein.
  5. Backup mit derselben Auszahlungsadresse und derselben E-Mail wie der Hauptpool, ohne separate Zugangsprüfung. Verlieren Sie im Moment des Ausfalls den Zugang zum Konto, nützt der eingerichtete Slot wenig.
  6. Backup nur auf einem Teil der Geräte eingerichtet. In einer Farm mit dreißig ASICs garantiert die Einrichtung über eine Konfigurationsvorlage Einheitlichkeit, das manuelle Durchgehen Gerät für Gerät lässt fast immer Lücken.

Wie man prüft, ob der Failover funktioniert

Direkte Antwort: Prüfen muss man durch erzwungenen Verbindungsabbruch zum Hauptpool, nicht in der Theorie. Am sichersten ist es, vorübergehend die Reihenfolge der Slots zu ändern oder die Adresse des Hauptpools am Router zu sperren, zu beobachten, dass der Miner auf die zweite Adresse gewechselt ist und angenommene Shares abliefert, und dann alles wieder herzustellen.

Ablauf:

  1. Stellen Sie sicher, dass der Worker auf dem Backup-Pool angelegt und in dessen Dashboard sichtbar ist. Am einfachsten ist es, zehn Minuten lang einen Miner auf den Backup zu richten und zu sehen, dass beim Worker Hashrate erscheint.
  2. Notieren Sie den aktuellen Zustand: Adressen in allen drei Slots, Worker-Namen, aktuelle Hashrate am Hauptpool.
  3. Sperren Sie den Zugang zum Hauptpool. Optionen: eine Router-Regel nach Domain oder IP, das Abschalten eines bestimmten Ports, oder der vorübergehende Austausch der Adresse im ersten Slot gegen eine garantiert nicht funktionierende.
  4. Stoppen Sie die Zeit. Notieren Sie, nach wie vielen Sekunden der Miner zur zweiten Adresse gewechselt ist. Das ist Ihr realer Failover-Timeout, und genau diesen Wert sollten Sie bei der Einschätzung von Verlusten im Kopf haben.
  5. Prüfen Sie im Dashboard des Backup-Pools, dass die Shares des Workers ankommen und als gültig anerkannt werden. Das bloße Vorhandensein einer Verbindung reicht nicht.
  6. Heben Sie die Sperre auf und beobachten Sie, ob der Miner von selbst zum ersten Slot zurückkehrt. Wenn nicht, ist die Rückkehr manuell, und das muss man im Ablauf berücksichtigen.
  7. Wiederholen Sie dasselbe für den dritten Slot, indem Sie sowohl den ersten als auch den zweiten Pool sperren.
  8. Notieren Sie Ergebnisse und Prüfdatum. Wiederholen Sie es nach jedem Firmware-Update: Das Failover-Verhalten ändert sich von Version zu Version.

Die Prüfung lässt sich gut mit geplanten Arbeiten kombinieren, wenn ohnehin ein Teil der Hashrate stillsteht. Die Kosten der Prüfung selbst berechnen sich nach derselben Tabelle: zehn Minuten bei 10 PH/s sind etwa 2,7 Dollar, eine einmalige Ausgabe für die Gewissheit, dass der Schutz funktioniert.

Failover muss vor dem Ausfall getestet werden
Failover muss vor dem Ausfall getestet werden

Kurz gesagt

Drei Slots statt einem erhöhen die Einnahme nicht. Sie entfernen aus der Grafik die Einbrüche, die sich sonst so lange hinziehen, bis Sie das Problem von Hand bemerken. Bei kleiner Hashrate misst sich der Gewinn in einzelnen Dollar pro Monat, bei industrieller in Hunderten und Tausenden.

Drei Dinge lohnt es sich im Kopf zu behalten. Das Umschalten geschieht nicht sofort, sondern nach dem Timeout der Firmware, dessen Wert Sie bei sich selbst messen müssen. Bei PPLNS kostet ein kurzer Wechsel auf den Backup weniger, als es scheint, weil Shares im Fenster allmählich altern, statt sofort nullgesetzt zu werden. Und ein eingerichteter, aber nie getesteter Failover ist kein Schutz, sondern nur dessen Imitation.

Was der Stillstand konkret für Ihre Konfiguration kostet, lässt sich im Rechner abschätzen, und die Bedingungen der Pools für den Backup lassen sich im Bereich Pool-Vergleich vergleichen.