Topic: Abstimmung - x8s - Maßnahmen gegen Pool Hopping - page 5. (Read 22651 times)

Gesamt-last-Shares = Summe aller im last(n)-Shares-Fenster abgelieferten last(n)-Shares pro Worker / Miner

Nachteil wäre wenn c = 0 ist, dann ist die Schürfzeit auch dahin.

... und allein die Zeit des Hoppingwechsels und deren Mhashverlust würde ebenfalls eine Rolle spielen, und den Ertrag des Hoppers mindern, auch wenn's nur Millisekunden sind zum Wechseln. Kumuliert auf die Wochen und Monate, wäre das sicherlich auch ein Verlust für den Hopper, weil in dieser Zeit das Minerprogramm nicht rechnet sondern mit Stop-start zu tun hat ...
Vielleicht auch noch damit den alles entscheidenden Share verwirft der gefunden werden könnte, um den Block zu lösen...

da haben leute also schon kleine progis geschrieben um möglichst nur an den kurzen blöcken in verschiedenen pools zu minen. ein automatisierter prozess zum poolhoppen.

hat denn irgendjemand schonmal bewiesen dass das überhaupt funktioniert?? das glaube ich nämlich gar nicht. es gibt keine möglichkeit zu sagen wann ein block fällt in einem pool. berechnungen mit statistischen wahrscheinlichkeiten um den "glücksfaktor" zu bestimmen machen keinen sinn.

wer hat die beweise dass man durch automatisiertes hopping mehr rewards hat?

ein hopper hat genauso viel glück/pech wie einer der nur ein einem pool mint.

wenn ich mehrere rigs hätte würde ich eine versuchsanordnung starten. leider ist mein mining-equip sehr bescheiden. jemand konfiguriert zwei worker mit der gleichen hashrate. ein worker mint 24/7 bei x8s. der andere wird mittels eines hopping-progs zum laufen gebracht und steuert automatisiert durch die verschiedenen poole. na einer bestimmten zeit 7 tage, 14 tage, wird bilanz gezogen.

so lang mir keiner das gegenteil beweisen kann, sage ich das automatisiertes hoppen nix bringt, ausser dass zeit damit verbraucht wird, mit einer kleinen software rumzuspielen.

Mir auch nicht so ganz, aber ich glaube, es werden nur die letzten (N)-Shares eines Miners berücksichtigt, bis der Block gefunden wurde.
Somit fallen alle Shares weg die abgeliefert wurden, die vor diesem Fenster liegen.
So habe ich das verstanden.

Was sind last(N)-Shares?

Bzw. das PPLNS Konzept ist mir nicht ganz klar.

Edit:

Ansatz für PPSPPTPPLNS:

a = (eigene Shares / Gesamtshares) x 49% vom Gesamtblockertrag
b = ((eigene Schürfzeit in der aktuellen Runde / Rundenzeit) x c) x 50% vom Gesamtblockertrag
c = (last(N)-Shares / Gesamt-last(N)-Shares)


d = a + b = Ertrag

Gesamt-last(N)-Shares = ?

b = (eigene Schürfzeit in der aktuellen Runde / Rundenzeit) x 25%

in dem Fall bekäme jeder User 12.5 BTC, wenn er die volle Rundenzeit schürft



b = (eigene Schürfzeit in der aktuellen Runde / Rundenzeit) x 25% / Anzahl der User

in dem Fall ergibt das Sinn, aber wenn du die Hashrate nicht in B einrechnest lassen sich die 25% für die Rundenzeit auch mit 1 mhash holen



b = (a x eigene Schürfzeit in der aktuellen Runde / Rundenzeit) x 25%

in diesem fall a = b, weil Shares / Gesamtshares = Zeitanteil / Gesamtzeit (konstate Hashrate vorrausgesetzt)

in das boot moechte ich aber nich aufspringen. es geht darum, dass die leute nicht vom proportionalen wegmoechten. auf welche weise gegen poolhopping vorgegangen wird, ist voellig egal. da kannst du halt noch so merkwuerdige methoden entwickeln, die simpelste (pplns) funktioniert und birgt gegenueber anderen keine nachteile.

Endlich kommt die Diskussion in Gang. Das freut mich.

Weitere Vorschläge?

Naja, vorrausgesetzt man hopft in einen Glückspool, wo anders kanns doch genaus so (schlecht) laufen, und dauernd hin und her wäre mir zu blöd. Und nachts hopst bestimmt auch kaum einer, oder könnte man das automatisieren?

ja, das ist mir auch aufgefallen, da b von a abhängig ist.

nehmen wir a raus aus b ergibt sich folgende Formel:

a = (eigene Shares / Gesamtshares) x 49%
b = (eigene Schürfzeit in der aktuellen Runde / Rundenzeit) x 25%
c = (last(N)-Shares / Gesamt-last(N)-Shares) x 25%

d = a + b + c = Ertrag

Die Rechnung ist nachvollziehbar und den Ansatz die geminte Zeit in das Auszahlungssystem einzubauen ist gut.

