Bitcoin Forum
December 06, 2016, 04:11:15 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   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 21277 times)
f4tal1ty
Hero Member
*****
Offline Offline

Activity: 546


View Profile
July 15, 2011, 03:48:39 PM
 #81

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 Huh



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)
1481040675
Hero Member
*
Offline Offline

Posts: 1481040675

View Profile Personal Message (Offline)

Ignore
1481040675
Reply with quote  #2

1481040675
Report to moderator
1481040675
Hero Member
*
Offline Offline

Posts: 1481040675

View Profile Personal Message (Offline)

Ignore
1481040675
Reply with quote  #2

1481040675
Report to moderator
1481040675
Hero Member
*
Offline Offline

Posts: 1481040675

View Profile Personal Message (Offline)

Ignore
1481040675
Reply with quote  #2

1481040675
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481040675
Hero Member
*
Offline Offline

Posts: 1481040675

View Profile Personal Message (Offline)

Ignore
1481040675
Reply with quote  #2

1481040675
Report to moderator
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 03:58:55 PM
 #82

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 = ?

f4tal1ty
Hero Member
*****
Offline Offline

Activity: 546


View Profile
July 15, 2011, 04:07:14 PM
 #83

Was sind last(N)-Shares?

Bzw. das PPLNS Konzept ist mir nicht ganz klar.
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 04:10:43 PM
 #84

Was sind last(N)-Shares?

Bzw. das PPLNS Konzept ist mir nicht ganz klar.

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.

bluetowel
Sr. Member
****
Offline Offline

Activity: 246



View Profile
July 15, 2011, 04:16:12 PM
 #85

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.

ooo Legalize it ooo
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 04:20:28 PM
 #86

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.

... 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...

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 04:29:59 PM
 #87

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-Shares)


d = a + b = Ertrag

...


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.



nebiki
Full Member
***
Offline Offline

Activity: 154


View Profile
July 15, 2011, 04:35:31 PM
 #88

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.

hopping ist auch nicht sofort ersichtlich. die ganzen niedlichen beispiele, die genannt werden, helfen oft nicht, zu verstehen, wieso es (weil varianz eine ganz grosse rolle beim minen spielt) ueberhaupt im mittel etwas bringt. hier gibt es einen beitrag, der alles "vernuenftig" erklaert. allerdings braucht es dafuer auch gewisse vorkenntnisse und die ein oder andere vorlesung in statistik sollte besucht worden sein: https://forum.bitcoin.org/index.php?topic=3165.0

edit: @yetis - warum kommen hier so viele beitraege ueber deine anti-hopping-methode? es gibt methoden, die funktionieren und simpel sind.

1DWttUPMiDL1ou64SoUriZ29bxdoChjPns
yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 04:48:53 PM
 #89


edit: @yetis - warum kommen hier so viele beitraege ueber deine anti-hopping-methode? es gibt methoden, die funktionieren und simpel sind.

Ja, ich bin halt so. Die einen halten nichts von PPS, die nächsten wiederum nichts von diesem und jenem, und die anderen nichts von PPLNS.

Da wird sich doch was finden, um alles unter einen Hut zu bekommen, oder? Am besten alles in einen Topf und fertig.

Dann sind alle glücklich.

Edit:
... und das leidige Thema des Poolhoppings wäre gegessen.

Ausserdem wollte ich einen Krieg verhindern, die Lager wieder zusammenführen, damit wir gemeinsam an einer Lösung arbeiten, die alle zufrieden stellen könnte.

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 04:49:43 PM
 #90

Vereinfachen wir das Ganze wieder ein bisschen und versuchen es mal anders?

PPS:    a = (eigene Shares / Gesamtshares) x 49%
PPT:     b = (eigene Schürfzeit in der aktuellen Runde / aktuelle Rundenzeit) ... x 25%
PPLNS:  c = (eigene last-Shares im last(n)-Shares-Fenster / Gesamt-last-Shares aller Miner im last(n)-Shares-Fenster) x 25%

d = a + b + c = Ertrag


Jetzt fehlt bei b noch was. Dann hätten wir's glaube ich. (hoffentlich)

Ich lass das jetzt mal so stehen. Muss was anderes erledigen...

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 07:58:39 PM
 #91

