Anfängerfrage - Wie wird verhindert, dass Poolteilnehmer redundante Berechnungen machen?

[MenionLeah]

Wenn ich es richtig verstanden habe, dann wird, wenn man nicht sowas wie BetterHash verwendet, der candidate block vom Pool "owner" festgelegt, richtig?
Wenn das so ist, wie wird dann verhindert, dass jeder Poolteilnehmer seinen eigenen "Zahlenbereich" durchrechnet und nicht mehrere Teilnehmer die gleichen, redundanten Berechnungen?

[Cricktor]

Wie das im Detail funktioniert, weiß ich nicht. Der Pool-Owner/Operator legt den Blockheader fest, für den ein valider Blockheader-Hash gefunden werden muss (da der Blockheader den Merkle-Root über die im Block enthaltenen Transaktionen enthält, sind damit auch die Menge und Reihenfolge der Transaktionen im aktuellen Block Candidate festgelegt). Der Pool verteilt nun an alle Pool-Teilnehmer unterschiedliche Hash-Aufgaben (Shares) für den aktuell zu hashenden Blockheader, so daß z.B. der Nonce-Bereich komplett abgegrast wird. Ziel ist aber, daß dieselbe Hash-Arbeit möglichst nicht von mehreren parallel bearbeitet wird, was ja Verschwendung der Hashleistung aller Teilnehmer wäre.

Ist ein Nonce-Bereich abgegrast und liegen alle Hash-Berechnungen dafür vor (ggf. wird eine Hashing-Aufgabe von zumindest zwei Minern identisch ausgeführt, um entscheiden zu können, ob beide dasselbe Ergebnis generieren, dann kann der Pool-Operator davon ausgehen, daß beide ehrlich gehasht haben), wird der Blockheader modifiziert (Blocktime in erlaubten Grenzen anpassen, Coinbase-Kommentar anpassen, OP-Return Data in Coinbase-Output anpassen) und man kann erneut das Hashen des kompletten Nonce-Bereichs für diesen neuen Blockheader an alle Pool-Teilnehmer verteilen. Das wiederholt sich, bis ein Pool-Teilnehmer einen "guten Hash" findet.

Mindestens zwei Tricks sind mir allerdings nicht im Detail bekannt und wer die kennt, darf sie gerne hier mitteilen, weil es mich auch interessieren würde (und ich bisher zugegebenermaßen zuwenig Motivation und Druck hatte, selbst danach zu suchen):

• Ganz so simpel kann es nicht sein, denn der Pool-Operator muss ja verhindern, daß ein Pool-Teilnehmer, der einen "guten Hash" findet, diesen nicht einfach selbst als neuen Block publiziert und damit den Block-Reward einsackt (wobei Pool-Teilnehmer zunächst keine Kenntnis über die tatsächlichen Transaktionen und deren Reihenfolge im Block Candidate haben, da sie höchstens Kenntnis vom Merkle-Root haben, aus dem aber diese Detailinformationen nicht ableitbar ist)
• Wie stellt der Pool-Operator fest, daß ein Pool-Teilnehmer einen "Accepted Share" korrekt berechnet hat, also für eine Teilaufgabe einen quasi "passenden" Hash gefunden hat? Ich hielte es ja für Verschwendung von Hash-Leistung, wenn man eine Hash-Aufgabe an zumindest zwei Teilnehmer vergibt, deren Ergebnis vergleicht und wenn es identisch ist, davon ausgehen kann, daß beide korrekte Arbeit geleistet haben (wäre ja unwahrscheinlich, daß beide Pool-Teilnehmer auf die gleiche Art und Weise den Pool-Operator betrügen).
• Der "Erfolg" eines Pools basiert auf der möglichst effizienten und minimal redundanten Verteilung der Hash-Arbeit und des zuverlässig vollständigen Abgrasens des Nonce-Bereichs für einen Block Candidate Header. Der Pool-Operator muss dabei aber sicherstellen, daß tatsächlich die eigentliche Suche korrekt abgeliefert wird, kann dabei aber nicht den Pool-Teilnehmern vertrauen, daß die ihm nicht etwa die Arbeit nur vorgaukeln (z.B. bei PPS-Modus des Pools). Wie das optimal effizient gewährleistet wird, würde mich sehr interessieren.
• Je nach Leistungsfähigkeit von Pool-Teilnehmern kann der Pool-Operator auch Teil-Aufgaben mit unterschiedlicher Difficulty verteilen. Wie das funktioniert, würde mich auch sehr interessieren.

 

Bearbeitet 28. August 2021 von Cricktor

[skunk]

vor 39 Minuten schrieb Cricktor:

