Ist meine Vorstellung vom Getwork-Protokoll für Bitminer richtig?

Ich versuche, die Idee hinter dem Getwork-Protokoll zu verstehen, indem ich meine Kommunikation mit einem Bitminter-Miner-Pool schnüffele.

Zuvor habe ich die Diskussion hier gelesen , aber wenn ich mir meine Pakete ansehe, denke ich, dass es einige Dinge gibt, die anders implementiert sind. Ich kann verstehen, dass meine Frage zu vage sein kann, weil ich hauptsächlich meine Ideen ausdrücke, wie das Protokoll funktioniert, was völlig falsch sein kann. Aber sei bitte nicht zu streng.

Ich möchte das Protokoll durchgehen und meine Gedanken erläutern. Wenn ich zu irgendeinem Zeitpunkt falsch liege, erklären Sie mir bitte, wo ich falsch liege:

1) Mein Client autorisiert sich auf dem Server, indem er eine Post-Anfrage sendet

POST/HTTP/1.1
Content-Type:application/json
Accept:application/json
X-Mining-Extensions:longpollbcidmidstaterollntime
X-BCID:somenumber
X-Mining-Hashrate:my
Authorization:mySignature
Content-Length:39
Host:mint.bitminter.com:8332
Connection:Keep-Alive
User-Agent:BitMinter/1.3.0[BitMinter]

Soweit ich verstanden habe, teilt der Client nur mit, welche Erweiterungen er unterstützen kann, seine Hashrate (auf dieser Grundlage gibt ihm ein Server eine Aufgabe), seine Autorisierungsdaten.

Ein paar Dinge kann ich hier nicht nachvollziehen. Was ist X-BCID und was hindert den Client daran, eine falsche Hashrate zu übermitteln? Soweit ich verstanden habe, kann der Server nicht die Arbeit aller Clients überprüfen, sodass er die falsche Hashrate nicht erkennen kann. Ich verstehe, dass ich hier höchstwahrscheinlich falsch liege, aber ich kann einfach nicht verstehen, wie es gemacht wird

2) Nachdem er die Genehmigung für die Anmeldeinformationen des Kunden akzeptiert hat, bittet er um Arbeit. Manchmal hat es eine riesige Zeichenfolge im Params-Feld. Ich kann nicht verstehen, was diese Zeichenfolge darstellt und warum sie angezeigt wird.

{
  "method":"getwork",
  "params":[],
  "id":1
}

3) der Server antwortet mit den Informationen, die er unterstützt, Zeit, nach der die Antworten an den Server veraltet wären. Hier taucht auch diese X-BCID auf, die ich nicht nachvollziehen kann.

HTTP/1.1 200 OK
X-Stratum:stratum+tcp://eu1.bitminter.com:3333
X-Long-Polling:/lp
X-BCID:someNumber
X-Roll-NTime:expire=7Date:Mon,07Jan201319:52:20GMT
Server:Outpost/1.1.0 beta1
Content-Length:374
Content-Type:application/json;charset=UTF-8
Connection:Keep-Alive
Keep-Alive:timeout=895,max=5

4) zusammen mit der Arbeit, die der Kunde erledigen muss:

{
  "result":{
     "data":"huge string",
     "target":"smaller string"
  },
  "error":null,
  "id":1
}

Aus der oben genannten Quelle habe ich verstanden, dass riesiger Stich die Informationen über die Arbeit für den Client enthält (von welcher Zeichenfolge zu welcher Zeichenfolge Hashes durchlaufen und berechnet werden müssen) und mit kleineren Zeichenfolgen verglichen werden muss . Wenn ich also während der Berechnungen auf einen Wert stoße, dessen Hashes mir eine kleinere Zeichenfolge geben , werde ich einen Block beenden. Ich habe nicht verstanden, warum ich hier ein Fehlerfeld habe. Was testet es?

Also, meine Fragen sind :

  • was ist das X-BCID-Feld in Anfrage 1 und 3
  • wie der Server die Hashrate validiert, die vom Client in Anfrage 1 übermittelt wird
  • Was ist das Params-Feld in Anfrage 2, warum ist es manchmal leer?
  • Ist mein Verständnis über die Anfrage 4 richtig und warum brauchen wir 'error': null, response. Liegt das nur am Standard von JSON-RPC und ist es immer null, oder es kann Gründe geben, warum es null sein wird.
Der Server validiert die Hash-Rate nicht. Dem Server ist es egal, wie hoch die Hash-Rate des Clients ist, nur wie viele Freigaben er übermittelt und mit welcher Schwierigkeit er sie übermittelt. (Stellen Sie sich den Bergmann vor, als würde er Kisten öffnen und nach Eiern suchen. Dem Pool ist es egal, wie viele Kisten Sie öffnen, sondern nur, wie viele Eier Sie finden, woraus er statistisch schließen kann, wie viele Kisten Sie geöffnet haben, wenn es ihn interessiert.)

Antworten (1)

X-BCID ist eine benutzerdefinierte Erweiterung, die nur von der Getwork-Implementierung von BitMinter verwendet wird. Es ist eine Blockänderungs-ID. Falls die lange Abfrage nicht optimal funktioniert oder Blockänderungen zu schnell erfolgen, als dass die lange Abfrage alle erfassen könnte, macht das Anzeigen einer neuen Blockänderungs-ID den Client darauf aufmerksam, dass er eine Blockänderung verpasst hat.

Der Server validiert die vom Client übermittelte Hashrate nicht. Im BitMinter-Pool wird es derzeit von der Implementierung mit variabler Schwierigkeit (Vardiff) verwendet, um die anfängliche Worker-Schwierigkeit zu bestimmen, bis der Pool genügend Daten hat, um eine Hashrate zu schätzen.

Die Parameter für getwork sind leer, wenn der Kunde neue Arbeit anfordert, und haben Daten, wenn der Kunde einen Arbeitsnachweis einsendet. Das ist eine dumme Sache mit dem Getwork-Protokoll, die rpc-Funktion ist "getwork", sowohl wenn Sie Arbeit bekommen als auch wenn Sie Arbeitsergebnisse einsenden.

Das Fehlerfeld in der Antwort ist immer vorhanden, da dies vom JSON-RPC-Standard gefordert wird. Weitere Informationen zu JSON-RPC finden Sie unter http://json-rpc.org/

Ist meine Vorstellung vom Getwork-Protokoll für Bitminer richtig?
AntwortenHierDatenschutz-Bestimmungen1y, 0v