Topic: Deutschsprachiger Pool btc.x8s.de ~110Ghash/s - page 31. (Read 167736 times)

Das erinnert mich an (mir fällt jetzt der Fachausdruck leider nicht ein):
Der der mehr für's Routing im Web bezahlt und braucht an Netzwerkleistung der bekommt auch das schnellere Routing im Web.
Kann auch sein, dass Hetzner eigene oder gemietete Nodes/Backbones hat, um z.B. die RZ miteinander zu verbinden.

Dann wäre das schonmal geklärt. Schneller Server, guter Daemon und 'n guter Ping. Dann können die BTCs ja eintrudeln.

Ok. Sind beide gleichschnell zu mir.

ne, mein server ist da nicht drauf, weil ich ja von dem aus gepingt hab wenn du x8s pingen willst, dann ping btc.x8s.de an

Wenn der zweitletzte Deiner ist, dann sehen wir auch ungefähr die Routing-Geschwindigkeit im Netzwerk selbst?!?
Btw. hab mal deepbit und zweitletzten angepingt und verglichen, und dabei festgestellt, dass der zweitletzte knapp 2 ms schneller ist zu mir.
Kann natürlich auch Toleranz sein.

Ja, deswegen sage ich ja, dass ich davon ausgehe, dass deepbit (bzw. zumindest dieser eine jene Server von deepbit) und x8s im gleichen Rechenzentrum stehen (was für bzw. gegen invalid blocks nur gut sein kann)

Edit: ich hab grad nochmal ein paar andere Server von denen ich weiß, in welchen Hetzner RZ die stehen angepingt, und es ist recht egal, auch über verschiedene RZ hinweg sind die Pingzeiten < 1ms

Sieht so aus als hättest du den Deepbit vom Rechenzentrum aus intern angepingt?!? weil die ms stark gering sind.

Y ist ne arme Sau

Auch eine gute Erklärung, redhatzero.^^

X hat zum Beispiel ein Schneemobil (vergleichbar mit dem Ping im Netzwerk) und Y muss zu Fuss laufen.

mal ein paar ping tests zu fallback nodes ( https://en.bitcoin.it/wiki/Fallback_Nodes ):

PING mining.bitcoin.cz (178.79.179.32) 56(84) bytes of data.
64 bytes from li348-32.members.linode.com (178.79.179.32): icmp_req=1 ttl=52 time=20.1 ms

PING fallback2.bitcoin.me.uk (178.255.199.86) 56(84) bytes of data.
64 bytes from hosted-by.snelis.com (178.255.199.86): icmp_req=1 ttl=56 time=14.7 ms

PING 109.75.176.193 (109.75.176.193) 56(84) bytes of data.
64 bytes from 109.75.176.193: icmp_req=1 ttl=58 time=6.52 ms

PING deepbit.net (46.4.121.119) 56(84) bytes of data.
64 bytes from static.119.121.4.46.clients.your-server.de (46.4.121.119): icmp_req=1 ttl=60 time=0.266 ms



Letzteres dürfte mit ein Grund sein, warum wir bisher keine Probleme mit invalid hatten. Ich geh davon aus, dass die deepbit server (bzw. zumindest der eine) im gleichen Rechenzentrum wie der x8s Server stehen.

Gut. Der Traffic läuft also auf einer einzigen 100 Mbit-Anbindung vom und zum Server!? Wir haben also bei der Bandbreite Luft nach oben. Interessant wäre in dem Fall wie schnell die Anbindung (Ping) ist, und nicht die Bandbreite. Je schneller Dein Server feuert und einsteckt, desto besser. (Wg. Blockbekanntgabe, etc.)

Kann er leider schon, auch wenn das aber eher der ausnahmefall ist:

Es gibt einen.. *hm*... Schneekugelsammler =)
Der sammelt durchnummerierte Schneekugeln.
Er gibt den Auftrag für Schneekugel 1 raus, Schneekugelhersteller X baut diese gibt sie zum Schneekugelsammler, von dem er dafür 50 BTC bekommt.
Schneekugel 2 macht Y .. Y bekommt 50 BTC...
etc etc etc...
So, jetzt passiert's aber, dass X+Y gleichzeitig die Schneekugel Nummer 1523 bauen, sie gehen von ihrer Werkstatt zum Schneekugelsammler.
X ist als erstes da, er bekommt die 50BTC
Jetzt kommt Y, der aber auch eine "gültige" Schneekugel mit der gleichen Nummer 1523 hat, aber der Schneekugelsammler mag halt von jeder Nummer immer nur eine Kugel..
deswegen geht Y leer aus.


Bei Bitcoins ist es dann so, dass es zwei Blöcke 1523 (1523.a und 1523.b) gibt. Wenn jetzt Block 1524 gemacht wird, hat er einen Verweis auf den vorherigen Block, wenn da jetzt 1523.a steht, dann hat eben .a gewonnen.

Das ganze könnte durchaus über mehrere Blöcke gehen. Deswegen sollte man ja auch 2-6 Confirmations (=neue Blöcke) warten bis man erhaltenen Bitcoins auch wirklich vertraut.

geht wieder? (zumindest bei mir)

Das war wieder das DB Backup... Wenn das läuft akkzeptiert der Pushpool irgendwann keine Verbindungen mehr bis das Backup fertig ist
(Bin grad dabei das Backup auf den Slave zu schieben)

Wegen Flaschenhals Netzwerk:
Laut Trafficstats haben wir wenn's viel ist 600MByte Traffic (Incoming+Outgoing) pro Stunde. Das sind ~1,33MBit/s wenn ich mich nicht verrechnet habe. Der Server ist mit 100MBit angebunden

