Verständnisfrage - Poolmining

[muto]

Mir ist vor kurzem unter der Dusche ein Einfall gekommen, den ich mit meinem Halbwissen nicht wiederlegen kann.

Was hält einen davon ab, einen Fork z.B. von cgminer zu machen, der shares an einen pool liefert und gefundene Blocks selbst einbehält?

Also eine einfach If-Schleife

If sharediff > networkdiff Then
  send to localwallet
Else
 send to pool
Endif

Ich kann mir fast nicht vorstellen, dass es funktioniert. Da wären bestimmt schon andere darauf gekommen. Aber ich weiß nicht, warum es nicht funktioniert 

[amigaman]

theoretisch geht das.
Aber wer würde deinen nicht-offiziellen Closed-source-client benutzen wollen?

[muto]

Ich selbst (natürlich nicht, aber theoretisch), damit kann ich dann Coins für meine nutzlosen Shares im Pool abschöpfen und wenn ich tatsächlich mal nen Block finde, behalte ich den selbst.

Ich hoffe doch stark, dass das nicht geht.

[amigaman]

Doch klar geht das, wenn du deine Saftware selber bauen kannst.
Warum sollte das nicht gehen?
Der Pool weiß doch nicht, das du das gefunden hast, wenn du es nicht erzählst.
Ist nur ne Frage, wie groß deine Chance ist, selbst einen Block zu finden.
Und sicherlich braucht es mehr als die paar Zeilen, aber das Prinzip geht so.
Ist so ähnlich mit der donate-funktion eingebaut gewesen, und manchen Pools wurde auch unterstellt, das sie das so ähnlich handeln.

[poorminer]

Ich hoffe doch stark, dass das nicht geht.

Wieso hoffst du, dass es nicht geht?

Du könntest die Pooled Mining Szene doch voll aufmischen damit.  

[Akka]

Geht nicht.

Ob die Hashes die du für einen Pool erzeugst einen gültigen Block finden ist auch von der Adresse für den Coin reward abhängig.

Mit diesen Hashes kannst du für dich selbst nichts anfangen.

[lassdas]

theoretisch geht das.

Genaugenommen geht das weder theoretisch, noch praktisch.
cgminer erzeugt (oder findet) nämlich garkeine Blöcke, sondern nur Hashes.  

Was ginge (sowohl theoretisch, alsauch praktisch), wäre, diese Hashes, die sogenannten Shares einzubehalten,
nur bringt das dem Erzeuger des Hashes/Shares garnichts, er schadet damit nur dem Pool und natürlich auch sich selbst.

Man kann mit einem Hash, den man für jemand anderen generiert (in unserem Fall für den Pool), keinen eigenen Block erzeugen,
da man für den eigenen Block andere Daten hashen würde, als der Pool.

[sQueeZer]

Ich verstehe trotzdem nicht genau, wieso das nicht funktionieren sollte...

Hinter dem Pool steht ebenfalls ein Wallet, welches gesynced ist und auf aktuellem Netzwerk-Stand ist.
Daraus resultiert doch logischerweise auch der aktuelle Block, an dem gehashed wird - soweit korrekt?

Also ist es doch Jacke wie Hose ob ich die Bock information aus dem Pool-Wallet ziehe
und spaeter bei Share > Networkdiff eifnach an mein eigenes Wallet sende oder in den
Pool zurueck-reporte.

Ein Gueltiges 'BLOCK!' im cgminer sollte sowohl fuer den Pool gueltig sein, als auch fuer das lokale
Wallet. Denn beide Wallets sind ja auf aktuellem Blockstand.

Korrigiert mich bitte falls ich da was falsch verstanden habe.

[poorminer]

Was ginge (sowohl theoretisch, alsauch praktisch), wäre, diese Hashes, die sogenannten Shares einzubehalten,
nur bringt das dem Erzeuger des Hashes/Shares garnichts, er schadet damit nur dem Pool und natürlich auch sich selbst.

Man kann mit einem Hash, den man für jemand anderen generiert (in unserem Fall für den Pool), keinen eigenen Block erzeugen,
da man für den eigenen Block andere Daten hashen würde, als der Pool.

Also man kann die erfolgreichen Hashes rausfiltern um einen Pool fertigzumachen. Der eigene Verdienst wird aber kaum gemindert, da es ja total unwahrscheinlich ist, selbst einen Block zu finden. Und selbst wenn, dann hätte man ja kaum was davon einen Block zu finden. Das nenn ich mal eine kreative, wenn auch ein wenig destruktive Idee.  

Wie sieht das aus, könnte man auch totale nonsense-Hashes senden, um beim Pool abzusahnen ohne zu leisten?

[fronti]

Ich verstehe trotzdem nicht genau, wieso das nicht funktionieren sollte...

Hinter dem Pool steht ebenfalls ein Wallet, welches gesynced ist und auf aktuellem Netzwerk-Stand ist.
Daraus resultiert doch logischerweise auch der aktuelle Block, an dem gehashed wird - soweit korrekt?

der Block zu dem du die den Hashwert finden willst/musst ist ja der neue. In den Transaktionen seit dem letzten gesyncten miteingeflossen sind.
Welche das dann sind entscheidet der miner (poolbetreiber) und da steht dann ja auch die Pooladdesse drin..

