Bitcoin Forum
December 11, 2016, 04:32:21 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Poll
Question: Was soll gegen Poolhopping unternommen werden
Statistiken verzögern - 11 (14.1%)
Änderung der Auszahlungsmethode auf z.B. PPLNS - 17 (21.8%)
nichts - 50 (64.1%)
Total Voters: 78

Pages: « 1 2 3 [4] 5 6 7 8 9 »  All
  Print  
Author Topic: Abstimmung - x8s - Maßnahmen gegen Pool Hopping  (Read 21284 times)
f4tal1ty
Hero Member
*****
Offline Offline

Activity: 546


View Profile
July 15, 2011, 01:02:55 PM
 #61

Soll jeder Pools wechseln wie er es für das wirtschaftlichste hält.

So kann sich der Poolbetreiber aber auch das Recht rausnehmen alles daran zu setzen seine Miner auch bei größen Blöcken an den Pool zu binden.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481430741
Hero Member
*
Offline Offline

Posts: 1481430741

View Profile Personal Message (Offline)

Ignore
1481430741
Reply with quote  #2

1481430741
Report to moderator
nebiki
Full Member
***
Offline Offline

Activity: 154


View Profile
July 15, 2011, 01:06:57 PM
 #62

Reden wir mal Tacheles!

Ich sehe ihr habt das ganze Prinzip (Bitcoinmining und Pools, etc.) nicht wirklich verstanden.
Auch ein Megapool mit x-tausend Mhash/s kann mal Stunden brauchen,
bis er mit seinen Mitgliedern einen Treffer landet, dieser eine besonderen Share der den Block fängt.

Unterdessen und währendessen hat z.B. x8s mit seinen anfangs 10-40 Ghash/s doch ordentlich gewonnen, oder?

Btw. Alle Pools rechnen an den selben Blöcken, die einen "deeper", die anderen weniger.
Welcher nun gewinnt, ist "immer" Glücksache. Lediglich der Wahrscheinlichkeit wird, bei einem dicken fetten Pool,
ein Schnippchen geschlagen, und bei der Verlosung sind mit einem größeren Pool eben mehr Möglichkeiten eines Treffers gegeben.
Und so'n kleiner Poolhopper mit seinen was weiss ich wievielen Mhashs oder Ghashs macht da das Fett auch nicht mehr fetter.^^
Und wenn der Pool eben 25% seiner Leistung dadurch einbüßt, dann bedeutet das nicht unbedingt, das es jetzt 25% länger dauert bis ein Block gefunden wird. Absoluter Blödsinn.
Freut Euch stattdessen, denn dann steigt Euer Ertrag wieder.

Jetzt die Poolhopper zu bestrafen oder zu bashen oder fertig zu machen,
oder zu ignorieren, etc. finde ich echt schwach und zeugt von wenig Intelligenz.

Die Geschichte erzählt viel über die Suche nach dem Einen, dem Sündenbock, der dem alle Schuld aufgebürdet wird.
Ich habe das vor kurzem am eigenen Leib erleben dürfen, die letzten 3 Jahre. Mobbing, Terror, Cyberterror, Sachbeschädigung meines Fahrzeuges, Rufschädigung, und Rufmord, üble Nachrede, Belästigung meiner Frau, etc. ... Da werden Dinge erfunden, Dinge gefunden die gar nicht da sind, usw. Die Horde rottet sich zusammen und so weiter. Der pure Neid ist das, sonst nichts!!!

Ich habe da keinen Bock drauf.



tl;dr - nur, weil die leute hier nich viel wissen, muss man nich einfach reinwerfen, dass poolhopper toll fuer jeden pool sind. fuer den pool (den betreiber) ist das total egal, wer wann wohin huepft, er freut sich ueber jeden hash. wenn du durch poolhopping einen ertrag groesser als 1 machst, nimmst du den ertrag irgendwo weg - das kannst du nicht einfach verneinen. es kommt nichts aus nichts. mach mich nich fertig, ich finds schon schlimm genug im deutschen forum mit den ganzen tollen leuten.


edit: die leute, die aktives poolhopping betreiben, sind auch aktiver im forum und demnach wesentlich aktiver an dieser abstimmung. will das nur mal hier reinwerfen Smiley nicht jeder, der abstimmt, nimmt regelmaessig an dem pool teil.