Ich habe mir die letzten Posts  kopfschüttelnd durchgelesen und muss wieder einmal feststellen, wie wenig ich das BTC-Prinzip verstanden habe.
Wieso ist es möglich, dass ein gefundener Block durch einen anderen Pool ungültig wird?
Ich fand  den Vergleich mit Goldschürfen immer ganz passend.
Kann man das in etwa auch so ausdrücken: Ich habe in dem Fluß etwas Gold gewaschen, da kommt plötzlich DeBeers (k, die machen mehr in Diamanten, aber auch in Gold) daher und sagt: Ich habe hier die Schürfrechte und nimmt mir die Nuggets weg?
Ein richtig berechneter Block kann doch nicht ungültig sein?
Na wie auch immer, macht weiter mit euerm TechTalk, kann man ja nur von lernen

x8s down?

edit:
Boah! Hab' schon 'nen Schock gekriegt als alle Karten und CPUs nur noch Connecting... angezeigt haben.
Gschwitzt hob i. 

Hmm... Ein Beispiel:

Du vergisst dabei, dass das Hashen im Nanosekundenbereich, während im Netzwerk die Übertragung im Millisekundenbereich erfolgt.
Das heisst, das nicht die Bandbreite entscheidend ist, sondern die Geschwindigkeit mit dem ein Client an Paketen versorgt werden kann, und der Server dementsprechend der Geschwindigkeit die Shares entgegennimmt und absegnet, etc.

Vielleicht ist diese Erklärung einleuchtender:
Eine typische Festplatte lädt und schreibt Daten mit 8 ms, während eine moderne und schnelle Solid State Drive die selben Daten mit 0,5 ms bereitstellt und abspeichert. Somit ist eine Applikation schneller geladen, das Betriebssystem bootet schneller, usw.

Typisches Flaschenhalsprinzip.^^

Edit: Und bei steigender Ghashleistung der Pools tritt immer mehr die Netzwerkleistung in den Vordergrund beim Rennen um Bitcoins, was früher zu vernachlässigen war, weil die Pools alle kleiner waren. Das kannst du übrigens in ganz wenigen englischen Threads nachlesen, soweit ich mich erinnern kann.

Okay, das klingt dann irgendwie gut.

Das ist ja das schöne an P2P wenn ich deepbit nicht erwische, dann wird's halt ein Node finden, an den ich meinen Block weitergeleitet habe. Das ganze geht ziemlich fix, ähnlich schnell wie bei Überweisungen (schau mal wie schnell eine Überweisung bei dir im Client auftaucht, wenn du dir von jemand anderes was schicken lässt).

Der Hash bzw. wie groß er ist hat meines Wissens nach keinen Einfluss drauf, welcher Block gewinnt. Sondern wirklich nur, welchen Block dann der als nächstes generierte als Vorgänger hat.

Sich zu deepbit zu verbinden würde da bestimmt schon auch Sinn machen, wobei ich davon ausgehe, dass es nicht "den Deepbit Server" gibt, sondern das auch auf mehrere Daemons verteilt ist, die man alle erwischen müsste.


Hier noch ein kleiner Quote zu dem Patch (den übrigens auch BTCGuild verwendet, insofern wird er schon nicht so schlecht sein ^^)

Am wichtigsten ist es wohl, gefundene Blöcke möglichst schnell an die großen Pools weiterzuleiten, damit diese nicht mehr versuchen, auf dem alten Block aufzubauen, sondern auf dem neuen von x8s. Falls sie nämlich noch 10 Sekunden länger an ihrem alten Block werkeln und dann doch noch einen weiteren darauf passenden finden, dann wird letztlich wohl der Block gewinnen, der einen kleineren Hash (=> schwieriger zu finden) hat.

Wenn dein bitcoind jetzt z.B. 500 Verbindungen hat, ist das IMHO vielleicht sogar kontraproduktiv. Ich habe meinen Client z.B. tagsüber fast immer an. Trotzdem bringt es dir überhaupt nichts, wenn du mir den Block schickst. Ich werde den zwar schön bei mir speichern, aber wenn dann 10 sec später ein noch schönerer (=> kleinerer Hash) von deepbit bei mir ankommt, verwerfe ich deinen wohl einfach wieder. Besser wäre es in dem Fall sogar dann gewesen, wenn dein bitcoind nur 1 Verbindung hätte, nämlich zu deepbit - der hätte dann nämlich sofort aufgehört, am alten Block weiter zu arbeiten, und damit wäre schonmal ein großer Teil des Netzwerkes nicht mehr dabei, "gegen" x8s zu arbeiten, sondern "für" deinen Block.

Wenn x8s jetzt so viele Connections offen hat, dass es (Zahl total aus der Luft gegriffen.. aber ich denke mal das läuft nicht parallel ab?) 20 Sekunden dauert, um den Block an alle Verbindungen zu schicken - eigentlich aber 5 Sekunden reichen würden, um den Block an die großen Pools zu schicken, dann wäre wohl der zweite Fall mit den 5 Sekunden und weniger Connections zu bevorzugen.

Möglicherweise rede ich hier aber auch Quatsch.

Auf alle Fälle gibt's jetzt ne neue Idee für die Achievements...

"Quicky - Hat an einer Runde mit weniger als 1000 Shares mitgemacht"
...
"Hammerhart - Hat an einer Runde mit über 2 Mio Shares mitgemacht"
"Sturkopf - Hat an einer Runde mit über 5 Mio Shares mitgemacht"
....
etc