PPS:a = (eigene Shares / Gesamtshares) x 24%
PPT: b = (((eigene Schürfzeit in der aktuellen Runde / aktuelle Rundenzeit) x (aktiv oder nicht)) / insgesamt aktive Miner bei Blockfund) x 50%
PPLNS: c = (eigene last-Shares im last(n)-Shares-Fenster / Gesamt-last-Shares aller Miner im last(n)-Shares-Fenster) x 25%

d = a + b + c = Ertrag

PPS ist hoffentlich jedem klar.

Zu PPT:
Wenn einer 100% dabei war dann ist Schürfzeit/aktuelle Rundenzeit = 1. Wenn weniger dann < 1
Wer nicht aktiv dabei war als der Block gefunden wurde, dann ist "aktiv oder nicht" = 0. Und 0 mal irgendwas ergibt ja Null, und 0 geteilt durch irgendwas auch. Die Frage ist nur, wer aktiv war oder nicht. Man könnte die Stunde vor dem Blockfund für ein einziges abgeliefertes Share hernehmen, und die eine Stunde nach Blockfund, oder so. Wird sich schon was finden. Oder nur die getwork-Abfrage, etc. als Bestätigung. Man könnte auch noch a in die Klammer mit einmultiplizieren usw. ...

Und PPLNS kann man auch weglassen, da wir ein System gefunden haben die Dauerschürfer zu belohnen und gleichzeitig Poolhopper zu bestrafen (grrrr!) =>

PPSPPT sieht wie folgt aus:

PPS: a = (eigene Shares / Gesamtshares) x 24% am Gesamtertrag
PPT: b = (((eigene Schürfzeit in der aktuellen Runde / aktuelle Rundenzeit) x (aktiv oder nicht)) / insgesamt aktive Miner bei Blockfund) x 75%

c = a + b = Ertrag

-----------------------------------------------------------------------------

Wer jedoch gerne last(n)-Shares mit dabei haben will, dann schaut's so aus:

PPSPPTPPLNS

PPS: a = (eigene Shares / Gesamtshares) x 24% am Gesamtertrag
PPT: b = (((eigene Schürfzeit in der aktuellen Runde / aktuelle Rundenzeit) x (aktiv oder nicht)) / insgesamt aktive Miner bei Blockfund) x 50% am Gesamtertrag
PPLNS: c = (eigene last-Shares im last(n)-Shares-Fenster / Gesamt-last-Shares aller Miner im last(n)-Shares-Fenster) x 25% am Gesamtertrag

d = a + b + c = Ertrag


PPT würde nur die belohnen, die auch während des Blockfundes dabei waren.
Alle anderen kriegen nur PPS + eventuell noch aus PPLNS was. Usw. und so fort...

-----------------------------------------------------------------------------

An den Prozenten könnte man noch etwas schrauben.

Wer Fehler findet darf gerne verbessern, dran herumhantieren, ... und hier dann die Verbesserung reinposten.

Wer die extreme Anti-Poolhoppermethode nehmen will der nimmt -> PPSPPT
Wer sie nicht gar so arg bestrafen will, die bösen Poolhopper der nimmt -> PPSPPTPPLNS

Und wer die Godlike-Anti-Poolhopper-Methode nehmen will, der lässt einfach PPS weg und bastelt sich 'ne Formel mit PPT+PPLNS oder die krasseste mit nur PPT.

Have fun!^^

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 08:12:49 PM
 #92

Oder wir machen es so, das sich jeder selber entscheiden kann wer welche Methode haben will.
Dann wird ganz einfach noch eine Fee für jeden angepasst, wie bei Deepbit.

PPS (8% Gebühr) - dafür wird jeder Share gezählt
PPT (1% fee)
PPLNS (1% fee)
PPSPPT (1% fee)
PPSPPTPPLNS (1% fee)
PPLNS (1% fee)

usw.


yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 08:24:44 PM
 #93

Eine kleines Verbesserungsbeispiel wäre:

PPS:a = (eigene Shares / Gesamtshares)
PPT: b = (a x((eigene Schürfzeit in der aktuellen Runde / aktuelle Rundenzeit) x (aktiv oder nicht)) / insgesamt aktive Miner bei Blockfund) x 50%
PPLNS: c = (eigene last-Shares im last(n)-Shares-Fenster / Gesamt-last-Shares aller Miner im last(n)-Shares-Fenster) x 25%