1DWttUPMiDL1ou64SoUriZ29bxdoChjPns
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 01:59:51 PM
 #63

Eine Beispiellösung, die Alle zufrieden stellen könnte und ein Kompromiß wäre:

1. Es werden nur 49% am gefundenen Block sicher an "alle" Schürfer ausgeschüttet.
2. 1% gehen an den Poolbetreiber und die Extrafees kann er auch behalten (, was er ohnehin schon erhält).
3. Die restlichen 50% werden anteilig an die Schürfer ausgegeben, die dabei waren, als der Block gefunden wurde.
    (Da müsste die Datenbank angepasst werden, etc. Ein Mehraufwand für den Poolbetreiber. Steht es einmal, sind alle glücklich.)
   Eine Benachteiligung derjenigen, die aus irgendwelchen Gründen nicht mitschürfen konnten, könnte man wiederum damit entschädigen, dass man die Sekunden/Minuten/Stunden zusätzlich mit einberechnet, die ein Schürfer dabei war an der gesamten Runde, mit 100% an Punkt 3. Somit sind Poolhopper und die, die wegen höherer Gewalt nicht mitmachen konnten, nur mit maximal anteilig möglichen 100% an Punkt 3 beteiligt. Die die Dauerschürfen sind ebenfalls bei den 100% an Punkt 3 mit dabei, jedoch kriegen sie ja anteilig viel mehr. Der Hopper kriegt also immer weniger von den 100% an Punkt 3, weil er ja gesprungen ist. Dieser Wert sinkt immer mehr, je länger er nicht dabei war, zum Beispiel 25% von Punkt 3, weil er 75% der Zeit nicht dabei war. Etc. pp.

Insgesamt erhält jeder "überschlagen" 49% + (50 % - x%) am gesamten Ertrag. Wobei x kleiner wird je mehr man dabei war, usw.

Das würde die Dauerschürfer extra belohnen und Poolhopper verringern.

Ist jetzt mal so eine schnelle Idee aus'm Kopf!

In meinen Augen wäre das ein guter Lösungsansatz, alle wären zufrieden, und ein Poolhopper würde sich dann zweimal überlegen, ob er hoppt oder nicht. Wenn er hoppt sinkt sein Ertrag an der zweiten Hälfte der Ausschüttung, je länger er weggehoppt ist, und der Ertrag für die Dauerschürfer steigt anteilig immer mehr je länger ein Hopper weg ist.

Was meint ihr?





Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
July 15, 2011, 02:18:29 PM
 #64

In meinen Augen wäre das ein guter Lösungsansatz, alle wären zufrieden, und ein Poolhopper würde sich dann zweimal überlegen, ob er hoppt oder nicht. Wenn er hoppt sinkt sein Ertrag an der zweiten Hälfte der Ausschüttung, je länger er weggehoppt ist.

Was meint ihr?

Klingt nach Milchmädchenrechnung und mich würde interessieren, wie man misst, wer "dabei war" wenn der Block gefunden wurde (getworks kann man ohne Ende und ohne Aufwand requesten). Als Gegenmaßnahme (falls z.B. gemessen wird, wer in den letzten 10 Minuten ein share abgeliefert hat) braucht man dann ja auch nur mehr 1 Share alle 10 Minuten abliefern um den vollen Ertrag zu erhalten (eigentlich sogar mehr, da vielleicht einige andere den Pool einfach so verlassen während der Runde).

Außerdem ist man dann immer noch 49% proportional, also "hoppbar" UND die 1% fee ist auch mehr als die 0% fee bei vielen anderen Pools.

Wenn man schon das Payout System anpasst, dann doch lieber gleich auf PPLNS, das ist dann genauso von Glück abhängig (man verdient mehr, wenn der Pool Glück hat) ABER kann nicht gehoppt werden.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
flinder
Newbie
*
Offline Offline

Activity: 25


View Profile
July 15, 2011, 02:23:36 PM
 #65

Hallo in die Runde.
Hier meine Gedanken zum Thema:

