Topic: Large Bitcoin Collider (Collision Finder Pool) - Deutscher Thread - page 18. (Read 51016 times)

Hallo Rico,

vielen Dank für Deine ausführliche Antwort.
Bezüglich den KEYs ist mir jetzt alles klar und das entspricht ja auch dem was auf Directory.io steht. 

Nun zur Benachrichtigungs E-Mail:

Ich habe hier bereits einen vollwertigen Mail-Server.
Als MTA habe ich mich auf den Linux-Kisten jetzt mal für SSMTP entschieden. Ist dem Grunde nach mutt sehr ähnlich. 

Ich habe als erstes die Config von ssmtp angepaßt und natürlich auch meinen Mailserver, so das er Emails von den Linux-Kisten überhaupt annimmt. Das hat soweit geklappt und eine erste leere Testmail wurde versendet.

Dann habe ich mit das ssmtp-Kommando zusammen gebaut für das versenden an meine E-Mail und das anhängen/einfügen in den Body der FOUND.txt-Datei. Auch das hat funktioniert und nachdem ich mir hilfsweise mit ./LBC -x eine FOUNDS.txt erzeugt hatte konnte ich die auch per Komando-Zeile erfolgreich an mich versenden.

Aktuell sieht der Befehl bei mir so aus:


Jetzt bitte nicht lachen, aber ich habe wirklich keine Ahnung von Linux:

Gehe ich recht in der Annahme, daß ich die Komandozeile von oben jetzt in eine Datei kopieren muß und diese im Verzeichnis  /collider liegen muss und "hook-find" heißen soll?

Wenn ja, was hat es mit dem "#!/bin/bash" aus Deinem Beispiel auf sich & muß ich die Datei noch irgendwie ausführbar machen?

Danke & Gruß Carsten.

Hm. Schwierig. Hängt nämlich davon ab ob/wo/wie der Mailversand konfiguriert ist.
Beispiel wie ich das bei mir habe:


