Topic: Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread - page 13. (Read 51053 times)

Da kannst du aber drauf wetten.
Aktuell ist mindestens 1.029...

@rico
Ich hab "nur" so ~20% mehr, und ich kann nicht sehen welchen Generator er benutzt.
-u hat was runtergeladen, -x hat getestet und mit den normalen Optionen geht's direkt los.
Die "Best Generator chosen"-Zeile kommt nicht.
Hast du das weggemacht, oder bin ich mal wieder zu doof?

Hallo Rico,

ich nutze die VMPlayer Konfiguration auf Windows7 x64.

./LBC -x

sagt "Best generator chosen: gen-hrdcore-sse41-linux64", obwohl meine CPU (Xeon W3520) laut CPU-Z die SSE4.2 instructions beherrscht.

Test läuft aber als OK durch mit ca. 250.000 K/s.


./LBC --version
gibt mir: 0.886

./LBC --update
Finished update run - system up to date.

erneutes ./LBC --version
gibt mir wieder: 0.886

Wenn den LBC nun starten will, bekomme ich folgende Fehlermeldung:
wrong: minversion

Ich bin hinter einer Firewall, die mir den Zugang zu Deinem FTP-Server verwehrt. Die Dateien mußte ich über einen anderen Rechner herunterladen. Könnte das damit zusammenhängen?

Würde gerne ein paar Rechner auf Deinen Pool ausrichten.

Grüße,
Janu$$

Ich habe neue Versionen der SSE42, AVX2 und Skylake CPU Generatoren auf den FTP Server gestellt. DIese nutzen die arulbero-ECC anstelle der libsecp256k1 und geben einen schönen Keyrate-Bonus. Nicht so hoch wie die GPU Versionen (folgen bald), aber immerhin. Die SSE42 Version erfährt interessanterweise den größten Zuwachs.

SSE42: +79%
AVX2: +29%
Skylake: +6%

Die  SSE41 bzw. 32bit-generic Versionen laufen aus - keine Updates verfügbar.
Es wird aber eine 64-bit generic Version geben.

How to update?

1) Beendet euren laufenden LBC durch drücken der Taste "e" und wartet, bis ihr den Shell prompt bekommt.

2) Gebt auf der Kommandozeile ./LBC -u - das wird den Generator (und ggf. die BLF Datei) aktualisieren


3) Gebt dann ./LBC -x ein um den Generator zu testen und einen neuen Benchmark zu fahren. Ihr solltet nun eine bessere Keyrate sehen.

4) Fertig!


Rico

Das klingt gut!  
Bedeutet das wir langsam in den Bereich vordringen, wo man neben der Geschwindigkeit ebenfalls die Hardware Temps ein bischen im Auge behalten sollte  
Bisher höre ich meine Grafikarte kaum, bei 80% Auslastung wird das sicher anders.

Bin gespannt!

Die libsecp256k1 ist laut den Bitcoin Core Developern mindestens um den Faktor 5 schneller als die nächstbeste Alternative - OpenSSL.
Ist libsecp256k1 nun gut oder OpenSSL schlecht?
Ist ein moderner Skylake gut oder ein "alter" Westmere schlecht?
Ist die Baureihe 222 gut oder die Baureihe 116 schlecht?

Das Schlüsselwort lautet Entwicklungsaufwand und daraus resultiert Fortschritt. Moderne Chipfabriken kosten Milliarden und es laufen darin Prozesse ab, die noch vor 30 Jahren als physikalisch unmöglich galten. (bspw. Wellenlänge Laser vs. Strukturgröße in der Litographie)...

Kommen wir zum Thema: LBC Client

Die gegenwärtig zum Download stehende Version macht auf meinem Notebook - bekanntlich benchmarktechnisches Zentrum der IT-Welt - ca. 7.5 Mkeys/s
Meine Development-Version (bis gestern Abend) mit einigen Optimierungen (bloom@GPU etc.) machte 9 Mkeys/s

Seit heute früh 0:30 MEZ arbeitet auf meinem Notebook eine Version, welche die EC-Arithmetik von Arulbero (siehe hier ff.) benutzt.

=> momentan ca. 20 Mkeys/s (= 40 Millionen Adressen pro Sekunde = 2.7x so schnell wie oclvanitygen)

Die GPU ist nun zu ~80% ausgelastet


Wir haben also noch etwas Reserve nach oben.  

Ich werde jetzt noch etwas testen, Pakete schnüren und dann die Version auf den Server schieben.



Rico

Altera 10 max ist recht interessant weil es ein recht günstiges Entwicklerboard gibt das solch ein FPGA verbaut hat und man das auch zusätzlich als Node benutzen könnte:

Auskennen tue ich mich damit auch noch nicht, aber das habe ich vor 6 Monaten auch über GPU Programmierung gesagt. 
Ein wenig habe ich mich schon umgesehen was es (bezahlbares) auf dem Markt gibt. Aber eine Einschätzung welche Anweisung in C in welchen Schaltkreis (mit entsprechendem Gatterverbrauch) übersetzt wird habe ich nicht finden können.

Der von Dir gepostete FPGA hat 50k LE, da gibt es auch noch ganz andere Brummer:
https://www.altera.com/products/fpga/stratix-series/stratix-10/overview.html
hat 5.5 mio LEs

"Up to 10 tera floating point operations per second "

Das entspricht dem einer derzeitigen High-End GPU , bei 125W Verbrauch.

Der große Vorteil bei diesen FPGAs (und warum ich sowas überhaupt in Erwägung ziehe): man kann sie auch in OpenCL programmieren.
https://www.altera.com/products/design-software/embedded-software-developers/opencl/overview.html