Aber die Rechnung ergibt an sich wenig Sinn, da a immer = b, weil die Shares & Zeit immer im Verhältnis zueinander und zur gelieferten Hashrate stehen.

Ich frage mich nur, wie man die Gesamt-last(N)-Shares berechnet, oder misst?

Irgendeiner eine Idee?

kleine Korrektur:

a = (eigene Shares / Gesamtshares) x 49%
b = (a x (eigene Schürfzeit in der aktuellen Runde / Rundenzeit)) x 25%
c = (last(N)-Shares / Gesamt-last(N)-Shares) x 25%

d = a + b + c = Ertrag

Ich finde es sehr interessant, wie keiner selbst mal in dieser Diskussion eine Lösung versucht.
Es wird gleich alles kaputtgemacht, usw., anstatt das WIR Alle unsere Rechen- und Denk-Leistung - die wir auf unseren Schultern sitzen haben - mit einbringen.

Kommt schon Leute. Das kann doch nicht sein, bitte.

fuehr doch noch ein paar logarithmen und exponentialfunktionen ein.. und moeglicherweise noch ableitungen und integrale. reihen natuerlich auch. cool waeren allerdings noch matrizen, mit denen sich das ganze dann noch mehrdimensional errechnen laesst.

Und um die PPLNS-Anhänger zufrieden zu stellen, versuche ich die Milchmädchenrechnung ein wenig zu erweitern.

Berechnung wäre:

a = (eigene Shares / Gesamtshares) x 49%
b = (a x (eigene Schürfzeit / Rundenzeit)) x 25%
c = (last(N)-Shares / Gesamt-last(N)-Shares) x 25%

d = a + b + c = Ertrag

Kurz: PPSPPTPPLNS

 

ohje jetzt werde ich mir wieder Freunde machen *lach

ich gehe mal davon aus das wenige Redhat das Messer auf die Brust gesetzt haben wegen den Hoppern und jetzt immer mehr auf den Zug aufspringen. Ich schätze einfach mal das der x8s womöglich durch das ganze hier sehr geschädigt wird.
Es beschweren sich leute wegen den Poolhoppern ca. 15% vom Pool (klar sind 20-25% wegen den sinkenden Hashraten, aber einige sind wohl gegangen und kommen wohl nicht wieder wegen "sinkender" einnahmen gegenüber früher) und wollen dies nun verändern, da es sonst angeblich länger dauert einen Block zu finden. Wenn nun eine Lösung gefunden wird werden wohl die Poolhopper weg sein (dauerhaft) und der ein oder andere wird nicht damit zufrieden sein und auch abwandern.
Was wurde nun erreicht??? dauerhaft weniger Hashraten! dafür aber das gewollte System und theoretisch längere dauer bis der Block gefunden wird. Das wird nun wieder einige dazu bewegen zu gehen, weil es lange dauert bis ein block gelöst wird.

Das ist leider ein Problem der Deutschen (bin selber deutsch) immer alles richtig regulieren zu wollen und immer mehr zu verlangen und sich nicht mit dem vorhandenen zufrieden zu geben.
Anstatt sich zu freuen das Redhat wirklich alles versucht die gewünschten Statistiken, Änderungen, anzeigen in den Pool einzufügen wird es nun ausgenutzt. Er gab den kleinen Finger und nun zieht man gleich die ganze Hand.

Ich weiss nun nicht wieviel so ein Server kostet und denke mal das er die Kosten erst wieder reinholt wenn der Pool grösser wird und eventuell einen kleinen oder grösseren Gewinn dann mal verbuchen kann (wenn er es auch erstmal als Fortbildungsmassnahme sieht) aber es sollten sich die leute erstmal verinnerlichen das diejenigen sein Werk zerstören können und das hätte man sich vorher mal überlegen sollen bevor man jemanden so unter Druck setzt.

Mir tut Redhat ehrlich leid.

vielleicht sehe ich es zu überzogen für manche aber jeder darf doch seine Meinung haben.

Was man auch nicht vergessen sollte, das sich sicherlich manche  nicht wirklich mit Hopping beschäftigt haben und nun sehen das es lohnenswert sein kann und dies nun versuchen werden und bei positiven Resultaten dies aktiv betreiben.

Ich hoffe doch das wenn dies alles umgesetzt wird und meine Befürchtung wahr wird, die Leute die Redhat so unter Druck gesetzt haben auch trotz allem weiterhin x8s treu bleiben und nicht den Pool verlassen. Denn wegen EUCH ist es dann soweit gekommen.

Macht im großen und ganzen keinen Unterschied, da der Zeitanteil immer etwa dem Shareanteil entspricht.

die frage ist eher, was an der methode besser ist als an PPLNS. irgendwelche merkwuerdigen berechnungen einfuehren kann man immer, aber sie sollten doch noch leicht verstaendlich bleiben. da sie untereinander vom nutzen her identisch sind, ist PPLNS die wesentlich bessere methode. das ist wie inches, miles und pounds - keiner braucht sowas.