Mutt ist ein mailclient, der es auch ermöglicht über Kommandozeile gesteuert zu werden. (Ich denke obiger Befehl ist selbsterklärend, ggf. Help aufrufen. In diesem fall würde bei Dir bspw. hook-find in etwa so aussehen:




Das größere Problem ist den MTA zu konfigurieren und da gibt es keine Einheitslösung. Exim, postfix, sendmail (Gott bewahre), oder an ein Relay senden... Da müsste man konkret wissen was für eine Mail-Infrastruktur vorhanden ist. Wenn Du bereits einen Mailserver hast, der auf Port 25 z.B. aus dem internen Netz connections akzeptiert, kannst Du das ja direkt an den schieben. Ich verwende manchmal exim, manchmal postfix.

Zu der privkey Sache. Du hast es ja schon herausgefunden, der folgende link

http://directory.io/3196241445567#5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEXxDuJBiUbiVA9e

hilft noch besser/visuell die Zusammenhänge zu sehen. (uncompressed <-> compressed)


Jo.



Rico

Hallo zusammen,

ich habe mal noch 2 Fragen bzw. bräuchte, als Windoff-User, mal Hilfe.

Als erstes würde ich gerne eine E-Mail versenden wenn etwas gefunden wird. - Dies soll ja mit "hook-find" gehen. - Leider habe ich Null Plan wie ich das Hook-Komando nutze bzw. einbinde und ob ich auf den Servern vorgängig noch irgendwas einrichten muss.
Für eine Noob-Anleitung wäre ich dankbar.  

Zum Zweiten geht es um den Fall das etwas gefunden wird. - Hier habe ich mir mal exemplarisch die Puzzel-Transaktion Nr. 49 vorgenommen.

Gefunden wurde:


Wenn ich nun den Hash 160 auf Blockchain.info suche, so verweist dieser auf 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF und der dort angezeigte HASH 160 stimmt auch überein. Soweit so gut.  

Nun wandle ich den Privat-Key in das WIF.


Dies dann mit Hilfe von node.js und coinstring zum WIF umgewandelt ergibt den folgenden Key:


Dies ist identisch mit dem hier angegebenen Key.

Wenn ich jetzt diesen Key in meine Wallet bei Blockchain.info importiere wird mir aber eine völlig andere BTC-Adresse & auch ein abweichender HASH 160 angezeigt.  

Blackchain.info meldet nach dem Import:

Ein Blick auf die Adresse 1HXocSh2faBTiw7PiLyDJhyrxeczrfDD52 zeigt dann bei Blockchain.info:

HASH 160:

Wo liegt der Fehler ?  

Kann ich jetzt selber beantworten:

Der KEY ist falsch. - Der korrekte KEY zu 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF lautet:


Warum? - Weil beim umwandeln in das komprimierte WIF zum Private Kay noch 0x01 hinzu muss. - Dann klappt's auch mit dem Import.

Ich lasse sowohl Frage als auch Antwort jetzt mal stehen, damit es auch sonst der eine oder andere noch nachvollziehen kann.

Über eine Antwort zu meiner ersten Frage würde ich mich natürlich immernoch freuen.


Danke & Gruß Carsten.

.

Gar nicht - ist eine interne Sache zwischen dem LBC client und dem Generator.

Angenommen eine CPU hat 320M keys zu generieren
Anstatt, dass der LBC nun pro 16M Blöcke 20 x einen Generator startet, startet er ihn einmal und sagt ihm "Du machst jetzt 20 x 16M blöcke"
und gibt ihm den Parameter -L 20 it

Das siehst Du in der Prozesstabelle, aber machen musst Du da nichts.

edit:


Alles ist relativ, in diesem Fall aber leider doch. Wenn die Platte so 411 MB/s sequentiell hat (http://www.anandtech.com/show/4863/the-samsung-ssd-830-review/2), dann dauert das Laden des 512MB blf files 1.2 Sekunden. In der Zeit hätte Deine CPU schon so 600-750' Keys pro Kern generieren können. Nun hat Linux zwar Caching-Mechanismen, die greifen aber nur, wenn der Hauptspeicher nicht anderweitig belegt ist und wie das auf einer VM im Zusammenspiel mit dem VMplayer (und dem drunterliegenden Win) ist, entzieht sich meiner Kenntnis, aber performanter als direkt auf HW wird das kaum sein.
In jedem Fall sparen wir uns nun dieses und noch andere startup-Kosten (berechnen von 8192 Konstanten für die ECC Arithmetik u.a.)
das macht sich natürlich in der Keyrate bemerkbar.

Aber wie schon oben erwähnt, kann man das natürlich auch so sehen, dass der Programmcode bislang schlecht war - immer so auf die armen Platten einzudreschen. Glücklicherweise nur lesend, also keine Spätfolgen für SSDs

Rico

Hmm habe in meinem Desktop ne Samsung 830PRO SSD, also lahm sollte die nicht sein...


Stimmt das war doch noch neu mit -L
Aber wie nutzt ein Noob wie ich das?
Habe mich eben bestimmt 45 Minuten damit befasst es mir einfacher zu machen und mir eine lbc.json erstellt.
Bis die dann mal ohne Fehlermeldung genommen wurde  

Dann hast Du eine lahme Platte. :-)

Bevor es diesen -L Parameter gab, ist ein Generator wegen 16M keys gestartet (und wieder beendet) worden.
Dabei hat er mal eben das 512MB BLF File geladen.

Ich habe davon nichts mitbekommen - mit meiner 2.5GB/s SSD. Und auch jetzt sind für mich die neuen Versionen nicht schneller, aber sonst überall im Lahm-Festplattenland sind Jubelschreie zu vernehmen. 

So richtig habe ich das gemerkt als die AWS Instanzen mit ihren 32 GPU generatoren nicht schneller waren als die CPU Instanzen. 

Naja - jetzt wird ja alles gut.


Rico

An einer USB Stick Version wäre ich auch interessiert, nur  mal zum testen...

Bin einen Schritt weiter gekommen.
In der VM habe ich 8 Cores eingestellt, dann erstmal das Update auf 1.031 und schwups mit -t 8 rennt die Kiste auf 100% und kommt auf 2,91Mkeys 
Damit ist der Rechner dann aber echt für nichts anderes mehr zu gebrauchen, außer vieleicht als Zusatzheizung.
Stelle ihn wieder auf 4 Cores und lasse ihn schnurren.

Linux vom USB Stick booten klingt gut! Kann man dafür so ein Bootfähiges Image evtl auch schon vorbereiten wie die VM Images? Wenn ich da mal angekommen bin, möchte ich sehen was meine Geforce 1060 bringt.
Morgen beschäftige ich mich nochmal mit dem Thema Proxyserver in der Firma...danke für den Tip weiter oben.

Ja, sorry hatte nur 3 Beiträge hochgescrollt und den bzgl. dem DEATH KISS nicht gesehen.
Sollte dann gleich wieder laufen ... 

Danke & Gruß, Carsten.

Anweisung: Vielleicht mal die Beiträge oben lesen.

Kurzfassung: 1.031 holen, dann sollte der Spuk ein Ende haben.


Rico

Ähm, was soll mir das hier sagen?

Auf allen meinem 3 Mega-Servern wurde LBC gelöscht!?  


Bitte um Anweisung / Hilfe. - Danke.


Gruß Carsten.

@Real

Bin kein Windows-Experte, aber die VMware Maschine kann man hinsichtlich Netzwerkconfig entweder im NAT-Modus oder Bridged betreiben.
Wenn man "Bridged" einstellt, dann verhält die sich meiner Erfahrung nach transparent wie die Mutterkiste.

Da das für die Mehrzahl der Fälle auch schön bequem ist, ist das wohl der Default.
Was Du willst, ist aber:

http://www.sysprobs.com/internet-access-proxy-vmware-guest-machine

@Hodl

Es gilt wohl beides. 
Im Nachhinein betrachtet war der Code früher immer schlecht, aber es braucht viel Talent (und Schweiß!), um in die "Im Nachhinein betrachtet" Situation zu kommen.
Ich meine, ich habe ja angefangen mit ca. 13000 keys/s pro CPU Kern...

Da dachte ich es sei geil verglichen mit 128 key/s und habe bissige Bemerkungen Richtung Willi geschickt
https://bitcointalksearch.org/topic/m.15638727

Aus heutiger Sicht war ich damals ebenso Dödel 
Und wer weiß was wir in 1 Jahr sagen...



Mache ich auch gerade auf der Gamer-Maschine meines Sohnes (Ubuntu 16.04 Desktop auf dem USB Stick installieren)
damit ich das mal mit einer AMD GPU ausprobieren kann. Angeblich läuft's ja - sagen die User, nur bei mir bislang noch nicht 



Rico

Argh das hatte ich gestern bei einem meiner Versuche die CPU voll auszulasten auch. Ich sah irgendwas von Update, aber es schien alles zu laufen und als er eigentlich fertig sein sollte mit dem Block -> Kiss of Death!

Danke Euch für die Hinweise, ich schaue mir das heute Abend nochmal an.
Hat nicht jemand auch noch zufällig einen Tip, wie ich mit einer VM durch einen http Proxy kommunizieren kann? Ich habe das aufgegeben @work  

Whoa, Danke!
Mein anderer Rechner liefert jetzt 3,0x ab, also aus insgesamt 4 sind 5,2MKeys geworden. Nur mal eben so 30% mehr.
Entweder bist du ein sehr guter Mathematiker/Programmierer, oder der Code war bislang sehr schlecht.

Jetzt muss ich auch noch eine native Kiste Lunixen

Diese Death Kiss Sache war ein wildgewordener Sicherheitsmechanismus, der in Kraft treten sollte (eigentlich), wenn jemand an den Binaries/Skripten pfuscht.
Mit 1.031 sollte dieses Problem der Vergangenheit angehören.
Es gab noch einen update_system() aufruf - unabhängig von LBC -u, leider war der erst nachdem die Checksumme der Skripte berechnet wurde.

Also nahm die Tragödie ihren Lauf:

LBC startet und berechnet die Programm-Checksum
Merkt, dass es ein Update gibt und holt das
Fängt an zu arbeiten
Am Ende wird der Block abgeliefert mitsamt client Version
"Oha! Andere Client version als checksum" denkt sich der Server -> Boom

Ähnlich bei der query, wo zwischen Start und absenden der Query auch noch ein update eingeschoben war.
Sprich wenn ihr LBC beendet, einfach mal in Ruhe ein LBC -u machen, wenn ihr den 1.031 client bekommt ist die Sache in trockenen Tüchern.


Zur Steigerung der Keyrate: Na klar yeehaw Ich optimiere ja wo es geht. Wir haben schliesslich viel Arbeit vor uns.


BTW: Willkommen in den top30! -> GPU auth


Rico

Holy sh*t what have you done?

Ich hab gerade mal gecheckt, wie viele GKeys ich schon habe, und anschließend gabs den Death Kiss.
Also gut, -x...
Dann wundert mich schon, das der Kasten auf einmal 1900MKeys abholt anstatt 1500, und nun steht da 2,18MKeys/s statt 1,6 bei unveränderten Einstellungen usw.
Yeeeehaaaw!

@Real-Duke
das hört sich für mich so an, als ob du der VM nicht genug Kerne eingestellt hast, und damit deine -c-Einstellung von der VM itself begrenzt wird.
Da gibts ja die Einstellung, damit eine VM mit Hunger nicht den Host außer Betrieb nimmt, und genau das passiert hier ja auch.
Der genaue Wortlaut des Fehlers wäre schon interessant, vielleicht nur ein Vertipper im Secret oder so, aber 8 Kerne brauchen auch satt RAM, vielleicht wars das auch.

Die CPU ist ein Xeon 1230v3 mit 4 Kernen + HT und den LBC starte ich mit -c 4
Wie gesagt, mache ich nichts weiter sind es so um die 2 -2,03 MKeys und als meine Tocher zwischendurch ihr "Star Stable" gepielt hat, gings runter auf 1,4 Mkeys.
Die Werte der CPU Auslastung sind aus dem Windows Taskmanager. Nebenbei mit Core Temp einen Blick auf die Temps geworfen und die liegen bei 45-50°C. Unter Vollast gehen die Kerne locker auf 60°C...
Ich probiere heute abend mal mit -c 8 damit auch die virtuellen Cores voll genutzt werden.

Edit 19.30Uhr
Es bleibt dabei, auch wenn ich mit -c 8 starte habe ich ca 50% CPU Nutzung. Zum Spaß mal in VM Ware auf 8 Kerne gestellt und RAM auf über 4,4GB erhöht endete mit einem Fehler "Server didn't like us" oder so ähnlich.
Solange ich mit 50% Last die besagten ~2 Mkey/s habe soll es mir recht sein.

Die W5580 nehmen zusammen nur etwa 200W mehr auf als vorher, laut USV-Display.
Mit TDP 130W pro Stück bin ich also voll im Rahmen.

Ich sehe aber im Taskmanager wildes geflackere auf allen Kanälen.
Leider kann ich auch da nicht sehen, welcher ein echter und welcher ein HT-Kern ist, aber es sind alle immer mal wieder dran.
Der Scheduler ist also recht großzügig in der Verteilung...

Der leuchtet dabei bestimmt ziemlich hell.  


Das musst Du nicht festlegen (*), das macht der Scheduler. Ich glaube kein OS dieser Welt - also nicht einmal Windows - nimmt einen logischen Kern wenn ein physischer idle ist.
Ich glaube das macht sogar der Prozessor selbst. Die HT Kerne dienen ja nur dazu die Prozessoreinheiten besser auszulasten. Das macht keinen Sinn, wenn die eben idle sind.

Sprich: die CPU belegt erst die phys Kerne, dann erst die HTs.

Mit -c10 auf Deinem 8+8HT System lastest Du 8 phys + 2 HT Kerne aus, die restlichen 6HT sind halt für was sonst noch so anfällt.

Ist natürlich nur vereinfacht dargestellt. Klar kann sich dann mal ein Prozess einen phys Kern mit einem anderen teilen, je nachdem wie die prioritäten im Scheduler sind.


Rico

(*) Unter Linux und vermutlich woanders auch, kann man das tatsächlich beeinflussen, wenn man bei einem Prozess die CPU-affinity setzt. Aber ... pffff

-c 6 auf einem i7-3820 (4+4HT, 3,6GHz) bringt ca. 1,6MKeys/s bei etwa 75% CPU, neben mehreren Browsern, Outlook, usw. usf.
Man kann noch gut nebenher arbeiten, aber manchmal merkt man schon, das Firefox gern etwas mehr Zeit braucht um dieses oder jenes Script abzuarbeiten.

-c 10 auf einem Dual Xenon W5580 (je 4+4HT mit 3,2GHz) ergeben locker 2,4MKeys/s, bei ca. 65% CPU. Zusätzlich lauft neben der VMWare-LBC-Appliance eine VirtualBox mit 2x Win7Pro, wird aber nur sporadisch genutzt, dennoch kann ich denen nicht weniger als je zwei Kernen geben.
Da ich leider nicht festlegen kann, welchen der 4&4 echten bzw. 4&4 HT-Kerne die Appliance benutzt, hab ichs mit "10" probiert, das sollte im Schnitt 5-6 der 8 echten Kerne beschäftigen.