Also das, was ich momentan auf der GPU veranstalte. Vielleicht compilier ich einfach nur das Programm für den FPGA neu? :-)


Rico

Ja, 512 MKeys/s waren 4 mio Seiten auf directory.io die Sekunde. Da sind wir drüber hinaus. 


Eine gewisse Analogie zum BTC Mining ist nicht abzustreiten. Ich habe ja die Evolution (Inflation würde ich es nicht nennen) CPU->GPU->FPGA->ASIC schon vor geraumer Zeit prognostiziert. Momentan sind wir irgendwo beim Pfeil zwischen CPU und GPU.

Mittlerweile kenne ich mich mit dem Generierungsprozess Privkey -> hash160 so gut aus, dass ich zuversichtlich sagen kann, mittelfristig einen GPU client zu haben, der gut 4-6 mal schneller ist als oclvanitygen (knapp doppelt so schnell sind wir heute bereits).

Und wenn ich das habe, besorge ich mir ein FPGA Entwicklerboard und mache da ein wenig mit rum.

Im Gegensatz zu Bitcoin-Mining, was ja eine unendliche Geschichte ist, ist das hier ein endliches Projekt. Der Suchraum ist natürlich gigantisch, aber endlich. Für diesen Suchraum sind 586 MKeys/s immer noch sehr wenig, aber die interessante Info hier ist, dass wir mit dieser Speed offensichtlich bereits in Bereiche vordringen, wo wir "Erster!" ausrufen können - schliesslich ist ja #51 bislang unangetastet und es sieht so aus als wäre es wirklich am LBC den privkey dazu zu finden.

Was vor allem für mich interesant ist, ist den Pool bei diesem Kapazitätsanstieg zu beobachten wie das ganze skaliert. Ohne Änderung, also ihn einfach so laufen zu lassen wie er ist, kann ich sagen, dass das sicher bis 50 GKeys/s skaliert. Sehr konservativ ausgedrückt - vielleicht sogar 500 GKeys/s aber so weit will ich mich nicht aus dem Fenster lehnen. Jedenfalls weiß ich schon, wie ich mit leichten Änderungen den Pool  weit über die TKeys/s Grenze hinaus skalieren könnte - sollte die Zeit mal kommen.

Ich habe auch gestern alle P2SH hash160 in die BLF Datei mit aufgenommen. Der Pool checkt also für alle mit aktueller BLF nicht mehr gegen ~11 mio  Addressen ab, sondern ~14 mio (im Übrigen zum Nulltarif - der LBC wird dadurch nicht langsamer). Vorerst nur experimentell, wenn das Ärger machen sollte nehme ich es wieder raus.


Rico

Jesus, 586MKeys/s.
Vor 2 (oder 3) Wochen war das so etwa ein Zehntel.

Miningpowerinflation wie beim BTC?
So langsam müsste doch mal einer einen PK für eine seiner eigenen Adressen finden 

Ach so war das gemeint, der Pool weiß das was fehlt. Ja, Verständnisfehler meinerseits, danke.

Doch, der pool weiß ja gerade dass da noch 370 * 10¹² Schlüssel fehlen und die Statistik geht nicht davon aus, dass wir sowas mal eben überspringen, also stimmt der Offset nicht. (Man könnte sagen sie Statistik "is not fully aware")

"Die Statistik wird aufgrund der bereits abgelieferten Arbeit berechnet und nicht aufgrund des Ortes wo wir uns gerade befinden." So in etwa.

Wo der 1000 CPUs herbekommt ... irgendwie scheinen dem die Server einfach so zuzufliegen.
Alles von Amazon, Google und anderen - sieht jetzt nicht nach Botnetz aus.
Ich schätze Admin in einem großen Saftladen, der ungenutzte Kapazitäten (auch eingekaufte) nutzt...
Oder reicher Schnösel, der sich nen Spaß erlaubt.


Rico

Yeah, i usually don't read the english thread

Müsste es nicht "is not aware" heißen, weil er das _nicht_ weiß?

Und: Wo zum Henker kommt der auf 1000 CPUs?
Kauft der Amazons Service, oder lässt der bei seiner Firma "schwatt" mitlaufen?

https://bitcointalksearch.org/topic/m.18206936



=> Wir machen das später nach


Rico

Die Website zeigt das aber noch nicht an.
Fehlt dann jetzt nicht was von 49,35 bis 50 Bits?
Oder machen wir das später nach?

Der Pool jagt momentan #51 - mit 325 MKeys/s. Tendenz steigend.

Ich habe ausnahmsweise die Poolfront auf den 2^50 Offset gelegt, das bedeutet - bei gegenwärtiger Geschwindigkeit - werden wir #51 in 0 bis 41 Tagen gefunden haben.

0.051 BTC sind da derzeit noch drauf und können nach gängiger Meinung als Bounty angesehen werden.

Gentlemen - start your Engines!


Rico

Ich krieg' mich gar nicht ein. Aus der History:



Das, woran da vom 28.7.2016 bis 14.9.2016 geknödelt wurde, macht der Pool heute in einer halben Stunde.



Rico

Mit der Hook-Funktion habe sogar ich, als alter Win-Admin, eine E-Mail Benachrichtigung hinbekommen. 

Gruß Carsten.

Sieht man ja in den top30. Unknownhostname ist ziemlich eifrig dabei (~150 Mkeys - schätze ich).

Wenn ich den verdammten GPU client (also meine neue Version) dazu bekäme nicht abzustürzen, dann könnten wir bald zur GKeys/s Zählweise übergehen...


Rico

Was los?
Nach der üblichen Wochenende-spitze mit hundertund... jetzt auf mal 250MKeys?
Hat da einer ne Farm gefunden?