Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread

[rico666]

edit:  Weil ich gerade die Pool Speed sehe. 256 Mkeys/s - das sind 2 Millionen Seiten auf directory.io pro Sekunde. Schon krass. 

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

2016-09-14: 500 bn keys (1 tn addresses) searched
2016-09-10: New client available 3x speedup
2016-09-07: Windows clients - although quite bad - available
2016-08-29: 1st "real" pool bounty found
2016-08-10: pool inception - roughly 0.15 MKeys/s
16 Jul/Aug: stand-alone experiments, then client and pool development
2016-07-28: standalone client: 36bits searched

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



Rico

[1715123393]

1715123393

[1715123393]

1715123393

[1715123393]

1715123393

[1715123393]

1715123393

[1715123393]

1715123393

[1715123393]

1715123393

[rico666]

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

[hodlcoins]

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?

[rico666]

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?

https://bitcointalk.org/index.php?topic=1573035.msg18206936#msg18206936

Exceptionally, I set the pool computational front to 2^50. We will cover the ~370 tn keys after we have found #51.

You will see this on block numbers > 1073770688

The stats about predicted find time for #51 are therefore not correct anymore (because the pool is aware of missing ~370 tn keys).

=> Wir machen das später nach


Rico

[hodlcoins]

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?

[rico666]

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?

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

[hodlcoins]

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

[hodlcoins]

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 

[rico666]

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 

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

[Lincoln6Echo]

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 

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

Weisst du welche Features ein FPGA haben müsste um dafür in Frage zu kommen? Ich kenne mich damit überhaupt nicht aus aber es interessiert mich
Würde solch ein FPGA zum Beispiel in Frage kommen?
https://www.altera.com/products/fpga/max-series/max-10/features.html

[rico666]

Weisst du welche Features ein FPGA haben müsste um dafür in Frage zu kommen? Ich kenne mich damit überhaupt nicht aus aber es interessiert mich
Würde solch ein FPGA zum Beispiel in Frage kommen?
https://www.altera.com/products/fpga/max-series/max-10/features.html

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

[Lincoln6Echo]

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:

[rico666]

...oder der Code war bislang sehr schlecht.

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

Code:

$ nvidia-smi 
Sat Mar 25 07:37:19 2017       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 378.13                 Driver Version: 378.13                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Quadro M2000M       Off  | 0000:01:00.0     Off |                  N/A |
| N/A   63C    P0    N/A /  N/A |   2201MiB /  4042MiB |     81%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|    0     21092    C   ./gen-hrdcore-skylake+gpu-linux64              540MiB |
|    0     21094    C   ./gen-hrdcore-skylake+gpu-linux64              540MiB |
|    0     21095    C   ./gen-hrdcore-skylake+gpu-linux64              540MiB |
|    0     21096    C   ./gen-hrdcore-skylake+gpu-linux64              540MiB |
+-----------------------------------------------------------------------------+

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

[Real-Duke]

Wir haben also noch etwas Reserve nach oben.  

Ich werde jetzt noch etwas testen, Pakete schnüren und dann die Versoin auf den Server schieben.
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!

[rico666]

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

Code:

# LBC -u
New generator found. (DL-size: 0.54MB)
BLF patch found. (DL-size: 206.96MB)
Finished update run - system up to date.

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

[Janu$$]

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$$

[hodlcoins]

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?

[Janu$$]

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

Gibt es eine Anleitung, wie ich die Updates manuell in die VM einpflegen kann?
Dateien kann ich auf einem anderen Rechner ohne die Firewall runterladen.

Grüße,
Janu$$

[rico666]

@hodl:
Ich glaube, das "best generator chosen" habe ich weggemacht.

@Janu$$

ftp://ftp.cryptoguru.org/LBC/client/LBC holen

passenden Generator von hier holen.
ftp://ftp.cryptoguru.org/LBC/generators/

sse41 gibts momentan nicht. ggf. in der VM konfig einstellen, dass er die CPU Features an die virtuelle Maschine weiterreicht.
auspacken, umbenennen, ausführbar machen

Code:

bunzip2 datum-md5.name.bz2
mv datum-md5.name name
chmod a+x name

neuesten Bloom filter holen
ftp://ftp.cryptoguru.org/LBC/blf/
(sind die .blf.bz2 Dateien mit den 17MMTT- am Anfang) also neuestes Datum holen.


Bloom filter auspacken umbenennen z.B.

Code:

bunzip2 170316-58afd82e681f19b2faf464851aee8541.blf.bz2
mv 170316-58afd82e681f19b2faf464851aee8541.blf hash160_funds.blf

Rico

[Janu$$]

@rico
Danke!