Ok.
Bei dem Projekt geht es im Grunde genommen darum private Keys zu finden zu Adressen auf denen Bitcoins liegen.
Das hat zunächst einmal den Aufkleber "unmöglich" und ist für mich daher genau die richtige Herausforderung.
http://directory.io/ kennst Du ja. Nun könnte man versuchen mit wget auf directory.io loszugehen, allerdings würde
- selbst wenn man eine Seite pro Sekunde abarbeitet - unsere Sonne früher verlöschen, bevor man auch nur 10
-56%
des Suchraumes abgegrast hätte.
Unsere Sonne wird nämlich in ca. 157680000000000000 Sekunden kaputt sein und bei 115792089237316195423570985008687907853269984665640564039457584007913129639936 privaten Schlüsseln und 128 davon pro Seite, sinds halt 904625697166532776746648320380374280103671755200316906558262375061821325312 Seiten.
Also muss man schneller sein. Das versucht dieses Projekt. Wie?
1) Es gibt die Möglichkeit die Keys offline zu generieren. Gegenwärtig schaffe ich mit einem (dickeren) Server 300.000 keys pro Sekunde, mithin das Äquivalent von 2343 Seiten auf directory.io
pro Sekunde.
(und schon hätte ich 10
-52% des Suchraumes abgegrast bevor unsere Sonne verlöscht)
2) Nun muss man aber wissen, dass der Suchraum gar nicht 256bit ist, sondern im Schnitt nur 160bit, denn es gibt zwar 2
256 private Schlüssel, aber diese werden auf 2
160 Adressen abgebildet. Daraus folgt übrigends, dass es im Schnitt pro Bitcoin Adresse 2
96 private Schlüssel gibt.
3) Dann ist es ja nicht so, dass man nach einer bestimmten Adresse sucht auf der Bitcoins liegen, sondern nach
irgendeiner. Davon gibt es derzeit etwas über 9.2 Millionen.
Wollen wir mal kurz nachrechnen:
Suchraum 2
160 geteilt durch 9.2 * 10
6 bedeutet ich muss 158858873622924230239530960077856849962601 Adressen abnudeln bis ich mit 100% Wahrscheinlichkeit auf eine stoße, die Bitcoins gelagert hat. Mit meinen 300k pro Sekunde brauche ich nur noch 16791272791193580906427676314 Jahre. Das mag sich nach viel anhören, aber immerhin kann ich bereits 0.00000000000939059248% des Suchraumes abhandeln bevor unsere Sonne verlöscht. Das ist gegenüber den 10
-56% von oben doch schon ein Fortschritt.
Das alles noch unter den Voraussetzungen, dass ich alleine suche und dass ich die Schlüsselgenerierung nicht beschleunigen kann. Ich möchte mit dem Collision Finders Pool eine Infrastruktur aufbauen, die diese Suche nach Kollisionen bestmöglich unterstützt. D.h. effiziente Verteilung der Suche auf möglichst viele Teilnehmer und Beschleunigung der Generierung von Adressen.
Was also steht an?
Der Pool funktioniert bereits und verteilt Suchblöcke an Clients von gegenwärtig 3 Betatestern. Die Clients nutzen momentan nur die CPU und vermutlich auch noch nicht besonders effektiv. Ich hoffe in den kommenden Tagen/Wochen
- bessere CPU clients
- wesentliche bessere GPU clients
zu bekommen. Und es ist im Übrigen Waschweiber-Gewäsch man könne ASICs (ggf. die Miner) prinzipiell nicht für so eine Aufgabe herannehmen. Gegenwärtig sind 6 x SHA256 Berechnungen notwendig pro privaten Key (compressed/uncompressed address). Wenn ich mir die Beschleunigung beim Mining ansehe, wo heutige moderne Miner um einen Faktor 1.000.000 und mehr schneller sind als die CPUs mit denen Mining angefangen wurde...
Es ist nicht abwegig, dass man 300GK/s (GigaKeys pro Sekunde) mit ASICs in einem "miner-ähnlichen Gerät" hinbekommen würde.
Es können sich nun im Laufe der Zeit diverse Eigenheiten des RIPEMD160(SHA256(x)) Verfahrens zeigen, vielleicht Informationen die bestimmte Bereiche des Suchraumes lohnenswerter erscheinen lassen als da brute force uniform durchzumarschieren (im übrigen habe ich da bereits eine Vermutung, aber der Rand ist hier zu schmal um sie niederzuschreiben).
Mit so einem operativen Pool steht man dann ja auch schnell Gewehr bei Fuß um solche Gebiete abzugrasen.
Aber um es ganz klar zu sagen: Derzeit ist das Minen von X mit GPUs und ASICs wesentlich "lukrativer" als irgendeine Suche nach Kollisionen.
Deswegen ist diese Suche hier eher was für ungenutzte CPU Kapazitäten.
Ok - so in etwa. Ich hoffe, es wurde etwas klarer, worum es hier geht. Man könnte noch mehr schreiben (wie z.B. dass auch wenn der Pool nie etwas finden würde, dies auch Vorteile hat - nämlich für den Bitcoin als Ganzes, etc.) aber ich denke diese ersten paar Worte sollten reichen.
Rico
