Deutschsprachiger Pool btc.x8s.de ~110Ghash/s

[redhatzero]

was man natürlich nicht vergessen darf: die difficulty ist auch schon das ein oder andere mal gestiegen in der zeit.

Bleibt nur daumendrücken, dass die aktuelle Runde nicht mehr allzulange braucht :/

[1713492721]

1713492721

[1713492721]

1713492721

[miningnew]

Wie wird man eigentlich genau bezahlt?

[KJaneway]

Weiß nicht genau was du meinst, aber die Formel für deine Auszahlung dürfte die Folgende sein:

(50-0,5)*Deine shares / Alle Shares

0,5 BTC sind Gebühr.

[redhatzero]

Runde 13 hat ihre 120 Confirmations bekommen

[Magro]

So bei Runde 14 liegen wir leider zum ersten Mal über dem Durchschnitt. Mal sehen wie lange es noch dauert. Es fehlen auch nur noch 19 Blöcke bis zur nächsten Difficulty Erhöhung.

[miningnew]

Oh neeiin es muss davor geschehen !!!

[lt.cmdr.data]

Machen wir uns doch nichts vor, das wird in Zukunft immer länger dauern 
(bzw. immer mehr Shares, wenn die Hashing-Rate steigt, bleibts vom zeitlichen Aufwand ja evtl. wieder gleich).

[redhatzero]

so, update:

* Impressum hinzugefügt (tjaja... böse Anwälte wird's immer geben, die sowas ausnutzen wollen )
* http://btc.x8s.de/account/stats - einen "load more" link hinzugefügt.. (unterstreichen bei hover & deutsche übersetzung kommen noch)
* Pool Transaktionen - Statt 20 werden 60 angezeigt

Ich finde, damit haben wir uns den Block jetzt aber verdient

[redhatzero]

Bist du da schon weiter? Ein nettes Achievement-System à la Steam Achievements würde ich sehr begrüssen
Dann kann man ein wenig angeben mit dem erreichten Medaillen (bspw. erster Worker online, 1Gh gesamt geliefert, 1 Mio shares gesammelt, seit Runde 1 dabei, etc.)
Zusätzlich würde ich es gut finden, wenn bei der Statistik-Seite eine Verlinkung auf eine Archiv-Seite wäre, wo man eine Liste mit allen Blöcken anschauen könnte.

Statistik "Archiv" gibt's ja jetzt durch den LoadMore Button auf der Stats Seite.

Wegen Achievment System bin ich noch nicht weiter, ich werd mich als nächstes an AutomaticPayout ranmachen, danach sollte dann das Achievement System dran sein

[PaZer]

PaZer ... träumt von Runde 9

[assko]

Manchmal hab ich das gefühl je mehr mhash nen pool hat desto mehr shares braucht er für nen block.

[turbofoen]

ach wat....das kommt dir nur so vor.

di enächsten werden wieder besser. ganz sicher. 

[yetis]

Vielleicht liegt's auch an der Netzwerkgeschwindigkeit (-> Ping). Je schneller ein getwork gefetcht werden kann, desto eher kann der Miner mit dem Hashen anfangen. Die aktiven Worker steigen und steigen und der Daemon hat viel mehr Miner zu bedienen. Das wiederum könnte bedeuten, dass die Netzwerkauslastung ein wenig steigt und der Ping ebenfalls. An der Rechenleistung des Daemons kann es nicht liegen, wenn der Daemon selbst nicht zum Hashen verwendet wird. Und ständige Statusabfragen des Daemons führen auch zu einer erhöhten Netzwerkauslastung. Da wird dann ein getwork in die Schlange gestellt und umgekehrt...
Mich würde interessieren wie die Netzwerkanbindung unseres Daemons ist und wieviele Verbindungen gleichzeitig er verkraften kann.
Das wäre meine theoretische Überlegung zu assko seinem Gefühl. ^^

Edit:
Eine Lösung wäre z.B. den Daemon zu splitten, sprich mehrere Daemons einzusetzen, die nicht die gleiche Netzwerkanbindung und nicht denselben Backbone benutzen, wie es zum Beispiel bei BTC-Guild (soweit ich das so sehe) der Fall ist / war.

[lt.cmdr.data]

Tja Leute, wenn mich nicht alles täuscht, haben wir seit diesem Block eine neue Difficulty:
http://blockexplorer.com/block/00000000000006f5d58e11e705c01b33a87f6d31f6b5bded34f01c68ad4e3d61

20:35 Uhr.

[assko]

Jo haben ne neue -.- 

[PaZer]

Tja Leute, wenn mich nicht alles täuscht, haben wir seit diesem Block eine neue Difficulty:
http://blockexplorer.com/block/00000000000006f5d58e11e705c01b33a87f6d31f6b5bded34f01c68ad4e3d61

20:35 Uhr.

Ja, haben wir: http://bitcoin.sipa.be/
Der Anstieg ist diesmal jedoch moderat. Wir werden es verkraften :-)

