Alle die sich bis jetzt mit ihrer BTC Adresse gemeldet hatten wurden eben ausbezahlt!
Bitte euren Trust nicht vergessen (ich gebe meinen dann am Ende wenn ich alle ausbezahlt habe)
Zahlung erhalten. Vielen Dank. Trust ist eben raus. |
|
|
|
So eine Order läuft --> 0.0045 BTC pro THs / Tag Nun endlich ins Bettchen, wollte vor einer Stunde schon weg sein, aber die Nacht ohne Order, ging irgendwie auch nicht  Danke für deinen Einsatz! |
|
|
|
|
{"hashrate1m": "520T", "hashrate5m": "527T", "hashrate1hr": "511T", "hashrate1d": "488T", "hashrate7d": "230T", "lastupdate": 1456235504, "shares": 43617005886, "bestshare": 978'318'151.11443806, "bestever": 252251073806}
|
|
|
|
Habe gestern abend dem con den Fehler mitgeteilt, wußte er schon und er Ändert es nicht(!) mit der
Begründung: der pool.status wäre für ihn und nicht für die Allgemeinheit, keine Daten von Interesse oder
Nutzen. Ich glaube er war nicht so gut gelaunt...
Ich habe noch darauf hingewiesen das es ja den ckpool source allgemein betrifft, also z.B. auch meinen
Pool, aber er will nicht. Für meinen Pool habe ich das gestern schon geändert, aber beim solo bleibt halt nur
die "krücke". Schade. Ein Versuch war es Wert.
Ok danke, dass du ihn darum angesprochen hast. Vielleicht korrigiert er das ja trotzdem einmal. Mit PHP ist das nun eigentlich gar kein Problem mehr. Ich kann damit leben. Benutzt du deinen Pool nur selber oder darf man da seinen Miner auch drauf lassen? |
|
|
|
Das habe ich auch gesehen, voll krass! Ich käme da höchstens auf eine Share pro Woche  Was ist, wenn man so einen Block findet? Kann man das (aptippen und) manuell über eine Node ins Netzwerk schicken? |
|
|
|
ein mining gerät geht doch einzelne Hashes durch. Desto schneller der Miner, desto schneller geht er auch die einzelnen hashes durch. doch wer sagt dem miner, welche hashes er überprüfen soll und in welcher Reihenfolge er die hashes abarbeitet? kann man das beeinflussen? ob er jetzt von a oder y anfängt
Hi Denizs Nach meinem Verständnis muss ein Miner, um einen gültigen Share zu bekommen, den Header (und noch weitere Dinge) zweimal mit SHA-256 hashen. Also im Sinn von: SHA256(SHA256(Blockheader + Nonce)). Der Blockheader kommt vom letzten gefundenen Block, da ja alles auf die vorherigen Blöcke aufbauen muss (das ist das chain in Block chain). Der Miner fragt beim Pool nach einer "Arbeitsvorlage" und bekommt diese zugeschickt. Darin ist dann der Header des letzten Block zu finden, den es zu hashen gilt. Der gehashte Header und die zusätzlichen Informationen müssen dann einen Hashwert ergeben, der höher als die aktuelle Difficulty liegt (mehr '0' am Anfang der Zeichenkette haben). Dann wurde ein Block gefunden. Ist der Hash, der gerade ausgerechnet ist, kleiner als die Diff (also kein Block gefunden), dann wird die Nonce verändert (erhöht) und nochmals mit der letzten Arbeitsvorlage gearbeitet. Erst wenn der nächste Block gefunden wird, müssen die Miner vom Pool eine neue Vorlage anfordern, da sich nun ja der Header des letzten Blocks geändert hat. Damit ein Miner nun beweisen kann, dass der eben gefundene Hash auch wirklich von ihm stammt, wird zum Header auch noch die Nonce gehasht. Eine Nonce ist nichts anderes als eine Zufallszahl oder zufällige Zeichenkette. Die Idee dahinter ist, dass nur derjenige Miner, welcher den Block gefunden hat, die Nonce kennt und somit beweisen kann, dass er die ganze Hash-Arbeit geleistet hat und nicht jemand anderes. Das ist das Proof-Of-Work, was grundsätzlich soviel heisst wie: Die notwendige Arbeit um einen Block zu finden kann nicht erlogen oder vorgetäuscht werden. Nur derjenige, der wirklich die Arbeit (Hashleistung) geleistet hat, kann die Nonce zum aktuellen Blockheader wissen. Es gibt einige Firmware für Miner welche behaupten, man finde mit diesen schneller einen Block. Aber das ist alles Quatsch. Man kann einen Miner nicht wirklich beeinflussen, dass er schneller auf die richtigen Nonces kommt. Zum Glück ist das nicht beeinflussbar! Ein Grund ist der benutzte Hash-Algorithmus SHA265, der immer einen gleich langen Hash generiert, egal was für eine Menge an Daten eingespielt wurden. Es ist auch nicht möglich, aus dem Hash die Ausgangszeichenkette zu errechnen (ausser mit Brute-Force). Ausserdem wird der Hash komplett anders aussehen, wenn bei den Eingangsdaten auch nur ein Bit geändert wurde. Auf unser Lotto Run gemünzt heisst das, dass wir unser Glück nicht wirklich beeinflussen können. Ich hoffe, ich hab da nichts durcheinander gebracht. Korrekturen und Ergänzungen willkommen  |
|
|
|
Bestshare hängt fest :-/ Die Shares hängen nicht davon ab, wie viele im Pool mit minen oder? {"runtime": 1376646, "lastupdate": 1456085119, "Users": 382, "Workers": 941, "Idle": 335, "Disconnected": 68}
{"hashrate1m": "1.34P", "hashrate5m": "1.27P", "hashrate15m": "1.26P", "hashrate1hr": "1.28P", "hashrate6hr": "1.36P", "hashrate1d": "1.32P", "hashrate7d": "1.48P"}
{"accepted": 242103604840, "rejected": 262390789, "bestshare": 24072982155, "SPS1m": 197.07902309677661, "SPS5m": 195.90629751545347, "SPS15m": 195.30409391368437, "SPS1h": 195.70898345756484} Also unser Glück ist nicht von anderen abhängig. Wenn mehr im gleichen Pool minen, dann steigt eben einfach die Wahrscheinlichkeit für den Pool als ganzes, für den einzelnen Miner jedoch ändert sich nichts. Das hat keine negativen Auswirkungen auf uns. |
|
|
|
Aber Grundsätzlich ist diese Form der Ausgabe einfach nicht konform!
EDIT:
Ich hätte gerne nur eine Zeile { xx : xxx, ... } dann wäre es doch deutlich Unkomplizierter!
Genau! Wer einen guten Draht zu -ck hat, kann ihn ja mal darauf aufmerksam machen   |
|
|
|
Die Ausgabe der Stats des ckpools ist kein valides JSON. Wenn man versucht, den ganzen String (es sind insgesamt 4 Zeilen) als JSON-Objekt zu behandeln kann das nur scheitern. Ich denke da werden aus drei verschiedenen Modulen Stats geladen und ohne die richtige Syntax in eine "Ausgabedatei" geschrieben. Die einzelnen Ausgaben werden mit einem Zeilenumbruch getrennt. Das bricht JSON. Der Validator sagt " Multiple JSON root elements". Eigentlich muss um diese drei Stats (abgegrenzt mit {...}) um alles herum mit eckigen Klammern [...] ein Array gebildet und die einzelnen Stats mit einem Komma getrennt werden. Es gibt Probleme, nachdem er die erste geschweifte Endklammer findet, es danach aber trotzdem wieder (ohne vorherige Deklaration als Array) mit einem neuen Abschnitt weitergeht. Schaut euch mal den Source-Code der Stats an. @cagrund: In folgendem Beispiel wird anstatt file_get_contents() die Funktion file() benutzt, welche den Inhalt von der URL lädt und in ein Array schreibt, in dem jede Zeile einzeln in einem eigenen Array-Platz liegt. Danach kann jede Zeile wiederum einzeln in ein JSON-Objekt umgewandelt und normal als JSON-Objekt behandelt werden: $url = 'http://solo.ckpool.org/pool/pool.status';
$stats_array = file($url); // Lädt die Statistik und schreibt jede Zeile einzeln in einen eigenen Arrayplatz
$json = json_decode($stats_array[0], true); // Erste Zeile in ein JSON-Objekt umwandeln
echo $json["runtime"];
@o_solo_miner: Der Fehler 'Error4 CTRLCHR' (Control Char?) weist doch genau darauf hin, dass der String kein valides JSON ist und der Interpreter nach der ersten gefundenen geschweiften Endklammer ohne Komma direkt wieder eine geschweifte Klammer findet. Die geschweiften und eckigen Klammern, sowie das Komma sind doch (Syntax-)Steuerzeichen. Damit die ckpool Stats valides JSON wäre, müsste es so aussehen: [
{"runtime": 1368726, "lastupdate": 1456077199, --snip-- "Disconnected": 41},
{"hashrate1m": "1.31P", "hashrate5m": "1.31P", --snip-- "hashrate7d": "1.48P"},
{"accepted": 239759339040, "rejected": 259340121, --snip-- "SPS1h": 194.75517717118731}
]Die Änderungen sind in rot markiert, Mittelteile der Zeilen habe ich weggelassen und mit --snip-- ersetzt... Bis die Ausgabe der Stats geändert wurde, bleibt uns nichts anders übrig, als jede Zeile einzeln als JSON-Objekt zu behandeln. |
|
|
|
Hallo Carsten Ich glaube das JSON auf der Stats-Seite ist nicht ganz konform. Da es mehrere geschweifte Klammern hat, ist es in Wirklichkeit doch ein Array, welches mit den eckigen Klammern eingeschlossen und die einzelnen Elemente mit Kommas getrennt werden sollte. Versuchs mal mit dem: <?php
$url = 'http://solo.ckpool.org/pool/pool.status';
$data = file_get_contents($url);
$tmp = explode(' ', $data);
$runtime = trim(str_replace(",", "", $tmp[1]));
echo $runtime;
?>
Quick & dirty, aber es funktioniert. Edit: Habe gerade gesehen, dass die Stats auch Zeilenumbrüche enthalten. Somit sollte es möglich sein, nur die erste Zeile in ein JSON-Objekt umzuwandeln und den Wert auszulesen. |
|
|
|
|
{"hashrate1m": "932T", "hashrate5m": "818T", "hashrate1hr": "701T", "hashrate1d": "186T", "hashrate7d": "35.1T", "lastupdate": 1455909371, "shares": 5210234273, "bestshare": 15'345'894'093.538525, "bestever": 15345894093}
|
|
|
|
Ich habe gestern Nacht mit diesem Lüfterlärm geschlafen in der Hoffnung das ich schnellstmöglich wieder sync bin. So war jetzt der Rechner die ganze Nacht und den kompletten Folgetag über, bis jetzt 17:30 Uhr an. Aber aktuell heist es immernoch 2 Wochen im Rückstand :-( Wieso dauert das so übertrieben lange? Ich habe die Blockchaindateien via -datadir in einer anderen Partition aber das wird doch wohl nicht der Grund sein? Für einen Ratschlag wäre ich dankbar! Und wenn das ganze doch sowieso ca. 200h läuft dann könnt Ihr doch auch noch bis So/Mo auf mich "warten" oder nicht?  Beim Sync wird Block für Block heruntergeladen und jede einzelne Transaktion darin verifiziert. Das dauert sehr lange. Die Daten auf einer anderen Partition sollte nicht das Problem sein. Das habe ich bei mir auch so. Der problematischste Flaschenhals wird die CPU sein. |
|
|
|
|
500 TH wären cool.
@ english speaking guys: Some of us want a higher hashrate of 500TH. We should have enough coins to run 500TH for about 200 hours. What do you think?
|
|
|
|
|
{"hashrate1m": "267T", "hashrate5m": "283T", "hashrate1hr": "271T", "hashrate1d": "98.5T", "hashrate7d": "17.1T", "lastupdate": 1455877389, "shares": 2496986603, "bestshare": 10'367'537'251.435539, "bestever": 10367537251}
|
|
|
|
{"hashrate1m": "259T", "hashrate5m": "257T", "hashrate1hr": "246T", "hashrate1d": "64.7T", "hashrate7d": "10.5T", "lastupdate": 1455861369, "shares": 1510414296, "bestshare": 2599234314.7828307, "bestever": 2599234314} noch ca. 5 Stunden dann steigt unser Zielwert / der Diff https://bitcoinwisdom.com/bitcoin/difficultyEstimated Next Difficulty: 163,471,924,639 (+13.43%) Zwar nicht ganz so hoch wie gedacht aber trotzdem nicht wenig... Hashrate(?): 1,121,384,701 GH/s   This is crazy... |
|
|
|
Lass ihn mal an, das dauert ewig...
Könnte das noch klappen oder wie schnell war das bei den Durchgängen zuvor? Kannst ja mal schauen, wie weit dein Rechner in 10 oder 20 Minuten mit der Synchronisierung kommt, dann können wir hochrechnen |
|
|
|
Bin ich jetzt raus?
- wenn keiner was dagegen hat und die coins noch unter dem Run ankommen, ist er mit drin (vorausgesetzt keiner hat was dagegen) bitte um eine kurze Info... wenn du weist was mit deinen Coins passiert ist Wenn keiner etwas dagegen hat dann entscheide ich mich natürlich für die oben fett markierte Variante. Sollte der Rechner über Nacht an bleiben? Wie weit ist deine Wallet nun gesynct? |
|
|
|
If there is a vote... I'd say 500T, but as the majority decide as you say Same here, for some reason I thought I saw that on the topic that it would be 500TH as long as the coins remained but I don't see it anymore. Yes it was like this. But the majority of the participants want slower, therefore longer. Post your opinion! Edit: The stats link also changed, because of the old best share value of a previous run: http://solo.ckpool.org/workers/1Q8VghUJkNeFnaKy553b9buUWKxFYL579G_megalotto2 |
|
|
|
Geil, dann hau rein die Sch** |
|
|
|
|
Show Posts
