Job Negotiation ist die Abstimmung zwischen Miner und Pool über eine eigene Mining-Aufgabe. Stratum V2 legt fest, wie Mining-Geräte und Pools miteinander kommunizieren. Das Job Declaration Protocol ist der Teil für eigene Vorschläge und arbeitet mit der Verteilung von Vorlagen und Aufgaben zusammen. Miner sollen Transaktionen auswählen können, während der Pool weiterhin Arbeit erfasst und vergütet. Entscheidend ist die tatsächliche Einrichtung, nicht nur der Name der Verbindung.
Anna stellt auf Stratum V2 um, erhält die Transaktionsliste aber weiterhin vom Pool. Das ist kein Widerspruch. Das Mining Protocol zur Übermittlung von Arbeit und Ergebnissen kann ohne Job Declaration und Template Distribution betrieben werden. Letzteres liefert Blockvorlagen; Job Declaration behandelt eigene Vorschläge. Für Annas Auswahl müssen auch diese Rollen eingebunden sein und der Pool sie unterstützen. Ein modernerer Transport allein sagt deshalb noch nichts darüber aus, wer den Inhalt eines Blocks im Bitcoin-Netzwerk bestimmt. [1] [4]
Die ausgewählten Zahlungen dürfen den Block nicht so füllen, dass seine Belohnungstransaktion coinbase nicht mehr hineinpasst. Der Template Provider muss daher den nötigen Freiraum kennen. Auf Annas Seite arbeitet das Programm JDC, kurz für Job Declarator Client. Es ermittelt die Anforderungen der verwendeten Pools und sendet sie mit der Datennachricht CoinbaseOutputConstraints an den Template Provider. Reserviert werden Datenplatz und sigops, also Signaturprüfungen, die auf das Blocklimit angerechnet werden. Andernfalls könnten zusätzliche coinbase-Ausgänge, also Einträge zur Zuweisung von Mitteln, die Blockgrenzen überschreiten. Eigene Transaktionsauswahl muss von Anfang an die Gültigkeit des gesamten Ergebnisses berücksichtigen. [3]
Im Full-Template-Modus sendet JDC DeclareMiningJob an JDS, den Job Declarator Server beim Pool oder bei einem Dienst, dem der Pool vertraut. Die Nachricht nennt die Kennungen der ausgewählten Transaktionen. Fehlt dem Server eine dieser Transaktionen, kann er ihre Daten mit ProvideMissingTransactions anfordern. Anna stellt somit Informationen bereit, mit denen ihre Auswahl geprüft werden kann. Die Bestätigung der Deklaration und die anschließende Annahme der eigenen Aufgabe durch den Pool sind zwei getrennte Schritte. Die erste erfolgreiche Nachricht schließt die gesamte Abstimmung noch nicht ab. [2]
Im Coinbase-only-Modus legt JDC die Transaktionsmenge nicht offen; DeclareMiningJob wird nicht verwendet. Der Pool schätzt den Ertrag anhand der eingereichten coinbase. So bleibt Annas Auswahl vor dem Pool verborgen, doch das beweist weder die Gültigkeit der versteckten Transaktionen noch deren tatsächliche Gebühren. Die Spezifikation nennt dieses Risiko ausdrücklich. Weniger offengelegte Informationen verändern auch die Prüfmöglichkeiten. Der Modusname garantiert nicht, dass sämtliche Vergütungsbedingungen ausreichend belegt sind. Diese Privatsphäre betrifft den Entwurf während des Minings. Findet Anna einen gültigen Block und veröffentlicht ihn im Netzwerk, sind dessen Transaktionen sichtbar. [2]
Im technischen Austausch erscheinen mehrere ähnlich wirkende Kennungen. JDS vergibt mining_job_token, auf das der Client in SetCustomMiningJob verweist. Nimmt der Pool die Aufgabe an, antwortet er mit SetCustomMiningJob.Success und seiner eigenen job_id. Token und job_id erfüllen unterschiedliche Rollen: Ersteres verbindet die Abstimmung über den Vorschlag, Letztere kennzeichnet die Arbeit beim Einreichen von Ergebnissen. Vergleichbar sind eine Antragsnummer und eine Nummer für den genehmigten Auftrag. Eine Verwechslung würde verhindern, dass der Pool ein Ergebnis der richtigen angenommenen Arbeit zuordnet. [1]
Auf jeden Netzwerkschritt zu warten würde Geräte unnötig aufhalten. Sobald Token und Vorlage vorliegen, kann der Client schon vor SetCustomMiningJob.Success mit optimistischem Mining beginnen. Die berechneten shares, Teilergebnisse als Arbeitsnachweis nach dem Pool-Ziel, werden bis zur Bestätigung zwischengespeichert. Nach Annahme der Aufgabe lassen sie sich mit der zugewiesenen Kennung einsenden. Eine laufende Maschine beweist also noch nicht, dass der Pool diese Arbeit angenommen oder gutgeschrieben hat. Rechenbeginn und Zusage zur Vergütung sind verschiedene Zeitpunkte. [1] [2]
Erhält Anna SetCustomMiningJob.Error oder innerhalb angemessener Zeit keine Antwort, empfiehlt die Spezifikation einen anderen Pool oder Solo-Mining. Widerstandsfähigkeit hängt daher von einem funktionierenden fallback ab, einem vorbereiteten Ersatzweg. Würde die Software still zur ursprünglichen Vorlage des ablehnenden Pools wechseln, könnte sie weiterlaufen, aber Annas Auswahl ginge verloren. Entscheidend ist, was das System bei Ablehnung tatsächlich tut. Eine im Protokoll beschriebene Möglichkeit beweist nicht, dass jeder Dienst sie unterstützt. [1] [4]
Anna will Transaktionen auswählen und weiterhin gemeinsam vergütet werden. Ihr JDC muss deshalb dem festgelegten coinbase-Ausgang des Pools einen Wert zuweisen, um die Bedingungen für Pool-Belohnungen zu erfüllen. Leitet sie einen Teil des Ertrags anderswohin, kann der Pool die Vergütung dieser Arbeit anteilig kürzen. Job Declaration schafft weder eine automatische Direktauszahlung an den Miner noch beseitigt es die Abrechnungsbedingungen des Dienstes. Es verändert vor allem, wer Blockinhalte vorschlagen kann; Gültigkeitsregeln und Einkommensverteilung sind gesondert zu betrachten. [2]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Stratum V2, getblocktemplate, Mining Pool, Block Template, Bitcoin. Auf diesen Eintrag verweisen außerdem Stratum V2, Mining Pool Centralization.