Was ist die Beziehung zwischen Hash-Rate und akzeptierten Anteilen?

Diese Frage bezieht sich speziell auf Litecoin, aber ich vermute, dass die Antwort auf beide zutreffen würde.

Angenommen, Sie haben ein Rig mit 700 Kh/s (LTC). Es scheint, dass Sie mehr oder weniger eine oder wenige akzeptierte Aktien pro Sekunde erhalten.

Mein Verständnis ist, dass Sie beim Schürfen 0 bis ~ 4 Milliarden für Ihre Nonce durchlaufen. Eine dieser Nonces ist die Nummer, nach der Sie suchen, und führt zu einer akzeptierten Aktie.

Im Durchschnitt würden Sie erwarten, in etwa 2 Milliarden Versuchen nach der richtigen Nonce zu lösen. Aber wenn Sie nur mit 700 Kh/s abbauen, geht die Mathematik nicht auf. Wenn Sie nur 700.000 Nonces pro Sekunde ausprobieren, dauert es etwa 45 Minuten, bis Sie den richtigen Nonce gefunden haben.

Was fehlt mir hier?

Antworten (2)

Beim Pool-Mining gibt es wirklich keine. Die meisten Pools verwenden heutzutage VarDiff, um die gleiche Anzahl von Anteilen pro Minute zu erreichen, indem Sie die Schwierigkeit Ihrer Arbeiter ändern. Nun, auf einem Low-End-Mining-Rig (sagen wir 20 kh/s) kann die Anzahl der akzeptierten Anteile stark variieren, da Sie mit Ihrem Anteil großes Glück oder Pech haben können. Solange Sie also über ein "gesundes" Maß an Hashing-Leistung verfügen, sollten Sie keine (m) Trends/Änderungen sehen (solange der Pool + VarDiff ordnungsgemäß eingerichtet ist).

Wenn Sie sich zum ersten Mal mit VarDiff-fähigen Pools verbinden, beginnen Sie mit einem Diff von 1, der sich dann über einen bestimmten Zeitraum anpasst, um eine vom Pool-Betrieb definierte Share-per-Minute-Rate zu erreichen.

Quelle: Ich, ich bin ein Pool-Op

BEARBEITEN Früher stand die Anzahl der von Ihnen eingereichten Shares in direktem Zusammenhang mit Ihrer Hashrate, je mehr akzeptierte Shares, desto schneller Sie hashten. AsicMiner-Produkte verwenden immer noch das Protokoll, das ursprünglich von Pools (und Bitcoin) namens "Getwork" verwendet wurde. Der bemerkenswerteste der damals verwendeten Pool-Server ist Pushpool.

Mit VarDiff haben Sie nicht die Möglichkeit, nach der Anzahl der eingereichten Aktien zu rechnen. Du berechnest also nun die Hashrate anhand der Schwierigkeit der eingereichten Aktie. Ich persönlich habe festgestellt, dass, wenn die Hashrate-Berechnung, die nur auf der Anzahl der eingereichten Aktien basiert, leicht mit Ihrer Hashrate-Berechnung basierend auf der Schwierigkeit der eingereichten Aktie abgewogen wird, die von Ihnen berechnete Hashrate des Benutzers genauer ist, als Sie es hätten, wenn Sie die berechnet hätten hashrate rein auf die Schwierigkeit der eingereichten Aktie.

Die Schwierigkeit liegt also in der Anzahl der führenden Null-Bytes, die im Hash erforderlich sind, richtig? Eine Schwierigkeit von 1 würde also erfordern, dass nur das erste Byte Null ist, und dies wäre dann leichter zu finden? Aber wird der Pool Sie mit mehr LTC für Anteile mit höherem Schwierigkeitsgrad („Qualität“) belohnen?
Ahh, das scheint das Problem zu sein. Ich denke dabei an das GetWork-Protokoll. VarDiff ändert das alles. Ich habs.

"Eine dieser Nonces ist die Nummer, nach der Sie suchen, und führt zu einer akzeptierten Aktie."

Diese Annahme ist falsch. Alles, was Sie sicherstellen müssen, ist, dass Ihr Hash unter dem Ziel liegt (und das Ziel auf der Schwierigkeit basiert). Sie könnten also einen Block treffen, der keine Nonce hat, die einen Hash unter dem Ziel ergeben würde, und Sie könnten einen Block treffen, für den jede Nonce einen gültigen Anteil ergeben würde.

Wenn Ihr Ziel also beispielsweise 0x0FFFFFFFF... lautet, dann ergibt im Durchschnitt 1 von 16 Hashes eine gültige Freigabe. Und wenn Ihr Ziel beispielsweise 0x0000000000000000FFFF... ist, müssen Sie die Schleife wahrscheinlich mehrmals ausführen, um einen Block zu treffen.

Nun, wenn Ihr Ziel 0x0000FFFFFFFF wäre ... wäre im Durchschnitt einer von ~ 65.000 gültig, oder? Dann ist mein Kommentar zu 0X00000000FFFFFFFFFFFF ... was zu einer von vier Milliarden führt, im Durchschnitt richtig?
Ja, wenn ich die Nullen richtig zähle. Aber der Punkt ist, dass die Anzahl der Iterationen für Nonce ziemlich irrelevant ist - es ist das Ziel, das das Verhältnis zwischen Hashrate und Sharerate definiert, und die Schwierigkeit hängt mit dem Ziel zusammen. Außerdem haben Pools im Allgemeinen entweder einen festgelegten Schwierigkeitsgrad für alle (das heißt, Sie würden mehr Anteile auf niedrigerem Schwierigkeitsgrad erhalten, aber jeder würde mehr Anteile erhalten, sodass, wenn der Pool einen Block erreicht, ein einzelner Anteil weniger wert ist) oder variiert Schwierigkeit, und rechnet dann eingereichte Aktien mit höherem Schwierigkeitsgrad als mehr wert, wenn es um die Verteilung des Blocks geht.
Ich habe etwas schnell gelesen und es scheint, dass Litecoin Bruchschwierigkeiten verwendet ... Was für mich keinen Sinn ergibt. Ich habe die Schwierigkeit immer als die Anzahl der Null-Bytes im Hash betrachtet. Jetzt sieht es so aus, als ob der Hash kleiner als das Ziel ist. Wie würde ein normales Schwierigkeitsziel aussehen, das zu einem akzeptierten Anteil pro Sekunde bei etwa 700-1500 Kh/s führen würde?
Ich schürfe derzeit auf Schwierigkeitsgrad 32 und mein Ziel ist 0x000007fff800... ; Um ganz ehrlich zu sein, habe ich keine Ahnung, was die genaue Beziehung zwischen Schwierigkeit und Ziel ist. Ich würde sagen, dass dies auf einem Mining-Rig mit ~1 MH/s zu etwa 1 Anteil pro 1-2 Sekunden führen würde, aber Sie möchten im Allgemeinen nicht zu schnell Anteile einreichen, oder Sie riskieren, an Ihren Netzwerkdurchsatz gebunden zu werden.
Was ist die Beziehung zwischen Hash-Rate und akzeptierten Anteilen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v