Vielleicht liegt's auch an der Netzwerkgeschwindigkeit (-> Ping). Je schneller ein getwork gefetcht werden kann, desto eher kann der Miner mit dem Hashen anfangen. Die aktiven Worker steigen und steigen und der Daemon hat viel mehr Miner zu bedienen. Das wiederum könnte bedeuten, dass die Netzwerkauslastung ein wenig steigt und der Ping ebenfalls. An der Rechenleistung des Daemons kann es nicht liegen, wenn der Daemon selbst nicht zum Hashen verwendet wird. Mich würde interessieren wie die Netzwerkanbindung unseres Daemons ist und wieviele Verbindungen gleichzeitig er verkraften kann. Und ständige Statusabfragen des Daemons führen auch zu einer erhöhten Netzwerkauslastung. Da wird dann ein getwork in die Schlange gestellt und umgekehrt...
Das wäre meine theoretische Überlegung zu assko seinem Gefühl. ^^

Edit:
Eine Lösung wäre z.B. den Daemon zu splitten, sprich mehrere Daemons einzusetzen, die nicht die gleiche Netzwerkanbindung und nicht denselben Backbone benutzen, wie es zum Beispiel bei BTC-Guild (soweit ich das so sehe) der Fall ist / war.

Das ist Schmarrn. Prost. Wir hatten am Anfang einfach nur Glück. Deepbit hatte letztens auch mit einem Monsterblock zu kämpfen. Die Difficulty steigt ebenfalls.

ABER HEY: BEVOR wir die Hardware für das Minen bestellt haben, war uns das alles doch klar. Wir haben uns trotzdem nicht abhalten lassen! Ahoi!

[redhatzero]

Mich würde interessieren wie die Netzwerkanbindung unseres Daemons ist und wieviele Verbindungen gleichzeitig er verkraften kann.
Edit:
Eine Lösung wäre z.B. den Daemon zu splitten, sprich mehrere Daemons einzusetzen, die nicht die gleiche Netzwerkanbindung und nicht denselben Backbone benutzen, wie es zum Beispiel bei BTC-Guild (soweit ich das so sehe) der Fall ist / war.

Die Netzwerkanbindung ist "recht gut" Er steht in nem Rechenzentrum mit ordentlicher Leitung und nicht zuhause per DSL verbunden
Wieviele Verbindungen er gleichzeitig verkraftet wird sich zeigen. Im Moment ist da noch Luft nach oben.
Ich benutze übrigens einen speziell gepatchten Daemon, der im P2P Netz versucht mehr(&aggresiver) Verbindungen aufbaut. Ziel ist hier möglichst viele Partner zu haben an die ein neu gefundener Block geschickt werden kann (und man damit hoffentlich das Rennen um invalid Blocks gewinnt, falls es mal dazu kommt)

Am "Daemon splitting" bin ich dran, ich hab hierzu wieder einen speziellen Bitcoin Daemon der an eine fest definierte Adresse die neu generierten BTCs schickt (und nicht wie der standard an eine neue zufällig generierte)
Grund für das splitting ist hier aber mehr, dass einige Leute (z.B. Bloody Angel) eine schlechte Leitung zum Pool haben.

[redhatzero]

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

[gentakin]

Ich benutze übrigens einen speziell gepatchten Daemon, der im P2P Netz versucht mehr(&aggresiver) Verbindungen aufbaut. Ziel ist hier möglichst viele Partner zu haben an die ein neu gefundener Block geschickt werden kann (und man damit hoffentlich das Rennen um invalid Blocks gewinnt, falls es mal dazu kommt)

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.

[redhatzero]

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

When your mining, it's vital that you be informed of new blocks on the
network as quickly as possible. This ensures that you are working on what is
most likely to be the longest chain. Similarly, it is vital that you get
your own blocks out to the network as soon as possible. This makes it the
most likely that your blocks will be incorporated in the chain that
ultimately wins.

Yet the code in bitcoind is stunningly conservative. It prioritizes
minimizing connections and overhead in a way that's great for a personal
wallet that does transactions but horrible for a minining controller. It is
also very slow to recover connections on a restart.