Ganz so simpel kann es nicht sein, denn der Pool-Operator muss ja verhindern, daß ein Pool-Teilnehmer, der einen "guten Hash" findet, diesen nicht einfach selbst als neuen Block publiziert und damit den Block-Reward einsackt (wobei Pool-Teilnehmer zunächst keine Kenntnis über die tatsächlichen Transaktionen und deren Reihenfolge im Block Candidate haben, da sie höchstens Kenntnis vom Merkle-Root haben, aus dem aber diese Detailinformationen nicht ableitbar ist)

Ist die Adresse auf die der Block Reward ausgezahlt werden soll nicht Teil des Block Hashes? Wenn ein Pool Teilnehmer einen gültiges Ergebnis für diesen Hash findet, kann er den Block so veröffentlichen oder es sein lassen aber er kann nicht einfach seine Wallet Adresse einfügen.

vor 39 Minuten schrieb Cricktor:

Wie stellt der Pool-Operator fest, daß ein Pool-Teilnehmer einen "Accepted Share" korrekt berechnet hat, also für eine Teilaufgabe einen quasi "passenden" Hash gefunden hat? Ich hielte es ja für Verschwendung von Hash-Leistung, wenn man eine Hash-Aufgabe an zumindest zwei Teilnehmer vergibt, deren Ergebnis vergleicht und wenn es identisch ist, davon ausgehen kann, daß beide korrekte Arbeit geleistet haben (wäre ja unwahrscheinlich, daß beide Pool-Teilnehmer auf die gleiche Art und Weise den Pool-Operator betrügen).

Den Aufwand würde ich gar nicht machen. Ich würde erstmal allen Teilnehmern vertrauen und nichts doppelt berechnen lassen. Mit genügend Zeit wird jeder Teilnehmer irgendwann mal einen Block finden womit sich die Frage erübrigt ob er lügt oder nicht. Ich würde den Teilnehmer einfach einen Reputationswert geben. Block finden erhöhte die Reputation ungemeint. Mit der Zeit reduziert sich die Reputation ganz langsam. Alle Teilnehmer mit geringer Reputation werden dann hin und wieder stichprobenartig überprüft.

Auch denkbar wäre es wenn ein Teilnehmer einen gültiges Ergebnis hat und damit der Nonce bekannt ist dann einfach genau diesen Nonce nochmal zur Kontrolle an andere Teilnehmer sendet. Allen den gleichen Nonce zu senden wäre natürlich ungünstig weil die Teilnehmer sich untereinander vernetzen können um dieser Überprüfung aus dem Weg zu gehen. Man könnte aber einfach dem Teilnehmer mit der geringsten Reputation genau diese Prüfung zukommen lassen. Oder man nimmt irgend eine andere Nonce. Entscheidend ist hier eher das Timing. Es wurde gerade ein gültiges Ergebnis gefunden womit der Pool Operator gerade alle Resourcen darauf verwenden muss diesen Block jetzt so schnell wie möglich in den Umlauf zu bringen. Wenige Millisekunden später wird der Befehl an alle Teilnehmer rausgehen den darauf folgenden Block zu minen. Diese kurze Unterbrechung könnte man perfekt nutzen um die schwarzen Schafe zu finden.

vor 39 Minuten schrieb Cricktor:

Je nach Leistungsfähigkeit von Pool-Teilnehmern kann der Pool-Operator auch Teil-Aufgaben mit unterschiedlicher Difficulty verteilen. Wie das funktioniert, würde mich auch sehr interessieren.

Unterschiedliche Difficulty ist nicht möglich. Die Difficulty wird von der Blockchain diktiert. Der Pool Operator kann aber stumpf einen Nonce Bereich durchzählen und einen Zeitrahmen festlegen. Ein Pool Teilnehmer, der 100 Hashes pro Sekunden schafft kann in einer Minute Nonce 0-5999 durch probieren. Der nächste Teilnehmer schafft vielleicht nur 3 Hash pro Sekunden. Der bekommt dann Nonce 6000-6179. Wieviel Hashes jeder Teilnehmer schafft kann man in umgekehrter Richtung recht einfach messen. Alle Teilnehmer maximal auszulasten und Überschneidungen zu vermeiden ist fast schon trivial.

Edit: Man kann auch einfach jedem Teilnehmer ein Inkrement zuweisen. In einem Pool mit 13 Teilnehmern und gleicher Hashleistung bekommen alle einen um 1 versetzten Startindex und dann jeweils um 13 erhöhen. Keine Überschneidung mehr und der Vorteil ist, dass man nach dem initialen Startschuss kaum Abstimmungsaufwand hat. Was macht man bei unterschiedlicher Hashleistung? Man könnte das entsprechend ausrechnen und auch dann nach dem gleichen Muster vorgehen. Die Frage ist nur ob die Berechnung überhaupt etwas ändert. Ein Miner mit 100 facher Hashleistung kann doch weiterhin in 13er Schritten vorgehen. Jeden Versuch den er macht hat die gleiche Chance einen Treffer zu finden und es stört nicht, dass die 12 benachbarten Zahlen vielleicht erst in 20 Minuten geprüft werden wenn die langsamen Miner aufgeholt haben.