d = a x 24% + b + c = Ertrag

yetis
Member
**
Offline Offline

Activity: 112


View Profile
July 15, 2011, 11:30:08 PM
 #94

So.

Nachdem mir redd die einfache und simple Formel für PPLNS dargelegt hat, revidiere ich meine ganzen Posts, und komme zu dem Schluss das PPLNS eine gute Alternative wäre.

PPLNS = Pay Per Last N Shares.

Beispielsweise:
X = Deine Shares in den letzten N Shares

Auszahlung bei gefunden Block = X * 50 BTC / N

-- redd





nebiki
Full Member
***
Offline Offline

Activity: 154


View Profile
July 16, 2011, 12:05:11 AM
 #95

So.

Nachdem mir redd die einfache und simple Formel für PPLNS dargelegt hat, revidiere ich meine ganzen Posts, und komme zu dem Schluss das PPLNS eine gute Alternative wäre.

PPLNS = Pay Per Last N Shares.

Beispielsweise:
X = Deine Shares in den letzten N Shares

Auszahlung bei gefunden Block = X * 50 BTC / N

-- redd

Smiley falls es unter all den ueberlegungen untergegangen sein sollte, hier nochmal der verweis auf die poolhopper-geschichte: https://forum.bitcoin.org/index.php?topic=3165.0

man muss ja noch dazu sagen, dass der eigentliche grund, pooled mining zu betreiben, ja die geringere varianz ist. deswegen halte ich eine loesung wie bei eligius doch am elegantesten. sollte nach einer relativ hohen difficulty-erhoehung der pool noch "vermoegend" sein, kann man sogar events mit reserven anstellen Smiley will nur mal in den raum werfen, dass man fuer 15-25 coins schon ne gute mining-karte bekommt. gibt natuerlich auch die langweiligere methode, einfach den satz pro share dann etwas anzuheben, bis nur noch die notwendige reserve uebrig ist.

1DWttUPMiDL1ou64SoUriZ29bxdoChjPns
bluetowel
Sr. Member
****
Offline Offline

Activity: 246



View Profile
July 16, 2011, 05:02:51 PM
 #96

So.

Nachdem mir redd die einfache und simple Formel für PPLNS dargelegt hat, revidiere ich meine ganzen Posts, und komme zu dem Schluss das PPLNS eine gute Alternative wäre.

PPLNS = Pay Per Last N Shares.

Beispielsweise:
X = Deine Shares in den letzten N Shares

Auszahlung bei gefunden Block = X * 50 BTC / N

-- redd





und wieviele shares würde man so für N einsetzen für einen ca 100ghash pool?


ooo Legalize it ooo
redhatzero
Full Member
***
Offline Offline

Activity: 126



View Profile
July 16, 2011, 05:27:12 PM
 #97

normalerweise hat N was mit der difficulty zu tun.
Mineco.in nimmt glaub ich Difficulty/2

X68N
Hero Member
*****
Offline Offline

Activity: 546


View Profile
July 16, 2011, 08:21:55 PM
 #98

Also ich hab gehört das es bei Katholiken eine Sünde ist und blind macht, genau wie masturbation ;-)
ein Hinweiß schreckt bestimmt einige Hopper ab.

Coinbase - All your money are belong to us  Cheesy -> http://de.wikipedia.org/wiki/All_your_base_are_belong_to_us
bluetowel
Sr. Member
****
Offline Offline

Activity: 246



View Profile
July 17, 2011, 09:06:54 AM
 #99

normalerweise hat N was mit der difficulty zu tun.
Mineco.in nimmt glaub ich Difficulty/2

last n shares = diff/2

wovon dann last n shares? l.n.s. aus dem gesamten netzwerk oder l.n.s. des pools?
ich nehm mal an des pools....

ooo Legalize it ooo
redhatzero
Full Member
***
Offline Offline

Activity: 126



View Profile
July 17, 2011, 11:34:24 AM
 #100

normalerweise hat N was mit der difficulty zu tun.
Mineco.in nimmt glaub ich Difficulty/2

last n shares = diff/2

wovon dann last n shares? l.n.s. aus dem gesamten netzwerk oder l.n.s. des pools?
ich nehm mal an des pools....

Last n Shares der runde, also werden nur noch z.b. Die letzten 700.000 Shares zur Verteilung benutzt anstatt alle x Millionen

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!