Ich bin ein kleiner Meiner mit 2 Grakas (1x groß, 1x klein) in 2 Rechnern.
Ich bin dabei aus Spaß an der Sache, aus Neugierde, aus Idealismus und ich freue mich über ein paar Euros.
Und in diesem Pool fühle ich mich sogar etwas zu Hause Smiley Hier macht mir minen gleich doppelt so viel Spaß.

Da ich nebenbei an den Rechnern auch arbeiten muss, spielen möchte und der Technik eine Pause gönnen will (die ist mit Sicherheit nicht für 24h/7 Tage ausgelegt) stoppe ich die Worker und fahre meine Rechner regelmäßig runter. So lange ich nicht volle Power brauche lasse ich am Tage und wenn ich sowieso dran sitze, die Rechner minen. Wenn ich auswärts unterwegs bin, bleiben die Rechner auch aus.

Damit ist für mich klar. Ich werde immer mal nicht dabei sein können. Ich mache meine Shares für die Runde so lange es ebend geht. Ich fände es für mich schade, dafür mit einer Abwertung für meine Shares "bestraft" zu werden. Wenn ich wie in Runde 27 nicht dabei bin, gibt es ebend keine BTC.

Wenn Hopping wirklich ein großes Problem ist, dann würde ich es unterstützen, nicht zu bestrafen, sondern zu belohnen. Damit ich als kleiner Nutzer nicht vertrieben werde. Oder alternativ könnte man sich durch eine Spende freikaufen? Wer nicht immer online ist oder meint, springen verbessert statistisch seinen Ertrag, kann durch eine Spende (die an die konstanten Nutzer geht) sich von "Strafen" oder Einschränkungen freikaufen.

Ich würde gerne etwas in den Pott tun, wenn ich dann für mich selbst entscheiden könnte, wann ich die Grakas anwerfe.
Und wie gesagt. Mein normales Leben bestimmt die Betriebszeit und Weise meiner 2 Rechner. Denn Geld verdienen tue ich auf andere Weise.
Und ich fände es schade, wenn ich das Gefühl hätte als unerwünscht zu gelten.
 
Gruß
f4tal1ty
Hero Member
*****
Offline Offline

Activity: 546


View Profile
July 15, 2011, 02:40:33 PM
 #66

Eine Beispiellösung, die Alle zufrieden stellen könnte und ein Kompromiß wäre:

1. Es werden nur 49% am gefundenen Block sicher an "alle" Schürfer ausgeschüttet.
2. 1% gehen an den Poolbetreiber und die Extrafees kann er auch behalten (, was er ohnehin schon erhält).
3. Die restlichen 50% werden anteilig an die Schürfer ausgegeben, die dabei waren, als der Block gefunden wurde.
    (Da müsste die Datenbank angepasst werden, etc. Ein Mehraufwand für den Poolbetreiber. Steht es einmal, sind alle glücklich.)
   Eine Benachteiligung derjenigen, die aus irgendwelchen Gründen nicht mitschürfen konnten, könnte man wiederum damit entschädigen, dass man die Sekunden/Minuten/Stunden zusätzlich mit einberechnet, die ein Schürfer dabei war an der gesamten Runde, mit 100% an Punkt 3. Somit sind Poolhopper und die, die wegen höherer Gewalt nicht mitmachen konnten, nur mit maximal anteilig möglichen 100% an Punkt 3 beteiligt. Die die Dauerschürfen sind ebenfalls bei den 100% an Punkt 3 mit dabei, jedoch kriegen sie ja anteilig viel mehr. Der Hopper kriegt also immer weniger von den 100% an Punkt 3, weil er ja gesprungen ist. Dieser Wert sinkt immer mehr, je länger er nicht dabei war, zum Beispiel 25% von Punkt 3, weil er 75% der Zeit nicht dabei war. Etc. pp.

Insgesamt erhält jeder "überschlagen" 49% + (50 % - x%) am gesamten Ertrag. Wobei x kleiner wird je mehr man dabei war, usw.

Das würde die Dauerschürfer extra belohnen und Poolhopper verringern.

Ist jetzt mal so eine schnelle Idee aus'm Kopf!

In meinen Augen wäre das ein guter Lösungsansatz, alle wären zufrieden, und ein Poolhopper würde sich dann zweimal überlegen, ob er hoppt oder nicht. Wenn er hoppt sinkt sein Ertrag an der zweiten Hälfte der Ausschüttung, je länger er weggehoppt ist, und der Ertrag für die Dauerschürfer steigt anteilig immer mehr je länger ein Hopper weg ist.