[Akka]

Wie sieht das aus, könnte man auch totale nonsense-Hashes senden, um bei Pools abzusahnen?

Nein. (Als ob darauf noch keiner gekommen wäre).

Gültige Hashes sind immer Hashes die bei einer niedrigeren Difficulty (und sonst identischen Umständen) einen Block für den Pool gefunden hätten.

[lassdas]

Korrigiert mich bitte falls ich da was falsch verstanden habe.

Aaalso:

Um einen Block zu erzeugen, nimmt man einen Haufen Daten,
Client Versionsnummer, Timestamp, Hash des vorherigen Blocks, Nonce
und den Hash der Transaktionen, die man in den Block aufnimmt.

Eine der Transaktionen, die man aufnimmt, ist die, die den Coin-Reward generiert und an eine Adresse sendet.
Die Wahrscheinlichkeit, daß Du exakt dieselben Transaktionen in Deinem Block aufnimmst, die auch der Pool für seinen Block verwendet, ist schon extrem gering,
aber mindestens diese eine Transaktion der neu-generierten Coins wird sich immer unterscheiden,
schließlich willst Du diese Coins in Deinem Block ja nicht an die Adresse des Pools schicken, sondern an Deine eigene.  

Für einen Block aus anderen Daten brauchst Du auch nen anderen Hash.

Wie gesagt, einbehalten kannst Du den Hash schon, bringt aber Dir aber nix.

[sQueeZer]

Korrigiert mich bitte falls ich da was falsch verstanden habe.

Aaalso:

Um einen Block zu erzeugen, nimmt man einen Haufen Daten,
Client Versionsnummer, Timestamp, Hash des vorherigen Blocks, Nonce
und den Hash der Transaktionen, die man in den Block aufnimmt.

Eine der Transaktionen, die man aufnimmt, ist die, die den Coin-Reward generiert und an eine Adresse sendet.
Die Wahrscheinlichkeit, daß Du exakt dieselben Transaktionen in Deinem Block aufnimmst, die auch der Pool für seinen Block verwendet, ist schon extrem gering,
aber mindestens diese eine Transaktion der neu-generierten Coins wird sich immer unterscheiden,
schließlich willst Du diese Coins in Deinem Block ja nicht an die Adresse des Pools schicken, sondern an Deine eigene.  

Für einen Block aus anderen Daten brauchst Du auch nen anderen Hash.

Wie gesagt, einbehalten kannst Du den Hash schon, bringt aber Dir aber nix.

Vielen Dank fuer die Ausfuehrliche Antwort. Das hiflt mir wirklich weiter
Dachte der naechste gueltige Block richtet sich lediglich am Hash des vorherigen Blocks.

Dennoch koennte man durch Einbehaltung der Gueltigen Pool-Bloecke zB
PPS-Pools schaden... Ohne selbt davon großartig betroffen zu sein.

Grueße

[muto]

Ich verstehe trotzdem nicht genau, wieso das nicht funktionieren sollte...

Hinter dem Pool steht ebenfalls ein Wallet, welches gesynced ist und auf aktuellem Netzwerk-Stand ist.
Daraus resultiert doch logischerweise auch der aktuelle Block, an dem gehashed wird - soweit korrekt?

der Block zu dem du die den Hashwert finden willst/musst ist ja der neue. In den Transaktionen seit dem letzten gesyncten miteingeflossen sind.
Welche das dann sind entscheidet der miner (poolbetreiber) und da steht dann ja auch die Pooladdesse drin..

Danke! Der Teil hat mir gefehlt

[poorminer]

Nein. (Als ob darauf noch keiner gekommen wäre).

Gültige Hashes sind immer Hashes die bei einer niedrigeren Difficulty (und sonst identischen Umständen) einen Block für den Pool gefunden hätten.

D.h. es wird jedes gesendete Hash vom Pool gegengeprüft, auch diejenigen, die keinen Block finden?

[Akka]

Nein. (Als ob darauf noch keiner gekommen wäre).

Gültige Hashes sind immer Hashes die bei einer niedrigeren Difficulty (und sonst identischen Umständen) einen Block für den Pool gefunden hätten.

D.h. es wird jedes gesendete Hash geprüft, auch diejenigen, die keinen Block finden?

Wie sollte der Pool sonst deinen Anteil an der Arbeit ermitteln? Deshalb stellt Stratum ja auch eine Lokale Div. entsprechend deiner Hardware ein, sonst hättest du nur deshalb massig Traffic. War bei Getwork noch so, das ist deshalb für die schnellen ASICs ungeeignet und wird meines Wissens auch von niemandem mehr benutzt.

*Mining ist jetzt nicht gerade mein Fachgebiet also alles mit ner Prise Salz lesen.

[lassdas]

Dennoch koennte man durch Einbehaltung der Gueltigen Pool-Bloecke zB
PPS-Pools schaden... Ohne selbt davon großartig betroffen zu sein.

Ja, das könnte man,
was vermutlich mit ein Grund dafür sein dürfte, daß es fast keine PPS-Pools mehr gibt und der kümmerliche Rest hohe Gebühren verlangt.

[sQueeZer]

Danke fuer die Beitraege, weiter so !