223 / 736SHARE

Mining Share

Wie Miner ihre Arbeit gegenüber einem Pool belegen

Petr verbindet sein Mining-Gerät mit einem Pool, einem Dienst, der die Arbeit mehrerer Miner zusammenführt. Auf dem Bildschirm sammeln sich akzeptierte Shares, aber in seiner Wallet kommt noch nichts an. Das ist kein Widerspruch. Ein Share belegt zunächst Arbeit; die Berechnung und Auszahlung einer Vergütung folgen später. Ohne solche laufenden Nachweise könnte der Pool die Beiträge kaum einschätzen, wenn die Suche nach einem echten Block lange dauert.

Ein Mining Share ist ein Rechenergebnis, das die Anforderung des Pools für einen bestimmten Auftrag erfüllt. Aus solchen überprüfbaren Stichproben schätzt der Pool die geleistete Arbeit. Die Anforderung ist meist leichter als die für einen gültigen Bitcoin-Block. Deshalb sind die meisten Shares keine neuen Blöcke.

Petrs Gerät unternimmt enorm viele Versuche. Der Pool braucht nicht für jeden eine Nachricht, sondern erhält ausgewählte Ergebnisse, die eine vorgegebene Bedingung erfüllen. Er prüft sie und schätzt aus Häufigkeit und Schwierigkeit statistisch die Arbeit. Ein Mining Share ist daher weder Teil eines unfertigen Blocks noch ein übertragbarer Anteil an Bitcoin. Er ist auch keine Transaktion auf der Blockchain, der öffentlichen Historie von Bitcoin-Transaktionen in miteinander verbundenen Blöcken. Er dient dazu, den Rechenbeitrag des Miners gegenüber dem Pool nachzuweisen. [1]

Beim Mining wird ein Hash gesucht: ein als Zahl interpretiertes Rechenergebnis, das nicht über einem festgelegten Zielwert liegt. Der Pool setzt meist einen numerisch höheren Zielwert als das Netzwerk. Mehr Ergebnisse passen darunter, die Bedingung ist also leichter. Was dem Pool genügt, reicht normalerweise nicht für einen Block. Zufällig erfüllen einige Ergebnisse auch das strengere Netzwerkziel. Sie können zu einem neuen Block führen, wenn dieser auch alle übrigen Regeln erfüllt. Der Pool lockert Bitcoin-Regeln nicht, sondern setzt eine eigene Grenze für laufende Arbeitsnachweise. [1]

Petr muss diese Nachrichten nicht selbst zusammenstellen; das übernimmt die Mining-Software. Stratum V2 ist ein Protokoll, also Kommunikationsregeln zwischen Geräten und Pool. Die Nachricht SubmitSharesStandard enthält job_id für den Auftrag, nonce als bei der Suche veränderten Wert, ntime für den Zeitstempel im Blockheader und version für die Version des Headers, des kompakten Datenkopfs eines Blocks. Hinzu kommt die Kennung des Kommunikationskanals. Ohne diesen Kontext kann der Pool die Berechnung nicht zuordnen. Eine nonce ohne den richtigen Auftrag ist kein eigenständiger Arbeitsnachweis. [2]

Petr vergleicht Geräte mit unterschiedlich schwierigen Aufträgen. Die Schwierigkeit dient hier als Gewicht: Ein Ergebnis, das eine strengere Bedingung erfüllt, wird als mehr Arbeit angerechnet. Bei Umrechnung auf denselben Maßstab haben zwei akzeptierte Einsendungen mit Schwierigkeit 1024 dasselbe Gesamtgewicht wie eine mit Schwierigkeit 2048. Die Nachrichtenzahl unterscheidet sich, das angerechnete Arbeitsgewicht ist gleich. Auch diese Summe ist kein exaktes Protokoll aller tatsächlich ausgeführten Berechnungen: Einzelne Treffer sind zufällig. Deshalb muss Petr prüfen, ob ein als Shares beschrifteter Zähler akzeptierte Ergebnisse oder deren auf einen gemeinsamen Maßstab umgerechnetes Gewicht anzeigt. [3]

Ein Pool bestätigt manchmal mehrere Einsendungen zusammen. Dafür gibt es in Stratum V2 die Antwort SubmitShares.Success. Das Feld new_submits_accepted_count zählt neu bestätigte Einsendungen; new_shares_sum summiert die Schwierigkeiten ihrer Aufträge. Das erste zählt Ergebnisse, das zweite deren Gewicht. Beide beziehen sich auf die gerade bestätigte Gruppe, nicht automatisch auf die Gesamtsummen über die Laufzeit des Miners. Beim Lesen des Protokolls sollte man daher keine einzelne Bestätigung für jedes gesendete Ergebnis erwarten. [2]

Petrs Gerät kann ein Ergebnis als gesendet melden, während der Pool es noch prüft. Stratum V2 verwendet bei einer fehlerhaften Einsendung SubmitShares.Error; sequence_number ordnet den Fehler der betroffenen Einsendung zu. Ist eine sofortige Prüfung nicht möglich, kann die Fehlermeldung später eintreffen. Gesendete und bestätigt akzeptierte Ergebnisse müssen deshalb getrennt betrachtet werden, ebenso Ablehnungen. Ein steigender lokaler Sendezähler beweist noch nicht, dass der Pool alles angerechnet hat. [2]

Bestätigte Arbeit fließt in die Vergütungsregeln des jeweiligen Pools ein. Braiins berechnet etwa bei FPPS, Full Pay Per Share, die Vergütung aus eingereichter Arbeit und Netzwerkdaten wie Schwierigkeit und Blockvergütung; ein Anteil für Transaktionsgebühren kommt hinzu. Der Pool zieht seine Gebühr ab, und Überweisungen richten sich nach den Auszahlungseinstellungen. Eine Share-Bestätigung sendet selbst noch keine BTC (Bitcoin) an eine Wallet. Petr verfolgt daher akzeptierte Arbeit, berechnete Vergütung und tatsächliche Auszahlung getrennt. [4]

Ein Share-Zähler kann an einen Download erinnern, doch Mining funktioniert anders. Shares und Blöcke entstehen bei der Suche nach ausreichend niedrigen Hashes mit zufälligen Ergebnissen. Mehr nachgewiesene Arbeit verbessert die statistische Grundlage zur Schätzung der Rechenleistung, garantiert aber keinen weiteren Treffer. Auch eine lange Reihe akzeptierter Shares sichert keinen Block beim nächsten Versuch. Der Zähler zeigt Petr laufende Arbeit und deren Annahme, nicht dass nur noch das letzte Stück eines Blocks fehlt. [3]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Mining Pool, Share Difficulty, Proof of Work, Mining Target, Bitcoin. Auf diesen Eintrag verweisen außerdem ASIC Miner, Mining Pool, Braiins Pool, Stratum V1.

DOC · 001Bitcoin Developer Guide — Pool miningDokumentation DOC · 002Stratum V2 — Mining ProtocolSpezifikation DOC · 003Braiins Academy — Pool FAQDokumentation DOC · 004Braiins Academy — Rewards and payoutsDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung