Suspekt suspekt..

Ist total egal, welchen Pit du benutzt, am Ende laufen die Shares zusammen

na, wie gesagt, ich füg auch noch gerne weitere Möglichkeiten dazu, wenn sie genannt werden

nix gegen vServer der lief bei mir prima mit bis zu 40Ghash/s .. und wenn auf dem vServer nur bitcoind+pushpool laufen, hab ich das auch schon bis 100GHash hochbekommen


Bei blockhistory https://poolmunity.com/blockHistory.php ist noch ein Bug:

Die Duration wird als "Jan 06 11:35:35" angegeben...

Die Balken sind jetzt irgendwie logarithmisiert Auch wenn's jetzt von den Proportionen nicht mehr ganz stimmt, ist es denke ich mal ein guter Kompromiss

Bitte einen Blick auf http://forum.bitcoin.org/index.php?topic=28848.0 werfen

Nachdem mir fast das Messer an die Brust gelegt wurde, dass ich doch was gegen Poolhopper machen soll und ich das Thema bereits im IRC angesprochen habe, eröffne ich jetzt hier eine Abstimmung über die Maßnahmen.

Aus meiner Technik Sicht, wäre ich für entweder keine Änderung ('nichts' ist am einfachsten umzusetzen..., aber evt. auch das unbefriedigendste) oder für PPLNS (geringe Änderungen, kann schnell umgesetzt werden).

Was ist Pool Hopping?
http://forum.bitcoin.org/index.php?topic=24966.0 (Englischer Beitrag, Im Prinzip geht es darum, dass Leute den Pool wechseln, wenn die aktuelle Runde zu lange dauert, mit dem Versuch ihren Ertrag zu optimieren)

Was ist PPLNS?
http://eligius.st/wiki/index.php/Pay_Per_Last_N_Shares (Englischer Beitrag, Zahlung wird nur anhand der letzten N Shares vorgenommen, wobei es bei kurzen Runden auch passieren kann / bzw. so gewollt ist, dass Shares für mehrere Runden gezählt werden)



Ein gutes Argument gegen eine Änderung ist "Wenn ich ein Share abliefere, dann will ich auch, dass wer was Wert ist, und nicht nach einer Zeit x wertlos wird"
Ein Argument für eine Änderung wäre: "Ich will nicht, dass andere auf meine Kosten ihren Gewinn maximieren"


Ich bin in der Sache neutral (abgesehen von meiner Technik Sichtweise) ich sehe gute Argumente für und gute Argumente gegen eine Änderung.
Deswegen würde ich das ganze zur Wahl stellen (gerne auch mit weiteren Lösungsmöglichkeiten)

Nachdem ich leider gerade nicht so viel Zeit habe, ausführlich über PoolHoping, PPLNS bzw. Score Based Auszahlungen zu schreiben, würde ich mich auch freuen, wenn von euch jemand mehr Details dazu liefern könnte.