Was meint ihr?











Also die Rewards für den Block werden so quasi geteilt, 50% gibts für den Anteil an Shares, 50% für den Mhash-Zeitanteil der gesamten Blockzeit (abzgl. Fees an den Poolbetreiber).

Mal als beispiel



Gesamthashrate: 100 Ghash

Miner A: 1 Ghash

Gesamtblockzeit: 10 Stunden

Gesamte Shares im Block 1000000

"Zeitpunkte" insgesamt: 100 Ghash x 600 Minuten = 60000 ZP



Miner A schürft für 7 Stunden mit

= 7000 Shares / 0,7 % der Shares = 0,175 BTC

= 1 Ghash x 420 Minuten = 420 ZP / 0,7 % der Zeitpunkte = 0,175 BTC


Kommt dann wohl ziemlich auf das selbe raus wie beim normalen Share-System.


Wenn andernfalls die anteilige Hashrate nicht mit der Zeit verrechnet wird, sondern die reine teilgenommene Zeit am Block ausschlaggebend ist, könnte man sich seine Zeit/User Prozentpunkte auch mit 10Mhash/s holen.





yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 02:41:18 PM
 #67

In meinen Augen wäre das ein guter Lösungsansatz, alle wären zufrieden, und ein Poolhopper würde sich dann zweimal überlegen, ob er hoppt oder nicht. Wenn er hoppt sinkt sein Ertrag an der zweiten Hälfte der Ausschüttung, je länger er weggehoppt ist.

Was meint ihr?

Klingt nach Milchmädchenrechnung und mich würde interessieren, wie man misst, wer "dabei war" wenn der Block gefunden wurde (getworks kann man ohne Ende und ohne Aufwand requesten). Als Gegenmaßnahme (falls z.B. gemessen wird, wer in den letzten 10 Minuten ein share abgeliefert hat) braucht man dann ja auch nur mehr 1 Share alle 10 Minuten abliefern um den vollen Ertrag zu erhalten (eigentlich sogar mehr, da vielleicht einige andere den Pool einfach so verlassen während der Runde).

Außerdem ist man dann immer noch 49% proportional, also "hoppbar" UND die 1% fee ist auch mehr als die 0% fee bei vielen anderen Pools.

Wenn man schon das Payout System anpasst, dann doch lieber gleich auf PPLNS, das ist dann genauso von Glück abhängig (man verdient mehr, wenn der Pool Glück hat) ABER kann nicht gehoppt werden.

Berechnung wäre:

a = (eigene Shares / Gesamtshares)
b = (a x (Schürfzeit / Rundenzeit))

c = (a x 49%) + (b x 50%) = Ertrag

Ich nenne das eine Antipoolhoppingmethode mit pay per share + Pay per time.

pps+ppt kurz PPSPPT

Was ist daran eine Milchmädchenrechnung?

PPLNS würde die Kleinen, die Hopper und diejenigen Benachteiligen, die nicht mitschürfen konnten, wegen höherer Gewalt.
Diejenigen, die das (n)-Shares-Fenster nicht erfüllen können eben, obwohl sie die gesamte Rundenzeit dabei waren, aber eben im Fenster keinen Share setzen konnten, aus welchen Gründen auch immer. Sei es Rechenpower, Hopping, oder höhere Gewalt.

Edit: Selbstverständlich kann man die oben genannte Formel ein wenig korrigieren. Im Großen und Ganzen aber finde ich es einen gelungenen Kompromiß für Alle.


nebiki
Full Member
***
Offline Offline

Activity: 154


View Profile
July 15, 2011, 02:47:07 PM
 #68

In meinen Augen wäre das ein guter Lösungsansatz, alle wären zufrieden, und ein Poolhopper würde sich dann zweimal überlegen, ob er hoppt oder nicht. Wenn er hoppt sinkt sein Ertrag an der zweiten Hälfte der Ausschüttung, je länger er weggehoppt ist.

Was meint ihr?

