Stale Rate bezeichnet den Anteil der Ergebnisse oder der gewichteten Arbeit, die als überholt gelten. Beim Bitcoin-Mining in einem Pool betrifft das meist Shares: Teilnachweise geleisteter Berechnungen, die nicht mehr zum aktuellen Auftrag passen. Die genaue Definition und die Folgen für die Vergütung hängen vom betrachteten System ab.
Ein Pool ist ein Dienst, der Arbeit unter Minern verteilt. Findet das Netzwerk einen neuen Block, müssen sie gewöhnlich anfangen, darauf aufzubauen. Ein Ergebnis aus dem vorherigen Auftrag hilft bei der neuen Arbeit nicht mehr. Stratum V2, ein Kommunikationsprotokoll für Mining-Geräte, regelt dies mit SetNewPrevHash: Das Gerät sucht nun einen Block, der an den neu angegebenen Block anschließt. Von den zuvor vorbereiteten Aufträgen bleibt nur der mit der Auftragskennung job_id bezeichnete gültig. Petra prüft bei der Fehlersuche daher die Gültigkeit des Auftrags, nicht bloß den Sendezeitpunkt. [1]
In einem einfachen Beispiel reicht Petra 100 Ergebnisse gleicher Schwierigkeit ein. Der Pool akzeptiert 98, lehnt 1 als stale und 1 aus einem anderen Grund ab. Abgelehnte Stale-Ergebnisse machen 1% aus, alle Ablehnungen zusammen 2%. F2Pool bezeichnet alle abgelehnten Einreichungen im Verhältnis zu sämtlichen Einreichungen als rejection rate. Stale ist in unserem Beispiel nur ein Teil davon. Die Zahlen erklären die Rechnung und sind keine akzeptable Betriebsgrenze; bei anderer Kategorisierung kann eine Anzeige etwas anderes bedeuten. [2]
Die Share-Schwierigkeit legt fest, wie anspruchsvoll ein einzureichendes Ergebnis sein muss. Braiins verbucht ein Ergebnis der Schwierigkeit d als d grundlegende Arbeitseinheiten. Nehmen wir einen stale Share mit Schwierigkeit 1 und einen akzeptierten mit Schwierigkeit 9. Nach Anzahl der Einreichungen ergibt sich 50%, nach Arbeitsgewicht 10%. Keine Rechnung ist an sich falsch; sie beantworten unterschiedliche Fragen. Petra verwendet beim Vergleich deshalb in Zähler und Nenner dieselbe Einheit und prüft, ob die Schwierigkeitskonvention übereinstimmt. [3]
F2Pool unterscheidet in seiner Dokumentation zwischen der vergüteten Kategorie Staled und abgelehnten stale Shares, für die es keine Vergütung gibt. Die Bezeichnung sagt somit allein nicht, ob Petra Geld verloren hat. Diese Regel lässt sich nicht auf jeden Pool übertragen: Maßgeblich sind die Bedingungen des jeweiligen Dienstes und seine tatsächliche Abrechnung. Beim Vergleich von Anbietern klärt Petra zunächst, welcher Kategorie die Ergebnisse angehören. Erst danach kann sie deren Einfluss auf die Einnahmen abschätzen. [2]
Beim Lesen eines Betriebsprotokolls übersieht man leicht, dass Stratum V2 mehrere Einreichungen mit einer einzigen Nachricht SubmitShares.Success bestätigen kann. new_submits_accepted_count nennt die Anzahl der neu bestätigten Einreichungen, new_shares_sum summiert deren Schwierigkeiten. Die Anzahl der Serverantworten ist deshalb nicht die Anzahl akzeptierter Shares. Bei einer Ablehnung enthält SubmitShares.Error die Kennung der Einreichung sequence_number sowie den Fehlergrund error_code. Ohne diese Unterscheidung könnte Petra jede Fehlermeldung für verspätete Arbeit halten. [1]
Die Nachricht von einem neuen Block muss zunächst die Computer erreichen, die Bitcoin prüfen. BIP152 beschreibt Compact Block Relay, eine datensparsamere Blockübertragung zwischen Knoten im P2P-Netzwerk, also direkt verbundenen Teilnehmern. Weniger Daten können die Übertragungsverzögerung verringern. Es geht jedoch um die Verbreitung von Blöcken, nicht um die Share-Abrechnung im Pool. Der Anteil der Blöcke außerhalb der Hauptkette misst daher nicht die verspäteten Ergebnisse von Petras Gerät. [4]
Braiins bietet Arbeitsstatistiken für unterschiedliche Zeiträume: shares_5m (letzte 5 Minuten), shares_60m (letzte 60 Minuten) und shares_24h (letzte 24 Stunden). Petra darf verspätete Ergebnisse eines kurzen Abschnitts nicht durch die Arbeit eines ganzen Tages teilen und mit der Stundenstatistik eines anderen Geräts vergleichen. Beide Teile der Rechnung müssen denselben Zeitraum und dieselben Geräte abdecken. Wurden keine Einreichungen beobachtet, ist das Verhältnis undefiniert; es handelt sich nicht um einen gemessenen Verlust von 0%. Auch eine Überwachungslücke oder eine fehlende Antwort beweist allein kein stale Ergebnis. [5]
Petra beginnt bei Auftragswechseln, Ablehnungsgründen und Verbindungsbedingungen im selben Zeitraum. F2Pool nennt Netzwerkbedingungen als Ursache für stale Ergebnisse. Andere Ablehnungen können durch Fehler in der Firmware, der Steuerungssoftware des Geräts, oder durch zu starkes Übertakten entstehen. Beim Übertakten wird die Taktfrequenz der Chips erhöht, um mehr Berechnungen auszuführen. Braiins empfiehlt ping, einen einfachen Test, ob der Server auf Netzwerkanfragen antwortet. Eine erfolgreiche Antwort belegt weder korrektes Mining noch gutgeschriebene Vergütung. Eine niedrigere Gesamtquote beweist allein nicht, dass die Ursache behoben wurde. Entscheidend ist, die Veränderung zu verstehen und die konkrete Fehlerart unter vergleichbaren Bedingungen zu verfolgen. [2] [6]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Mining Share, Share Difficulty, Mining Latency, Pool Fee, Bitcoin. Auf diesen Eintrag verweisen außerdem Stale Block, Mining Latency.