Bearbeitet 28. August 2021 von skunk

[Cricktor]

vor 33 Minuten schrieb skunk:

Ist die Adresse auf die der Block Reward ausgezahlt werden soll nicht Teil des Block Hashes? Wenn ein Pool Teilnehmer einen gültiges Ergebnis für diesen Hash findet, kann er den Block so veröffentlichen oder es sein lassen aber er kann nicht einfach seine Wallet Adresse einfügen.

Da hast du natürlich Recht und ich den Wald vor lauter Bäumen nicht gesehen. Die Coinbase-Transaktion zur Auszahlung des Block-Rewards ist ja zwingend die allererste Transaktion im Block Candidate und damit natürlich auch über den Merkle-Root im Blockheader enthalten und festgelegt. Die kann ein unehrlicher Pool-Teilnehmer natürlich nicht für sich "verbiegen", um den Block-Reward für sich zu reklamieren.

 

Hm, die Aussagen zur Difficulty muss ich dann doch mal etwas differenzieren:

Zitat

Share and block solution are different things. Share difficulty doesn't affect the number of blocks found by a pool. Share difficulty doesn't affect miner rewards. Shares are used by miners to monitor their rigs and by pools to distribute rewards amongst their miners.

For example, suppose a block solution is a number that starts with 10 zeros and, a share solution may be a number with 5 zeros at the beginning. Sooner or later one of the shares will have not only 5, but 10 zeros at the start, and this will be the block solution.

A big mistake among beginning miners is to think that they find a block (or even two), when they see phrases like ‘Share Found’ and ‘Share accepted’ in their mining software.

Zitat

What does share difficulty mean when mining?

Based on your hashrate, Mining Pools set how hard it is to submit a share to them. The higher the hashrate, the higher the Share Difficulty. When miners are grinding through hashes, they will eventually find a hash that meets the target Share Difficulty, then they send it to their Mining Pool.

Ich verstehe es dann so, daß der Pool-Owner je nach Leistungsfähigkeit des Pool-Teilnehmers sehr wohl eine unterschiedliche Share-Difficulty verteilen kann. Angenommen die Block-Lösung wäre z.B. ein Hash der kleiner sein muss als ein Hash mit 19 Nullen am Anfang (wie aktuell bei Bitcoin), dann akzeptiert der Pool einen Share mit z.B. 10 Nullen von einem schwachen Pool-Teilnehmer, während ein starker Pool-Teilnehmer vielleicht 12-14 Nullen als "accepted share" abliefern muss. Die genauen Zahlen können sich ja unterscheiden und der Pool kann die Share Difficulty ja auch unterschiedlich für die Bezahlung des Miners gewichten. Wie genau das gemacht wird, entzieht sich meiner Kenntnis. Aber ich meinte in meiner ursprünglichen Aussage diese Share Difficulty und nicht die erforderliche Block Difficulty für einen validen Block.

Bearbeitet 28. August 2021 von Cricktor

[skunk]

vor 25 Minuten schrieb Cricktor:

Ich verstehe es dann so, daß der Pool-Owner je nach Leistungsfähigkeit des Pool-Teilnehmers sehr wohl eine unterschiedliche Share-Difficulty verteilen kann. Angenommen die Block-Lösung wäre z.B. ein Hash der kleiner sein muss als ein Hash mit 19 Nullen am Anfang (wie aktuell bei Bitcoin), dann akzeptiert der Pool einen Share mit z.B. 10 Nullen von einem schwachen Pool-Teilnehmer, während ein starker Pool-Teilnehmer vielleicht 12-14 Nullen als "accepted share" abliefern muss. Die genauen Zahlen können sich ja unterscheiden und der Pool kann die Share Difficulty ja auch unterschiedlich für die Bezahlung des Miners gewichten. Wie genau das gemacht wird, entzieht sich meiner Kenntnis. Aber ich meinte in meiner ursprünglichen Aussage diese Share Difficulty und nicht die erforderliche Block Difficulty für einen validen Block.

Ah stimmt das ergibt Sinn. Difficulty runter geht immer aber rauf ist sinnfrei.

Der Trick dahinter ist, dass der schwache Teilnehmer einen Hash mit mindestens 10 Nullen finden soll. Wenn der Teilnehmer bezüglich seiner Hashleistung nicht ehrlich ist, wird er selbst dafür keine Lösung finden. Die Gesamtleistung des Pools wird dadurch aber nicht reduziert. Der schwache Teilnehmer kann auch einen Glückstreffer haben mit 19 Nullen am Anfang. Die für ihn geringere Difficulty erlaubt es ihm nur "Zwischenergebnisse" einzureichen um zu beweisen, dass er die notwendige Hashleistung hat um auch mal einen Glückstreffer mit 19 Nullen zu landen.