Klingt nach Milchmädchenrechnung und mich würde interessieren, wie man misst, wer "dabei war" wenn der Block gefunden wurde (getworks kann man ohne Ende und ohne Aufwand requesten). Als Gegenmaßnahme (falls z.B. gemessen wird, wer in den letzten 10 Minuten ein share abgeliefert hat) braucht man dann ja auch nur mehr 1 Share alle 10 Minuten abliefern um den vollen Ertrag zu erhalten (eigentlich sogar mehr, da vielleicht einige andere den Pool einfach so verlassen während der Runde).

Außerdem ist man dann immer noch 49% proportional, also "hoppbar" UND die 1% fee ist auch mehr als die 0% fee bei vielen anderen Pools.

Wenn man schon das Payout System anpasst, dann doch lieber gleich auf PPLNS, das ist dann genauso von Glück abhängig (man verdient mehr, wenn der Pool Glück hat) ABER kann nicht gehoppt werden.

Berechnung wäre:

a = (eigene Shares / Gesamtshares)
b = (a x (Schürfzeit / Rundenzeit))

c = (a x 49%) + (b x 50%) = Ertrag

Ich nenne das eine Antipoolhoppingmethode mit pay per share + Pay per time.

pps+ppt kurz PPSPPT

Was ist daran eine Milchmädchenrechnung?

PPLNS würde die Kleinen, die Hopper und diejenigen Benachteiligen, die nicht mitschürfen konnten, wegen höherer Gewalt.
Diejenigen, die das (n)-Shares-Fenster nicht erfüllen können eben, obwohl sie die gesamte Rundenzeit dabei waren, aber eben im Fenster keinen Share setzen konnten, aus welchen Gründen auch immer. Sei es Rechenpower, Hopping, oder höhere Gewalt.

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.

1DWttUPMiDL1ou64SoUriZ29bxdoChjPns
f4tal1ty
Hero Member
*****
Offline Offline

Activity: 546


View Profile
July 15, 2011, 02:49:20 PM
 #69

Macht im großen und ganzen keinen Unterschied, da der Zeitanteil immer etwa dem Shareanteil entspricht.
Andrexyz
Jr. Member
*
Offline Offline

Activity: 41


View Profile
July 15, 2011, 02:54:48 PM
 #70

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.
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 03:02:03 PM
 #71

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

 Shocked



nebiki
Full Member
***
Offline Offline

Activity: 154


View Profile
July 15, 2011, 03:08:28 PM
 #72

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

 Shocked

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.

1DWttUPMiDL1ou64SoUriZ29bxdoChjPns
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 03:15:38 PM
 #73

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.


yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 03:21:35 PM
 #74

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

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 03:23:47 PM
 #75

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 frage mich nur, wie man die Gesamt-last(N)-Shares berechnet, oder misst?

Irgendeiner eine Idee?

f4tal1ty
Hero Member
*****
Offline Offline

Activity: 546


View Profile
July 15, 2011, 03:27:20 PM
 #76

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.
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 03:29:07 PM
 #77

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.

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

blizzen
Sr. Member
****
Offline Offline

Activity: 280



View Profile
July 15, 2011, 03:31:14 PM
 #78

Hallo zusammen,

scheint mir eine typisch deutsche Diskussion zu sein, wie wirds noch gerecht als gerecht, und am Ende triffts doch wieder irgend einen. Wer dabei ist, bekommt was, wer nicht, der nicht, fertig.
Immer locker bleiben Cool

nein, Hopper bekommen mehr (und durchsuch mal das Forum, es gibt inzswischen Algorithmen, die den max. Profit (hey, war sicher ein Ferengi) ausrechnet) und die, die im Pool zurückbleiben, bekommen weniger, weils einfach noch länger dauert, wenn viele Miner abziehen und sie mit wenig Power "fertig" rechnen müssen...

D.h. sie machen das auf Kosten anderer und das ist eben nicht gerecht!

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?
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 03:31:35 PM
 #79

Endlich kommt die Diskussion in Gang. Das freut mich.

Weitere Vorschläge?

nebiki
Full Member
***
Offline Offline

Activity: 154


View Profile
July 15, 2011, 03:41:26 PM
 #80

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.



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.

1DWttUPMiDL1ou64SoUriZ29bxdoChjPns
Pages: « 1 2 3 [4] 5 6 7 8 9 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!