Hi, ich nutze den offiziellen Client in Version 0.3.22 (Ubuntu) und habe heute festgestellt, dass neue Adressen im Adressbuch unter 'Receiving' auftauchen, welche ich nicht angelegt habe. Kennt jemand das Problem bzw. ist das normal? Leider kann man die Adressen auch nicht löschen, oder gibt es da einen Weg ohne Gui?  ich kann das bestätigen. es ist zwar nur 2 mal passiert, aber immerhin. (win7/64_btclient0.3.24b) ich hab mir nichts weiter bei gedacht, er hat halt eine neue addy aus der wallet gezogen, die da wohl schon eh drin ist..... ...anbei kann ich auch mal erwähnen, dass ich immer zu 100% eine fehlermeldung beim erstmaligen öffnen des adressbuches nach einem neustart des clients bekomme. ich weiss grad nicht ausm kopf was drin steht aber es klingt doll  ich klick dann weder auf OK noch auf NEIN sondern auf Abrechen. dann verschwindet die fehlermeldung und ich kann normal auf das adressbuch zugreifen. falls es jmd interessiert kann ich mal ein snapshot von der meldung machen... |
|
|
|
der letzte post von btcLeger ist ein guter versuch das ganze hier in die richtige richtung zu lenken, macht was draus ihr schlauen köpfe...  Warum wird nichts gegen die immer gleichen Probleme unternommen? Immerhin sind doch 90% der Probleme immer die gleichen. ja,... schau dich mal in der welt um, und stell deine frage dann nocheinmal... |
|
|
|
Prost!... |
|
|
|
Von mir auch vielen Dank für die geleistete Arbeit. Das hier war der Beste Pool. ...jo stimmt, der beste pool.... ...ich bedanke mich auch schön bei dir. |
|
|
|
na nu mach schon den link hier rein oder sag uns wenigstens dein eBayNick ...... |
|
|
|
...puhh, der bruder wars.......alles nochmal gutgegangen... |
|
|
|
Ich hab auch bisher kein Vorschlag gesehen der es allen Recht macht, ...... ...das gerechteste wäre wohl - so kam mir neulich in den sinn - das gesamte p2p bitcoin-netzwerk so umzugestalten, dass keine pools mehr nötig wären. jeder wäre immer an jedem block nach seinem %anteil beteiligt. das gesamte netzwerk wäre ein grosser pool mit pps. es gäbe dann kein hopping mehr und alles wäre super gerecht ....vielleicht auch langweiliger.... k.a. |
|
|
|
......... Hopper verdienen mehr.
eventuell vielleicht...... |
|
|
|
|
schuhu - TH-R19049
Romep - TH-R19610
nemesis51- TH-R19626
restore - TH-R19728
ByteCoinFan - TH-R110165
betropie - TH-R110959
realhuette - TH-R111219
esmog - TH-R111474
Schleicher - TH-R111617
ewibit - TH-R114143
wareen - TH-R114158
bluetowel - TH-R114190
|
|
|
|
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.... |
|
|
|
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? |
|
|
|
|
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.
|
|
|
|
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. an alle, die meinen, poolhopper sind nich schlimm und jeder share soll gleichviel wert sein: ihr solltet erstmal den post lesen, den redhatzero gelinkt hat. PPLNS ist fair und hat keinerlei nachteile. kannste das auch begründen? mit nur so einer behauptung kann niemand etwas anfangen. und redhat0 würde sich freuen wenn du uns mehr details über pplns liefern könntest.  |
|
|
|
es gibt nicht wirklich einen grund etwas gegen poolhopping zu unternehmen, die gründe die hier dafür angegeben werden gibt es nicht. wir müssen damit leben und nichts dagegen tun. es ist die freiheit der entscheidung des miners wann und wo er mint. das ist ein grundrecht und ich nehme auch diese frage des poolhopping zu anlass um ein bitcoinspezifisches grundrecht zu formulieren: "ein share ist ein share, egal wann er erzeugt wurde" wenn wir anfangen um den wert eines shares zu feilschen aus welchen gründen auch immer, dann wird viel ungerechtigkeit in der bitcoin-community entstehen. einer hat gesagt: "typisch deutsch, wie können wir es noch gerechter machen". und am ende wird immer alles nur ungerechter. ich sag euch solche sachen gehen immer nach hinten los. als wir in block 23 waren und der auch wieder auf die 2mio. zu ging ist die hashrate im pool um ca 20ghash gesunken, mein eigener anteil erhöhte sich noch um ca. 20% - soviel zum argument: belohnung der treuen. danach hatten wir block 24&25 in ca 9 std. da war die hashrate ähnlich niedrig, und ich hab mich gefreut, erst in block 26 stieg die hashrate wieder. ich glaube nämlich nicht das man mit poolhopping seinen ertrag wirklich maximieren kann, dass macht man nur - wie einer schon sagte - wenn der stammpool down ist, oder mal wegen der abwechselung. beim glücksspiel sollte man - hat mir mal einer erklärt - sich immer entscheiden ob man mit der bank oder gegen die bank spielt, man sollte aber nie zwischen beiden switchen. eine goldene glücksspielregel - hat mir mal einer erklärt - und es stimmt und weil ich an diese glücksspielregel glaube, weiss ich auch das pollhooper, sofern sie es denn wegen gewinnmaximierung tun - am ende weniger haben als sie dachten. man muss einfach darauf vertrauen, dass im netzwerk die prozentuale aufteilung der shares in bitcoins immer genug gerechtigkeit für alle bringt, sofern man den wert eines shares unangetastet lässt. ich schliesse mich dann auch meinem vorredner an: Klar, soll jeder tun und lassen, was er will. Ich bleibe im Pool und rechne da vor mich hin.
und wer auch immer redhatzero da bedrängt hat: Blödmann.
was redhatzero da in wenigen Tagen auf die Beine gestellt hat verdient Resprekt. |
|
|
|
So.. Blockmäßig gefällt mir der Tag heute sehr gut  mir auch ja da freut man sich edit: und das ich seit über 38 std. keine stales mehr hab freut mich auch..... fettes lob an unseren pool-macher redhatzero |
|
|
|
Das mit dem "die user sollen sich nen Pit suchen" halte ich für schwierig, ich glaube es haben nicht viele Lust, öfter mal die config zu ändern.
Dem stimme ich voll zu. GUIMiner unterstütz seit der letzten Version x8s Native. Seit dem ist es gar nicht möglich den Server manuell einzustellen. Es sei denn ich stelle im GUIMiner den Pool nicht auf x8s sondern auf "other". Da hab ich aber eigentlich gar keine Lust drauf  so ein neuer reiter ist in sekundenschnelle angelegt.... wo ist das problem? ich hab gleich für alle drei server reiter gemacht, dann kann ich schnell switchen. ich mein auch, jeder user der in der lage ist seine grafikkarte zum minen zu benutzen, sollte auch in der lage sein sich ein pit zu suchen |
|
|
|
Update:
* rememberMe sollte gefixt sein
Danke, bei mir gehts jetzt. Hier scheint es jetzt auch zu funktionieren, Safari und Firefox aufm Mac getestet. Danke! dto. Hier gehts jetzt auch. jo, passt |
|
|
|
so, kleines update - RememberMe Cookie umbenannt - Jeder muss sich jetzt neu einloggen, dafür sollte dann aber auch überall das RememberMe wieder funktionieren
Bitte Feedback zu Punkt 4, falls es da noch immer Probleme gibt. hi. ja bei mir geht es schon seit einer woche so. neu anmelden alle 30 min. ca. habe auch schon cookies gelöscht, funzt aber net Ist das Cookie nach ca. allen 30 Minuten überhaupt noch vorhanden? Welcher Browser? Falls Firefox genutzt wird, ist da ein Addon installiert das Deinen Cache/History/Cookies/etc. regelmässig automatisch löscht? Vielleicht irgendwo ein Tool im Hintergrund, dass Deinen Browsercache leert, etc. zeitbasiert, usw. Cookieblocker vielleicht? Wenn du eine Firewall nutzt, dann schau mal da nach, ob da was vorhanden ist, Anti-Phishing, Antitracking-tools, benutzt du http oder https (könnte auch am Cache liegen, dass SSL-verschlüsselte Seiten nicht zwischenspeichert auf der Platte), vielleicht hast du auch eine Einstellung vorgenommen, die Cookies von Erstanbietern blockt, hast Du auch die richtigen Cookies gelöscht, in Firefox gibt's 'ne Einstellung unter Datenschutz "Cookies akzeptieren" <-- Haken rein, und so weiter... ...ohne die einstellungen an meinem rechner win7/firefox5 zu verändern, hat sich das verhalten der remember me funktion verändert. |
|
|
|
na endlich ist der block gefunden ...
war längste bis jetzt aber immer noch unter difficult ^^ die glückssträhne geht weiter ...
der 14. topt das jetzt, gleich 2mio shares...... .....aber die glückssträhne geht auf jedenfall weiter ;-) *daumdrück |
|
|
|
so, kleines update - RememberMe Cookie umbenannt - Jeder muss sich jetzt neu einloggen, dafür sollte dann aber auch überall das RememberMe wieder funktionieren
Bitte Feedback zu Punkt 4, falls es da noch immer Probleme gibt. hi. ja bei mir geht es schon seit einer woche so. neu anmelden alle 30 min. ca. habe auch schon cookies gelöscht, funzt aber net |
|
|
|
|
Show Posts
