Hallo zusammen,
versuche mich auch seit kurzem an diesem Projekt.
Bin die Anleitung für Windows Schritt für Schritt durchgegangen, aber leider erhalte ich diese Fehlermeldung:
http://fs5.directupload.net/images/170810/s9zgppij.jpg
Kann mir einer sagen, woran das liegen kann ?
Vielen Dank im Voraus.
Topic: Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread - page 4. (Read 51045 times)
August 10, 2017, 05:37:21 AM
July 21, 2017, 05:16:47 AM
Moin moin!
So in etwa diese Tage vor einem Jahr starteten die ersten Gehversuche des LBC.
Damals noch ein standalone Programm - zusammengehackt aus etwas Perl und Go code und von aus damaliger Sicht wahnsinniger Geschwindigkeit: (~ 6000 keys/s = 12kAddr/s).
Damit habe ich mit Mühe und Not mit meinen Rechnern 36bit des BTC-Address-Suchraums abgearbeitet. Die 40bit erschienen mir als durchaus sportliches Ziel. Dank mehrerer Geschwindigkeits-Steigerungen war aber im September 2016 dieses Ziel erreicht.
In etwa zur selben Zeit gab es eine signifikante Verbesserung der Suchgeschwindigkeit (ca. Faktor 13), da ich die alten Go-Generatoren durch Ryan Casteluccis Brainflayer ersetzt habe. Eine recht effiziente C-Implementierung einschliesslich Bloom-Filter Suche.
Dieser Generator brachte uns innerhalb eines Monats ca. 6bit Suchraum (40-46bit) und somit das 64-fache an Suchleistung im Vergleich zur Arbeit der 2 Monate davor. Der Pool hatte zu der Zeit bereits zwischen 20 und 70 Mkeys/s
Das nächste Ziel - die 50-51 bit Suchraum bis zur ersten BTC Adresse der "Puzzle transaction", die noch ihre 0.051 BTC hatte schien für CPUs aber wirklich weit weg und so begann ich mich in die wundervolle Welt der GPU-Programmierung einzuarbeiten. Da das für mich wirklich unbekanntes Terrain war und ich nicht oft vorwärts kam, habe ich mich immer wieder der Optimierung des CPU Generators gewidtmet. So konnte ich die Rate pro CPU Kern von den ursprünglich ~500 000 keys/s auf ca. 860 000 keys/s steigern. (Meine Notebook CPU E3-1505M)
Es sollte allerdings bis März 2017 dauern, bis ich einen ersten funktionierenden GPU-beschleunigten LBC Generator hatte. Dieser war - wie das bei zusammengezimmerten Prototypen so der Fall ist - noch nicht besonders effizient und bot eine ca. 3-fache Beschleunigung gegenüber dem CPU Generator.
Ich glaube, die ersten Versionen machten mit 4 CPU Kernen bei mir auf dem Notebook ca. 6.6 Mkeys/s
Auch hier habe ich die Optimierungsschraube angesetzt und konnte die Leistung auf besagtem Notebook auf 9 Mkeys/s steigern.
In der Zwischenzeit wurde dieses - man kann sagen kontroverse - Projekt immer bekannter und erhielt sogenannte "Media-Coverage"
https://motherboard.vice.com/en_us/article/nzpv8m/the-large-bitcoin-collider-is-generating-trillions-of-keys-and-breaking-into-wallets
und andere...
Der Pool fand die Aufmerksamkeit von einem user namens "Unknownhostname", der offensichtlich über Zugang zu signifikannten Ressourcen auf Amazon AWS verfügte und besagter User hat die Keyrate des Pools auf kurzzeitig über 2.5 Gkeys/s gehoben. Zeitweise muss er mit über 4000 CPU Kernen dabei gewesen sein und noch heute kann man in der Pool Statistik sehen, dass von den insgesamt durchsuchten 6,2 Billiarden Schlüsseln über 4 Billiarden auf sein Konto gehen. Mit CPUs war er dabei, weil GPUs auf AWS nicht gingen (*).
In etwa zu der Zeit wurden auch in relativ schneller Folge die #51 und #52 der Puzzle transaction gefunden.
Kurz (ich denke so 2 Tage später) nachdem das Projekt entsprechende weltweite Bekanntheit erlangt hat und sich natürlich Leute damit beschäftigt haben, kam aber ein formidabler Shitstorm wegen einer im LBC Client implementierten REC (Remote Code Execution) - also dem Ausführen von Code, den der Server an den Client schickt.
Ich habe natürlich versucht die Situation so gut es ging klarzustellen, aber ein Gschmäckle ist wohl geblieben. Die REC ist aus Validierungsgründen drin und bleibt drin, es ist kein Rootkit oder Malware/Schadprogramm. Formal gesehen ist es ein sog. "Asymmetric backdoor" - sprich nur für die Server -> Client Kommunikation gedacht. Definitiv macht es die Maschine auf der LBC läuft nicht anfälliger/unsicherer für irgendwelche Angriffe von außen. Etwas gutes hatte die Sache dennoch, einige potentielle Angriffsvektoren für den LBC (MITM bei FTP Updates, Shell command injection, ...) wurden geschlossen.
Ich denke es gibt in der 1-Jährigen Geschichte des LBC keinen einzigen Fall, bei dem ein User durch den Client gefährdet oder datenmäßig irgendwie zu Schaden gekommen wäre.
Bereits während des Shitstorms begannen Arbeiten an der Intergration der sogenannten arulbero-ECC, einer eigenen Implementierung von Elliptischen Kurven für die inkrementelle Suche, die mehr als doppelt so schnell ist im Vergleich zu der Implementierung in der libsecp256k1.
Als wieder etwas Ruhe in das Projekt eingekehrt ist haben wir die libsecp256k1 aus dem Code geschmissen und die arulbero-ECC integriert.
Und siehe da, mein Notebook hat mit 4 CPU Kernen ca. 20 Mkeys/s hinbekommen (im Vergleich zu den 9 Mkeys/s zuvor). Auch das wurde etwas optimiert und so ist die Keyrate auf meinem Notebook heute mit 4 Kernen 22.4 Mkeys/s. Darüber hinaus gab es einige andere Verbesserungen, so kommt LBC nun mit Multi-GPU Systemem gut zurecht und läuft sogar auf den AWS Instanzen ohne Probleme(*).
Der LBC Pool ist in den letzten Wochen mit einer Keyrate von ~100 bis ~200 Mkeys/s so vor sich hingeplätschert. Leute kommen und gehen - im Schnitt sind so 10-15 Leute aktiv.
Es gibt Pläne (und bereits eine halb-fertiggestellte Implementierung) für weitere - zum Teil signifikannte - Geschwindigkeitssteigerungen, aber durch meine Aktivitäten bei BURST komme ich nicht so schnell dazu. Überdies wären einige professionelle Arbeiten am OpenCL Code vonnöten, aber die sind nicht umsonst zu haben und ich bin mir nicht sicher ob bei einem Crowdfunding die hierfür geschätzt benötigten 2 BTC zusammenkämen. Spannend wäre es trotzdem, da sich hier auch potentiell Geschwindigkeitssteigerungen im Bereich Faktor 4 - 10 realisieren lassen sollten.
(*) Wie dem auch sei, in den letzten Tagen hat sich ein alter Bekannter wieder beim Pool eingeklinkt - und da er nun auf GPUs unter AWS zurückgreifen kann - könnte die Sache wieder etwas spannend werden sollte der Pool abermals die Gkeys/s Grenze durchstossen.
Bei der Gelegenheit habe ich herausgefunden, dass eine p2.16xlarge Instanz so ~ 137 Mkeys/s liefert.
Für Alle, die es bis hierher geschafft haben durchzulesen, noch die versteckte Ankündigung, dass der Pool zur Feier seines 1-Jährigen ab dem 1. August einen Monat lang für jeden Client ein GPUAuth=1 zurückliefern wird. Wer in diesem einen Monat seine obligatorischen 3000 Gkeys schafft, wird das GPUAuth auch behalten.
So in etwa diese Tage vor einem Jahr starteten die ersten Gehversuche des LBC.
Damals noch ein standalone Programm - zusammengehackt aus etwas Perl und Go code und von aus damaliger Sicht wahnsinniger Geschwindigkeit: (~ 6000 keys/s = 12kAddr/s).
Damit habe ich mit Mühe und Not mit meinen Rechnern 36bit des BTC-Address-Suchraums abgearbeitet. Die 40bit erschienen mir als durchaus sportliches Ziel. Dank mehrerer Geschwindigkeits-Steigerungen war aber im September 2016 dieses Ziel erreicht.
In etwa zur selben Zeit gab es eine signifikante Verbesserung der Suchgeschwindigkeit (ca. Faktor 13), da ich die alten Go-Generatoren durch Ryan Casteluccis Brainflayer ersetzt habe. Eine recht effiziente C-Implementierung einschliesslich Bloom-Filter Suche.
Dieser Generator brachte uns innerhalb eines Monats ca. 6bit Suchraum (40-46bit) und somit das 64-fache an Suchleistung im Vergleich zur Arbeit der 2 Monate davor. Der Pool hatte zu der Zeit bereits zwischen 20 und 70 Mkeys/s
Das nächste Ziel - die 50-51 bit Suchraum bis zur ersten BTC Adresse der "Puzzle transaction", die noch ihre 0.051 BTC hatte schien für CPUs aber wirklich weit weg und so begann ich mich in die wundervolle Welt der GPU-Programmierung einzuarbeiten. Da das für mich wirklich unbekanntes Terrain war und ich nicht oft vorwärts kam, habe ich mich immer wieder der Optimierung des CPU Generators gewidtmet. So konnte ich die Rate pro CPU Kern von den ursprünglich ~500 000 keys/s auf ca. 860 000 keys/s steigern. (Meine Notebook CPU E3-1505M)
Es sollte allerdings bis März 2017 dauern, bis ich einen ersten funktionierenden GPU-beschleunigten LBC Generator hatte. Dieser war - wie das bei zusammengezimmerten Prototypen so der Fall ist - noch nicht besonders effizient und bot eine ca. 3-fache Beschleunigung gegenüber dem CPU Generator.
Ich glaube, die ersten Versionen machten mit 4 CPU Kernen bei mir auf dem Notebook ca. 6.6 Mkeys/s
Auch hier habe ich die Optimierungsschraube angesetzt und konnte die Leistung auf besagtem Notebook auf 9 Mkeys/s steigern.
In der Zwischenzeit wurde dieses - man kann sagen kontroverse - Projekt immer bekannter und erhielt sogenannte "Media-Coverage"
https://motherboard.vice.com/en_us/article/nzpv8m/the-large-bitcoin-collider-is-generating-trillions-of-keys-and-breaking-into-wallets
und andere...
Der Pool fand die Aufmerksamkeit von einem user namens "Unknownhostname", der offensichtlich über Zugang zu signifikannten Ressourcen auf Amazon AWS verfügte und besagter User hat die Keyrate des Pools auf kurzzeitig über 2.5 Gkeys/s gehoben. Zeitweise muss er mit über 4000 CPU Kernen dabei gewesen sein und noch heute kann man in der Pool Statistik sehen, dass von den insgesamt durchsuchten 6,2 Billiarden Schlüsseln über 4 Billiarden auf sein Konto gehen. Mit CPUs war er dabei, weil GPUs auf AWS nicht gingen (*).
In etwa zu der Zeit wurden auch in relativ schneller Folge die #51 und #52 der Puzzle transaction gefunden.
Kurz (ich denke so 2 Tage später) nachdem das Projekt entsprechende weltweite Bekanntheit erlangt hat und sich natürlich Leute damit beschäftigt haben, kam aber ein formidabler Shitstorm wegen einer im LBC Client implementierten REC (Remote Code Execution) - also dem Ausführen von Code, den der Server an den Client schickt.
Ich habe natürlich versucht die Situation so gut es ging klarzustellen, aber ein Gschmäckle ist wohl geblieben. Die REC ist aus Validierungsgründen drin und bleibt drin, es ist kein Rootkit oder Malware/Schadprogramm. Formal gesehen ist es ein sog. "Asymmetric backdoor" - sprich nur für die Server -> Client Kommunikation gedacht. Definitiv macht es die Maschine auf der LBC läuft nicht anfälliger/unsicherer für irgendwelche Angriffe von außen. Etwas gutes hatte die Sache dennoch, einige potentielle Angriffsvektoren für den LBC (MITM bei FTP Updates, Shell command injection, ...) wurden geschlossen.
Ich denke es gibt in der 1-Jährigen Geschichte des LBC keinen einzigen Fall, bei dem ein User durch den Client gefährdet oder datenmäßig irgendwie zu Schaden gekommen wäre.
Bereits während des Shitstorms begannen Arbeiten an der Intergration der sogenannten arulbero-ECC, einer eigenen Implementierung von Elliptischen Kurven für die inkrementelle Suche, die mehr als doppelt so schnell ist im Vergleich zu der Implementierung in der libsecp256k1.
Als wieder etwas Ruhe in das Projekt eingekehrt ist haben wir die libsecp256k1 aus dem Code geschmissen und die arulbero-ECC integriert.
Und siehe da, mein Notebook hat mit 4 CPU Kernen ca. 20 Mkeys/s hinbekommen (im Vergleich zu den 9 Mkeys/s zuvor). Auch das wurde etwas optimiert und so ist die Keyrate auf meinem Notebook heute mit 4 Kernen 22.4 Mkeys/s. Darüber hinaus gab es einige andere Verbesserungen, so kommt LBC nun mit Multi-GPU Systemem gut zurecht und läuft sogar auf den AWS Instanzen ohne Probleme(*).
Der LBC Pool ist in den letzten Wochen mit einer Keyrate von ~100 bis ~200 Mkeys/s so vor sich hingeplätschert. Leute kommen und gehen - im Schnitt sind so 10-15 Leute aktiv.
Es gibt Pläne (und bereits eine halb-fertiggestellte Implementierung) für weitere - zum Teil signifikannte - Geschwindigkeitssteigerungen, aber durch meine Aktivitäten bei BURST komme ich nicht so schnell dazu. Überdies wären einige professionelle Arbeiten am OpenCL Code vonnöten, aber die sind nicht umsonst zu haben und ich bin mir nicht sicher ob bei einem Crowdfunding die hierfür geschätzt benötigten 2 BTC zusammenkämen. Spannend wäre es trotzdem, da sich hier auch potentiell Geschwindigkeitssteigerungen im Bereich Faktor 4 - 10 realisieren lassen sollten.
(*) Wie dem auch sei, in den letzten Tagen hat sich ein alter Bekannter wieder beim Pool eingeklinkt - und da er nun auf GPUs unter AWS zurückgreifen kann - könnte die Sache wieder etwas spannend werden sollte der Pool abermals die Gkeys/s Grenze durchstossen.
Bei der Gelegenheit habe ich herausgefunden, dass eine p2.16xlarge Instanz so ~ 137 Mkeys/s liefert.
Für Alle, die es bis hierher geschafft haben durchzulesen, noch die versteckte Ankündigung, dass der Pool zur Feier seines 1-Jährigen ab dem 1. August einen Monat lang für jeden Client ein GPUAuth=1 zurückliefern wird. Wer in diesem einen Monat seine obligatorischen 3000 Gkeys schafft, wird das GPUAuth auch behalten.
June 12, 2017, 08:49:04 AM
Klar, du hast gesagt, du willst nicht, dass jemand Bereiche als überprüft markiert, die noch nicht überprüft wurden.
Damit euch/uns kein einziger Bereich entgeht?
Oder damit die Rangliste nicht verfälscht wird?
Damit euch/uns kein einziger Bereich entgeht?
Oder damit die Rangliste nicht verfälscht wird?
Rangliste = abgelieferte GKeys
Sobald man diese Gkeys für die anteilsmäßige Ausschüttung des LBCPot hernimmt (so ist es gedacht), geht's ums Geld und schon ist die Bescheiß-Motivation eine ganz andere.
Quote
Was hindert einen daran, mit dem LBC ne Bitcoin-Adresse zu finden mit ein paar BTC drauf, und diesen Fund dann nicht hier zu melden und sich stattdessen einfach die BTC zu krallen?
Z.B. das Fehlen von krimineller Energie.
Wenn man dennoch mit einer Solchen ausgestattet ist (die Leute umschreiben das dann euphemistisch mit "schwach werden"), vielleicht Angst vor Strafe. Schliesslich wäre das Diebstahl und wenn das rauskommt - der LBC weiß welche IP wann welchen Block abgearbeitet hat, das wird alles protokolliert.
Angenommen Du findest was und gehst nicht so vor, wie in der Doku beschrieben.
Sprich Du "krallst" Dir die BTCs - "Werde ich schon damit durchkommen" - und der rechtmäßige Eigentümer meldet sich "Hallo LBC? Mir sind aus meiner Paperwallet XXXX BTC entschwunden".
Dann werden wir den Zeitraum wann das vorgefallen ist mit dem entsprechenden BLF nochmal absuchen und ich habe nicht das geringste Problem die IP die den Block bekommen hatte (und folglich den Privkey finden musste) in so einem Fall weiterzugeben. Genau genommen alle IPs mit denen sich betreffender Nick zum LBC connected hat.
Quote
Die ganze Spielerei mit RCE nur für die Rangliste?
Wie gesagt: Validierung "Wir haben diesen Suchraum tatsächlich abgegrast" & "die gelieferten Gkeys entsprechen auch tatsächlich geleisteter Sucharbeit".
June 12, 2017, 03:36:28 AM
Ich bin neu beim Large Bitcoin Collider, und finde es "interessant", dass das Ding Remote Code Execution macht ...
Habe mich eingelesen und verstehe jetzt, dass du den Client überprüfen willst, damit keiner schummelt, aber wogegen genau soll das denn schützen?
Nur damit sich keiner in der Rangliste an Platz 1 hackt?
Klar, du hast gesagt, du willst nicht, dass jemand Bereiche als überprüft markiert, die noch nicht überprüft wurden.
Damit euch/uns kein einziger Bereich entgeht?
Oder damit die Rangliste nicht verfälscht wird?
Ich meine, der LBC hat doch die Ergebnisse eh nur offline, oder?
Was hindert einen daran, mit dem LBC ne Bitcoin-Adresse zu finden mit ein paar BTC drauf, und diesen Fund dann nicht hier zu melden und sich stattdessen einfach die BTC zu krallen?
Das geht auch trotz dem Super-Schutz mit Code Execution, denn der Server bekommt den Fund nicht mit - oder doch? Der bekommt nur gemeldet "habe Block X untersucht".
Die ganze Spielerei mit RCE nur für die Rangliste?
Habe mich eingelesen und verstehe jetzt, dass du den Client überprüfen willst, damit keiner schummelt, aber wogegen genau soll das denn schützen?
Nur damit sich keiner in der Rangliste an Platz 1 hackt?
Klar, du hast gesagt, du willst nicht, dass jemand Bereiche als überprüft markiert, die noch nicht überprüft wurden.
Damit euch/uns kein einziger Bereich entgeht?
Oder damit die Rangliste nicht verfälscht wird?
Ich meine, der LBC hat doch die Ergebnisse eh nur offline, oder?
Was hindert einen daran, mit dem LBC ne Bitcoin-Adresse zu finden mit ein paar BTC drauf, und diesen Fund dann nicht hier zu melden und sich stattdessen einfach die BTC zu krallen?
Das geht auch trotz dem Super-Schutz mit Code Execution, denn der Server bekommt den Fund nicht mit - oder doch? Der bekommt nur gemeldet "habe Block X untersucht".
Die ganze Spielerei mit RCE nur für die Rangliste?
June 09, 2017, 08:13:31 AM
Und weshalb? War doch eigentlich nicht zu erwarten..?
June 09, 2017, 02:36:54 AM
Unsere Nr. 1 ist zurück und er hat Tesla P100 GPUs im Gepäck...
...
Ja, der gibt mir immer nen root account, damit ich ihm die erste Maschine aufsetze.
Um so Sachen wie "Backdoors" muss man sich dann keine Sorgen machen.
Ich kann aber erstmal jeden beruhigen, die Perfomance der P100 GPUs ist erstaunlich schlecht.
...
Ja, der gibt mir immer nen root account, damit ich ihm die erste Maschine aufsetze.
Um so Sachen wie "Backdoors" muss man sich dann keine Sorgen machen.
Ich kann aber erstmal jeden beruhigen, die Perfomance der P100 GPUs ist erstaunlich schlecht.
kannst du bitte mal einen unwissenden aufklären?
1)
Unsere Nr. 1 = Unknownhostname, siehe LBC Statistiken. Der gute Mann hat mit - geschätzt - 4000 CPU Kernen eine zeitlang so 90% der Poolkapazität gestellt und auch heute noch gehen irgendwas um die 4000 Tera-Keys von den 5700 des gesamten Pools auf seine Kappe.
Sollte der sich entscheiden diesmal mit GPUs anzutanzen, dann wird die Poolspeed wieder in Giga-Keys/Sekunde gemessen werden.
Und er hat wohl Zugriff auf Amazon Maschinen, die noch gar nicht offiziell sind. Ich vermute, es ist wohl ein Admin bei Amazon Web Services.
2)
Er gibt mir (hier via PM) einfach mal immer wieder einen Root-Account zu solchen Maschinen, damit ich die teste/aufsetze. So geschehen gestern mit einem client, der 56 Kerne(?) und 2 x P100 GPUs hatte. Meine Anmerkung war ein Seitenhieb auf den Shitstorm, der sich Ende April über den LBC ergossen hatte.
3)
Erstaunlicherweise sind die P100 aber sehr schlecht was die Performance anbelangt - zumindest unter LBC. Bereits 5 Broadwell-Kerne lasten so eine P100 aus - laut nvidia-smi, die Karte wird aber nicht warm. Also irgendwas macht der LBC "falsch". Aber soweit mir bekannt, ist das auch nur die Pascal Architektur wie bei einer 10xx und da klappt alles.
June 08, 2017, 01:12:20 PM
Hallo zusammen, ich wollte auch mal bisschen spielen und was sinnvolles machen :-)
wenn ich die VM das erste Mal starte macht er ein Update vom Client danach bekomme ich beim starten LBC -x nur noch Fehler.
Error laoding Shared Libarys. Kann mir mal bitte jemand helfen.
wenn ich die VM das erste Mal starte macht er ein Update vom Client danach bekomme ich beim starten LBC -x nur noch Fehler.
Error laoding Shared Libarys. Kann mir mal bitte jemand helfen.
Alles Folgende aus dem Stegreif/Hinterkopf, ungetestet ohne Gewähr:
$ pacman -Syu
(damit das System einigermaßen up-to-date ist)
$pacman -S ocl-icd
(dummy OpenCL Lib)
$ cd collider
$ wget https://lbc.cryptoguru.org/static/client/LBC
$ touch diagnostics-OpenCL.txt
$ ./LBC -x
Ab da sollte es so ziemlich tun.
June 08, 2017, 12:43:22 PM
Unsere Nr. 1 ist zurück und er hat Tesla P100 GPUs im Gepäck...
Ja, der gibt mir immer nen root account, damit ich ihm die erste Maschine aufsetze.
Um so Sachen wie "Backdoors" muss man sich dann keine Sorgen machen.
Ich kann aber erstmal jeden beruhigen, die Perfomance der P100 GPUs ist erstaunlich schlecht.
Code:
root@host1:~# nvidia-smi
Thu Jun 8 11:58:01 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 375.66 Driver Version: 375.66 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla P100-PCIE... On | 0000:81:00.0 Off | 0 |
| N/A 29C P0 42W / 250W | 4820MiB / 16276MiB | 79% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla P100-PCIE... On | 0000:82:00.0 Off | 0 |
| N/A 27C P0 41W / 250W | 4820MiB / 16276MiB | 81% Default |
+-------------------------------+----------------------+----------------------+
Ja, der gibt mir immer nen root account, damit ich ihm die erste Maschine aufsetze.
Um so Sachen wie "Backdoors" muss man sich dann keine Sorgen machen.
Ich kann aber erstmal jeden beruhigen, die Perfomance der P100 GPUs ist erstaunlich schlecht.
kannst du bitte mal einen unwissenden aufklären?
June 08, 2017, 11:57:39 AM
Unsere Nr. 1 ist zurück und er hat Tesla P100 GPUs im Gepäck...
Ja, der gibt mir immer nen root account, damit ich ihm die erste Maschine aufsetze.
Um so Sachen wie "Backdoors" muss man sich dann keine Sorgen machen.
Ich kann aber erstmal jeden beruhigen, die Perfomance der P100 GPUs ist erstaunlich schlecht.
Code:
root@host1:~# nvidia-smi
Thu Jun 8 11:58:01 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 375.66 Driver Version: 375.66 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla P100-PCIE... On | 0000:81:00.0 Off | 0 |
| N/A 29C P0 42W / 250W | 4820MiB / 16276MiB | 79% Default |
+-------------------------------+----------------------+----------------------+
| 1 Tesla P100-PCIE... On | 0000:82:00.0 Off | 0 |
| N/A 27C P0 41W / 250W | 4820MiB / 16276MiB | 81% Default |
+-------------------------------+----------------------+----------------------+
Ja, der gibt mir immer nen root account, damit ich ihm die erste Maschine aufsetze.
Um so Sachen wie "Backdoors" muss man sich dann keine Sorgen machen.
Ich kann aber erstmal jeden beruhigen, die Perfomance der P100 GPUs ist erstaunlich schlecht.
June 07, 2017, 10:11:15 AM
EM Style = Der Versuch das Unmögliche zu lösen.
Wie erfolgreich das Ganze langfristig ist steht in den Sternen, aber wie andere es hier einfach als Zeitverschwendung deklarieren ist wie die Broker, die damals den Aktienkurs von Tesla geshorted haben und ordentlich auf die Fresse bekommen haben.
Strafe die Hater mit Ignoranz
Wie erfolgreich das Ganze langfristig ist steht in den Sternen, aber wie andere es hier einfach als Zeitverschwendung deklarieren ist wie die Broker, die damals den Aktienkurs von Tesla geshorted haben und ordentlich auf die Fresse bekommen haben.
Strafe die Hater mit Ignoranz
June 07, 2017, 09:29:35 AM
Ich finde die Idee hier genial. Hat was von Elon Musk Style 
Elon Musk Style = man macht etwas, an das vorher überhaupt nicht zu denken war, aber man kann trotzdem mit Heerscharen von "Kritikern" rechnen.
June 07, 2017, 04:31:44 AM
Ich finde die Idee hier genial. Hat was von Elon Musk Style
Elon Musk Style = Schulden und nur Schulden, alles so zusagen auf Wasser geschrieben… den Schuldenberg wird Er Niemals tilgen können HA, Ha, ha... June 07, 2017, 02:53:03 AM
Ich finde die Idee hier genial. Hat was von Elon Musk Style
June 07, 2017, 02:45:05 AM
https://www.heise.de/forum/heise-online/News-Kommentare/Schneeballsystem-Millionenstrafe-fuer-Bitcoin-Mining-Firmen-GAW-Miners-und-Zenminer/Der-Large-Bitcoin-Collider-ist-pure-Augenwischerei-und-Energieverschwendung/posting-30500067/show/
Na? Heute schon eine Kathedrale angepisst Wuffi?
Quote
Ergo, der LBC ist aus Kaese, nicht der Mond. Und der Gründer des LBC ist eine kleiner Gernegross.
Na? Heute schon eine Kathedrale angepisst Wuffi?
May 31, 2017, 04:20:12 AM
Also das mit dem Release dauert noch ein wenig... 
Der Generator funktioniert blendend und auf Maschinen mit kräftigen GPUs (1060 aufwärts) gibt's wirklich eine Verdoppelung der Keyrate.
Allerdings werden die CPU-only clients effektiv langsamer.
Hat mich etwas überrascht, weil die ECC Berechnungen auch auf CPU clients wesentlich effizienter sind, allerdings ist da der Flaschenhals eben nicht mehr die EC-Arithmetik, sondern der hash160.
Die hashing-Last steigt normal auf das Doppelte (wie gesagt bei starken GPUs kein Problem, die werden einfach nur besser ausgelastet), aber bei Generatoren, wo die arme CPU das Hashing machen muss, geht die Performance in die Knie. Ich vermute, dass dann die 4 x hash160 bereits den CPU Cache trashen. Oder irgendwas in der Richtung.
Kein Grund zur Panik, wird n-k Symmetrie eben optional sein. Leute mit starken GPUs schalten das einfach ein, Leute mit CPU-only lassen's bleiben.
Leute mit mittelstarken GPUs (so wie ich), bekommen einen leichten Geschwindigkeitszuwachs mit weniger CPU Last.
Konkret bei mir
ohne n-k sym: 4 CPUs + 80% M2000M = 22.3 Mkeys/s
mit n-k sym: 3CPUs + 100% M2000M = 27.x Mkeys/s
Diese Symmetrie ist also was für Leute mit CPU-GPU Gespann bei dem eben die CPUs nicht die GPU auslasten können.
Bzw. - vorerst nur Theorie - wird die n-k Symmetrie auch bei "CPU-only" Clients von Vorteil sein, die eben das Hashing effizienter durchführen können. Ich denke da speziell an Intel Goldmont und AMD Ryzen CPUs, die Hardware-Unterstützung für SHA256 haben.
So nun das Problem.
Da ich beide Typen von Clients unterstützen muss, gestaltet sich die Buchhaltung der abgelieferten Blöcke auf dem Server haariger als gedacht. Denn die Schlüssel sind zwar hübsch symmetrisch, die Blocknummern jedoch nicht (einfach weil
0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f (unser "n") nicht durch 220 teilbar ist.)
Ich bekomm's schon hin - das ist ja alles noch keine Rocket Science - ist eben nur mehr Arbeit als gedacht, folglich dauert's. Also nicht wundern, wenn diesbezüglich erstmal eine Weile Funkstille ist.
Der Generator funktioniert blendend und auf Maschinen mit kräftigen GPUs (1060 aufwärts) gibt's wirklich eine Verdoppelung der Keyrate.
Allerdings werden die CPU-only clients effektiv langsamer.
Hat mich etwas überrascht, weil die ECC Berechnungen auch auf CPU clients wesentlich effizienter sind, allerdings ist da der Flaschenhals eben nicht mehr die EC-Arithmetik, sondern der hash160.
Die hashing-Last steigt normal auf das Doppelte (wie gesagt bei starken GPUs kein Problem, die werden einfach nur besser ausgelastet), aber bei Generatoren, wo die arme CPU das Hashing machen muss, geht die Performance in die Knie. Ich vermute, dass dann die 4 x hash160 bereits den CPU Cache trashen. Oder irgendwas in der Richtung.
Kein Grund zur Panik, wird n-k Symmetrie eben optional sein. Leute mit starken GPUs schalten das einfach ein, Leute mit CPU-only lassen's bleiben.
Leute mit mittelstarken GPUs (so wie ich), bekommen einen leichten Geschwindigkeitszuwachs mit weniger CPU Last.
Konkret bei mir
ohne n-k sym: 4 CPUs + 80% M2000M = 22.3 Mkeys/s
mit n-k sym: 3CPUs + 100% M2000M = 27.x Mkeys/s
Diese Symmetrie ist also was für Leute mit CPU-GPU Gespann bei dem eben die CPUs nicht die GPU auslasten können.
Bzw. - vorerst nur Theorie - wird die n-k Symmetrie auch bei "CPU-only" Clients von Vorteil sein, die eben das Hashing effizienter durchführen können. Ich denke da speziell an Intel Goldmont und AMD Ryzen CPUs, die Hardware-Unterstützung für SHA256 haben.
So nun das Problem.
Da ich beide Typen von Clients unterstützen muss, gestaltet sich die Buchhaltung der abgelieferten Blöcke auf dem Server haariger als gedacht. Denn die Schlüssel sind zwar hübsch symmetrisch, die Blocknummern jedoch nicht (einfach weil
0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f (unser "n") nicht durch 220 teilbar ist.)
Ich bekomm's schon hin - das ist ja alles noch keine Rocket Science - ist eben nur mehr Arbeit als gedacht, folglich dauert's. Also nicht wundern, wenn diesbezüglich erstmal eine Weile Funkstille ist.
May 25, 2017, 01:24:57 PM
Jedenfalls werden die GPU user bald eine Verdoppelung der Geschwindigkeit bekommen.
Das ist mal ne krasse Ansage!
11.9 Mkeys/s derzeit. Ich lasse das jetzt mal stehen - auch wenn mir der code noch nicht gefällt und fange mal mit dem Release an.
Da muss noch einiges getestet werden. Optimieren kann man ja dann immer noch.
May 25, 2017, 06:57:38 AM
Jedenfalls werden die GPU user bald eine Verdoppelung der Geschwindigkeit bekommen.
Das ist mal ne krasse Ansage!
Das Einzige was zur Zeit das colliden stört, sind die ebenfalls stark angestiegenen Außentemperaturen! Ist auch ohne laufenden PC bereits schön warm in der Bude.
May 25, 2017, 06:16:50 AM
Es ist soweit. Seit heute früh 5:45 wird... ach neee andere Baustelle.
Jedenfalls werkelt seit heute ein provisorischer Prototyp auf meinem Rechner, der 10.8 Mkeys/s pro CPU Kern zustande bringt (GPU 25% Last).
Noch vollkommen unoptimiert, ich hoffe, das vor dem Release noch um knapp 1 Mkeys/s steigern zu können.
Jedenfalls werden die GPU user bald eine Verdoppelung der Geschwindigkeit bekommen.
CPU-only clients werden auch schneller, aber nur so 15-20%.
Jedenfalls werkelt seit heute ein provisorischer Prototyp auf meinem Rechner, der 10.8 Mkeys/s pro CPU Kern zustande bringt (GPU 25% Last).
Noch vollkommen unoptimiert, ich hoffe, das vor dem Release noch um knapp 1 Mkeys/s steigern zu können.
Jedenfalls werden die GPU user bald eine Verdoppelung der Geschwindigkeit bekommen.
CPU-only clients werden auch schneller, aber nur so 15-20%.
May 19, 2017, 05:36:31 AM
hallo, ist etwas "offtopic",
Ich weiß, entschuldigung dafür. Hab es hier reingeschrieben, weil ihr hier Ahnung habt.
Danke!
May 19, 2017, 05:11:10 AM
Danke, aber damit tauchen die pattern irgendwo in der Adresse auf und nicht explizit am Anfang und Ende :-(
'^1Happy.+trade$'
wobei ich das mit dem Ende nicht so positiv sehe, weil das eigentlich schon die sha256d checksum ist und wenig Chancen auf Erfolg hat.
Wenn ich mich nicht irre, gehen regex auch nur bei vanitygen, nicht bei oclvanitygen.
Was das in diesem Thread verloren hat, ist mir auch schleierhaft, daher meine hochqualifizierte und definitive Antwort (um weiteres Nachbohren zu vermeiden).
Jump to: