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-walletsund 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.