Och nö (

Pushpool

So.. Blockmäßig gefällt mir der Tag heute sehr gut

Als ich damals die patches für guiminer geliefert habe, bin ich auch noch davon ausgegangen, dass sich alles über pit.x8s. regeln lässt

Ich will aber auch nicht wie BTCGuild (oder, das waren die?) 5 Server Einträge im GUIMiner haben.

Naja, mal sehen... es wird sich schon ne Lösung finden, mit der wir alle zufrieden sind

Gz zum Block & Der Link ist schon wieder verschwunden

wart lieber noch, ich werd ne json api basteln, die den server status zurückliefert.

Roundrobin ist nicht, da kann's passieren, dass der Client sich von Server A Arbeit holt und das Ergebnis an Server B sendet (und damit ist es ungültig).
Ich hatte ein DNS basiertes Verfahren ähnlich zu GeoIP eingesetzt, wo aber auch das Problem war, dass gerade bei großen Providern die User Anfrange über mehrere DNS Server kommen, die dann evt. auch an unterschiedliche Server weitergeleitet werden.

In Sachen Reverse Proxy hab ich als wir auf den neuen Server gezogen sind bereits mal HAProxy ausgetestet, das wäre prädestiniert für solche Sachen, leider ist es nicht ganz so leicht sowohl für viele kleine kurze Verbindungen (=getwork) als auch für einige lange (=Longpolling) das beste rauszuholen.

Datenbankmäßig ist soweit alles im grünen Bereich, ich arbeite recht viel mit NoSQL basierten Techniken.

Das DNS Loadbalancing gefällt mir eigentlich am besten, evt. werd ich das zumindest halb wieder einführen (als Anti-DDOS Maßnahme ist das in meinen Augen das sinnvollste)
und ich werd auch HAProxy wieder eine Chance geben

Im Moment setze ich drauf, dass die User freiwillig sich einen unausgelasteten Pit suchen


Und btw: neuer Block

Naja, nach 7mio war dann dort doch mal Schluss... Und der nächste hat dann ~87000 gebraucht, gleicht das ganze wieder ein bischen aus

Wenn's keinen Block gibt, müssen wenigstens Updates her :/

http://btc.x8s.de/topList

Alle Beteiligten an der aktuellen Runde

Das sind dann 'richtige' stales. Bisher war es so, dass Pushpool entschieden hat, ob ein Share Stale war oder nicht. Die Shares die bisher unter Stale gefallen sind, werden aber jetzt an den bitcoind weitergereicht (weil der das besser weiß als Pushpool) und der entscheidet dann ob's stale ist oder nicht. Auch wenn Bitcoin dann entscheiden sollte, dass der Share stale ist, wird er als valid gewertet (Die Arbeit ist ja trotzdem angefallen)

Als invalid werden aber weiterhin Shares gezählt, die der Pushpool entweder gar nicht ausgegeben hat oder wo versucht wird, Shares doppelt abzuliefern etc..

http://btcbase.com/2011/05/21/wie-kann-ich-bitcoins-nutzen/

Das beantwortet jetzt zwar nicht direkt deine Fragen, aber das ganze btcbase.com blog ist schon mal ein guter anfang

so, update:

* neben API Key gibt's jetzt auch noch den PublicKey im Profil, letzterer wird für die Userbar+öffentliche Profile benutzt (jeder der eine Userbar eingebunden hat, muss jetzt leider auch die URL ändern...)
* erste Alpha der öffentlichen Profile:

http://btc.x8s.de/profile/<public key>
z.B. http://btc.x8s.de/profile/f436063f4a25bab0ec13438db5541821

Die öffentlichen Profile sind noch ganz weit weg von dem, was ich mir vorstelle... Aber ihr habt in dem frühren Stadium jetzt noch jede Menge Einfluss darauf, also.. her mit Ideen + Vorschlägen

pit2.x8s.de ist ein vServer, der aber ziemlich stabil läuft (testweise hatte der schonmal ~80% des gesammten pool traffics)
pit.x8s.de ist der Hauptserver, der zwar in Theorie mehr Power als der vServer hat, aber auch noch andere Aufgaben hat.

Eine Anmerkung wäre noch, dass auf pit2 ein neuer bitcoind läuft, der zwar auf dem Testnet einwandfrei funktioniert, aber unter realen Bedingungen noch keinen Block gefunden hat (was nix bedeutet, aber 100% trau ich dem ganzen erst, wenn der nen Block findet)

Wenn pit2 vernünftigt läuft (und auch den ersten Block gefunden hat) werde ich pit.x8s.de auch auf einen vServer umziehen, so dass der Hauptserver sich nur noch um die Datenbank kümmern muss.


Die FAQ etc werde ich demnächst ändern

So,

nachdem das Problem mit den Stales gelöst ist, werde ich morgen die EC2 Instanz wieder abschalten.

Ab dann bitte nur noch
pit.x8s.de
oder
pit2.x8s.de

verwenden.

Danke