hallo rico und danke,
login kann ich schon eingeben, aber nicht das pw
lg
Topic: Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread - page 23. (Read 51045 times)
January 09, 2017, 08:43:46 AM
January 09, 2017, 07:22:56 AM
Hallo und guten morgen,
ich habe mir jetzt Diskinternals geladen. Nun meine frage.
wie bekomme ich es jetzt ans laufen?
ich habe mir jetzt Diskinternals geladen. Nun meine frage.
wie bekomme ich es jetzt ans laufen?
1) Lösche Diskinternals wieder
2) https://lbc.cryptoguru.org/man/admin#installation
(VMware, LBC-Appliance, ggf 7zip ... einfach die Punkte abarbeiten)
Rico
January 09, 2017, 03:27:28 AM
Hallo und guten morgen,
ich habe mir jetzt Diskinternals geladen. Nun meine frage.
wie bekomme ich es jetzt ans laufen?
lg
thomas
ich habe mir jetzt Diskinternals geladen. Nun meine frage.
wie bekomme ich es jetzt ans laufen?
lg
thomas
January 08, 2017, 03:30:05 PM
Ach mist geht ja nur auf Linux.
January 08, 2017, 03:19:13 PM
Hallo zusammen und noch ein frohes neues jahr,
ich versuche mein glück auch mal.
lg
thomas
ich versuche mein glück auch mal.
lg
thomas
January 04, 2017, 11:24:48 AM
any news an deinem Projekt
Jo.
Ich habe den CPU Generator nochmal etwas schneller gemacht, weil sich herausgestellt hat, dass Pieter Wuille es mit der Performance bei der libsecp256k1 nicht so ganz ernst nimmt.
Naja - Bitcoin Core Programmierer und Open Source ... kennt man ja.
Nachdem ich nun also die schnellste RIPEMD160 CPU-Implementierung habe, die schnellste EC CPU-Implementierung habe und die vorerst schnellste SHA256 CPU-Implementierung verwende, ist die Skylake Version des Generators mal eben doppelt so schnell wie supervanitygen.
Ich mache auf einem Kern bei mir ca. 720000 keys/s - aber im Gegensatz zu Supervanitygen eben compressed UND uncompressed public keys (also 1.44 mio hash160 pro Kern pro Sekunde gegen 11 mio hash160 gecheckt).
Einen haarigen Bug habe ich heute behoben (alle Block-Zahlen über 50 Ziffern wurden falsch berechnet), glücklicherweise hat das auf die abgelieferte Arbeit keinen Einfluss, weil wir noch irgendwo bei 15 Ziffern rumkrebsen.
Für den Bugreport danke an einen asiatischen Nutzer, der im Übrigen in den nächsten Tagen ca. 1200 CPU Kerne auf den Pool loslassen will, weil - jetzt kommt's:
Er nur noch ungefähr den Bereich kennt, wo er seine Bitcoins deponiert hat, aber die konkreten privaten Keys nicht mehr hat.
LBC als recovery tool! Ich schmeiß mich weg.
Rico
January 01, 2017, 02:43:05 PM
any news an deinem Projekt
November 18, 2016, 04:55:40 AM
Der Server ist natürlich noch in Betrieb und das wird noch ein paar Milliarden Jahre so bleiben.
Wenngleich mit kleinen Unterbrechungen.
Diesen Sonntag Abend wird der Server wegen Umzug ca. 30 Minuten offline sein.
Da das länger ist, als die Client Retry-Zeiten, wird ein Restart der Clients nach dem Termin notwendig sein.
Ich empfehle, die clients nicht mit extra-langen Arbeitszeiten zu starten (-t 30 ist ok), damit nicht unnötig viel Arbeit verloren geht.
Vermutlich setze ich hier noch einen PING ab, bevor wir mit dem Umzug beginnen.
Rico
November 17, 2016, 06:35:47 AM
Rico ist der Server noch in betrieb?
Bekomme Meldung:
Bekomme Meldung:
Code:
perl LBC -c 2 -t 600
Fetching adequate work... Malformed answer: server didn't send minversion requirement.
Der Server ist natürlich noch in Betrieb und das wird noch ein paar Milliarden Jahre so bleiben.
Die Meldung ist interessant, denn das ist einer der Tests mit denen der Client checkt ob das gegenüber ein legitimer Server ist.
./LBC statt perl LBC, aber das ist nur rein kosmetisch. Was sagt denn
Code:
./LBC -v
?? Wenn das älter ist als 0.899, einfach neue version holen:
ftp://ftp.cryptoguru.org/LBC/client/LBC
Die sollte sich auch künftig selbst aktualisieren.
Rico
November 15, 2016, 09:15:51 AM
Der versuch war auf einem alten AMD Prozessor.
Habe es jetzt mit einem intel i5 versucht und es geht.
Habe auch in Englischen Thread jemanden gefunden bei dem die Datei nicht heruntergeladen wurde der dann einfach alles manuell runtergeladen hat und so habe ich es auch machen müssen. Habe aber auch keine rechte geändert bei dem Ordner aber es läuft jetzt.
Danke trotzdem
Habe es jetzt mit einem intel i5 versucht und es geht.
Habe auch in Englischen Thread jemanden gefunden bei dem die Datei nicht heruntergeladen wurde der dann einfach alles manuell runtergeladen hat und so habe ich es auch machen müssen. Habe aber auch keine rechte geändert bei dem Ordner aber es läuft jetzt.
Danke trotzdem
November 15, 2016, 07:53:19 AM
HAllo,
habe es auch probiert aber bekomme immer die Fehlermeldung
Benchmark info not found - benchmarking... 'gen-gocpu-linux64' not found/executable
kann mir jemand helfen?
habe es auch probiert aber bekomme immer die Fehlermeldung
Benchmark info not found - benchmarking... 'gen-gocpu-linux64' not found/executable
kann mir jemand helfen?
Was sagt "./LBC -v" und welche CPU hast Du denn?
Rico
November 15, 2016, 05:32:59 AM
HAllo,
habe es auch probiert aber bekomme immer die Fehlermeldung
Benchmark info not found - benchmarking... 'gen-gocpu-linux64' not found/executable
kann mir jemand helfen?
habe es auch probiert aber bekomme immer die Fehlermeldung
Benchmark info not found - benchmarking... 'gen-gocpu-linux64' not found/executable
kann mir jemand helfen?
November 08, 2016, 11:38:04 AM
Auf den LBC Log schauend:
"iiih" - denke ich mir - "was ist das denn?"
Hat sich also ein schweizer Rösti einen Client geholt, ungefähr 5 Blöcke von je ca. 2GKeys angefordert, aber natürlich nicht geliefert.
Mit folglich 0 abgearbeiteten Blöcken ist man auch in der CLient-DB unbekannt und wenn man mit "query" hechelnd abfragt wo man denn nun in der Rangliste ist macht der Server würg, weil die Client-Id gibt's nicht. Macht dem Server Nichts, stört nur mein ästhetisches Empfinden.
Danke. Fixed. Und die versprochenen aber nicht gelieferten Blöcke habe ich in 7 Minuten durch
-c 64 ;-)
Damit keine Missverständnisse aufkommen: Ist nicht bös' gemeint. Klar ist jeder Client willkommen und offensichtlich ist es ja der Softwarequalität zuträglich, wenn sich die Leute "unerwartet" verhalten.
Rico
Code:
1478622274Query
[LBC::Server:10261] error @2016-11-08 17:24:35> Route exception: hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at /data/web/LBC-Server/bin/../lib/LBC/Server.pm line 200. in /opt/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0/Dancer2/Core/App.pm l. 1388
1478622284Query
[LBC::Server:10261] error @2016-11-08 17:24:44> Route exception: hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at /data/web/LBC-Server/bin/../lib/LBC/Server.pm line 200. in /opt/perlbrew/perls/perl-5.24.0/lib/site_perl/5.24.0/Dancer2/Core/App.pm l. 1388
"iiih" - denke ich mir - "was ist das denn?"
Hat sich also ein schweizer Rösti einen Client geholt, ungefähr 5 Blöcke von je ca. 2GKeys angefordert, aber natürlich nicht geliefert.
Mit folglich 0 abgearbeiteten Blöcken ist man auch in der CLient-DB unbekannt und wenn man mit "query" hechelnd abfragt wo man denn nun in der Rangliste ist macht der Server würg, weil die Client-Id gibt's nicht. Macht dem Server Nichts, stört nur mein ästhetisches Empfinden.
Danke. Fixed. Und die versprochenen aber nicht gelieferten Blöcke habe ich in 7 Minuten durch
Code:
./LBC -c 64 -p 127581257-127583176
Loop off! Work on blocks [127581257-127583176] (2013 Mkeys)
Best generator chosen: gen-hrdcore-avx2-linux64
PAGE-TO: 127583176 PAGE-FROM: 127581257
Estimated duration: 1m 15.445689375s
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
...
-c 64 ;-)
Damit keine Missverständnisse aufkommen: Ist nicht bös' gemeint. Klar ist jeder Client willkommen und offensichtlich ist es ja der Softwarequalität zuträglich, wenn sich die Leute "unerwartet" verhalten.
Rico
November 07, 2016, 05:10:48 AM
Oder auch 1012 (damit's keine Missverständnisse mit den Amis gibt).
Trotz "nur CPU mit einer Prise GPU" hat der Pool mittlerweile das Äquivalent von über 1 Billion Seiten auf directory.io abgeklappert.
Angenommen man wäre noch jung und stünde voll im Saft seines Lebens (oder so) und hätte noch 60 Jahre zu leben, das wären dann 1892160000 Sekunden. Ist deprimierend - ich weiß.
Angenommen man würde also diese knapp 1.9 Mrd Sekunden Tag und Nacht damit verbringen pro Sekunde eine Seite (= 256 Adressen) auf directory.io gegen 11 mio Adressen abzugleichen... man hätte dann nach Adam Riese eben 1.9 Mrd Seiten am Ende seines nicht so ereignisreichen Lebens gecheckt.
Es stellt sich natürlich die Frage, ob man so schnell wäre und auch ob man noch 60 Jahre zu leben hätte wenn man das denn machen würde, aber nur mal so angenommen. Der Pool bewältigt diese Aufgabe derzeit in ca. 100 Minuten. Ist auch deprimierend - ich weiß.
Im Umkehrschluß bedeutet das, dass die Arbeit, die der Pool bislang erledigt hat in etwa 568 solcher grandios durchlebter Menschenleben (34080 Jahre) entspricht. Und das in knapp 40 Tagen. Ich gebe dann wieder Bescheid, wenn die erledigte Arbeit einem Sonnenleben bei 1Seite/Sekunde entspricht.
Rico
Trotz "nur CPU mit einer Prise GPU" hat der Pool mittlerweile das Äquivalent von über 1 Billion Seiten auf directory.io abgeklappert.
Angenommen man wäre noch jung und stünde voll im Saft seines Lebens (oder so) und hätte noch 60 Jahre zu leben, das wären dann 1892160000 Sekunden. Ist deprimierend - ich weiß.
Angenommen man würde also diese knapp 1.9 Mrd Sekunden Tag und Nacht damit verbringen pro Sekunde eine Seite (= 256 Adressen) auf directory.io gegen 11 mio Adressen abzugleichen... man hätte dann nach Adam Riese eben 1.9 Mrd Seiten am Ende seines nicht so ereignisreichen Lebens gecheckt.
Es stellt sich natürlich die Frage, ob man so schnell wäre und auch ob man noch 60 Jahre zu leben hätte wenn man das denn machen würde, aber nur mal so angenommen. Der Pool bewältigt diese Aufgabe derzeit in ca. 100 Minuten. Ist auch deprimierend - ich weiß.
Im Umkehrschluß bedeutet das, dass die Arbeit, die der Pool bislang erledigt hat in etwa 568 solcher grandios durchlebter Menschenleben (34080 Jahre) entspricht. Und das in knapp 40 Tagen. Ich gebe dann wieder Bescheid, wenn die erledigte Arbeit einem Sonnenleben bei 1Seite/Sekunde entspricht.
Rico
November 02, 2016, 07:54:01 AM
Quote
Trotzdem sollte theoretisch 1:30 drin sein.
Wow, aber das ist ja schon mal ordentlich, auch wenn du da nochmal ca. das doppelte an Optimierungsbedarf siehst...
November 01, 2016, 07:12:21 AM
Quote
ich habe bereits einen GPU generator am Laufen, der ca. 50% der Performance von oclvanitygen hat.
Was bedeutet das denn im Gegensatz zum derzeitigen cpu-Klienten?
Kommt auf die GPU an.
Konkret auf meinem Notebook (Skylake Xeon vs. Quadro M2000M) ist das so 1:4, sprich der GPU generator ist 4 mal schneller als der CPU generator (edit: also wenn alle Kerne arbeiten).
Aber da trifft auch eine relativ starke CPU auf eine relativ schwache GPU.
Trotzdem sollte theoretisch 1:30 drin sein.
Glücklicher weise habe ich von einem Mitglied seine Implementierung bekommen und studiere diese nun. Wenn ich sozusagen das Beste zweier Welten vereinen kann (ich habe eine effizientere hash160 Berechnung, er hat den Bloom Filter auf die GPU gebracht), dann könnte das richtig krachen.
K-EX
October 31, 2016, 06:57:20 AM
Quote
ich habe bereits einen GPU generator am Laufen, der ca. 50% der Performance von oclvanitygen hat.
Was bedeutet das denn im Gegensatz zum derzeitigen cpu-Klienten?
October 28, 2016, 04:50:44 AM
verfolge den englischen Thread nicht so weil mein English noch nicht so gut ist .
Die schlechte Nachricht: Ich muss noch viel über OpenCL lernen.
Die gute (oder noch schlechtere - je nachdem wie man's sieht) Nachricht: Offensichtlich sind auch andere unfähig.
Als Erklärung zu letzterem:
Ich dachte mir ursprünglich, oclvanitygen so hinzubiegen, dass es tut was ich will. Das habe ich auch geschafft und ich habe bereits einen GPU generator am Laufen, der ca. 50% der Performance von oclvanitygen hat. Die 50% sind deswegen, weil für jeden Durchlauf (der Generator sieht sich 2^30 private keys pro "block" an) eigentlich 2 Durchläufe notwendig sind: Einer bei dem compressed public keys und einer bei dem uncompressed public keys generiert werden. Das Feld-Wald-Wiesen oclvanitygen generiert nämlich nur eine Art an public keys (habe vergessen welche).
Das ist natürlich Käse, weil man idealerweise beide keys gleichzeitig erzeugen sollte, müsste, hätte, könnte.
Wenn man denn könnte - da hapert's noch mit meinem OpenCL Wissen um den shitty code, der da in oclvanitygen herrscht zurechtzubiegen.
Dann gibt es da noch das Problem, dass oclvanitygen eigentlich auf andere Aufgaben hin getrimmt (naja - sagen wir "barock erweitert") wurde: Präfix-Suche und regex-Suche.
Die regex-Suche habe ich eh gleich geknickt, aber die Präfix-Suche ist da mit AVL Trees gelöst und das ist ja für unseren Bedarf so ziemlich das übelste was man machen kann.
Also versuche ich mich momentan an einem eigenen generator, der compressed und uncompressed keys in einem Durchgang erzeugt und diese gegen einen Bloom Filter abgleicht - alles auf der GPU.
Es geht alles sehr zäh, weil wie gesagt OpenCL Neuland für mich ist. Auf der anderen Seite ist Programmierung nicht so ein Neuland für mich und wenn es so klappt wie ich mir das vorstelle, dann sollte mein Generator oclvanitygen "im Staub hinter sich zurücklassen".
Dauert halt, weil ich auch noch andere Dinge zu tun habe und sonst leider keiner zugegen ist, der außer bla bla mal mit anfassen könnte.
Rico
October 27, 2016, 11:10:03 AM
Hallo rico wie sieht es aus ?
verfolge den englischen Thread nicht so weil mein English noch nicht so gut ist .
verfolge den englischen Thread nicht so weil mein English noch nicht so gut ist .
October 21, 2016, 06:08:01 AM
Wenn ich nochmal um den Faktor 1000 besser werde ist's nicht mehr ganz so kläglich, aber immer noch
ungefährlich für Bitcoin.
ungefährlich für Bitcoin.
Im Übrigen sind wir soweit. Der Pool ist die letzten 2 Tage ca. um den Faktor 1000 schneller als die Keygenerierung zu der Zeit o.g. Zitats.
Einen Riesengrund zur Besorgnis gibt es natürlich noch nicht, allerdings spricht prinzipiell Nichts dagegen, dass der Pool in ca. 4 Monaten nochmal um den Faktor 1000 schneller wird, denn nachdem ja hier keiner zu Potte kommt, habe ich beschlossen einen GPU client zu schreiben.
https://youtu.be/lbDoZTs3NoY?t=65
Rico
Jump to: