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

Kurzer Statusbericht:

• client wurde auf 0.993 upgedated, man kann nun eigene Id angeben, und auch mit einem Passwort absichern (Vorbereitung für Auszahlungen)
• Die "echte" Key-Rate wird nach jeder Runde im Client angezeigt; Konfigurationsdatei für default, damit man nicht immer alles auf der Kommandozeile eingeben muss.
• no_update flag - für Leute, denen nicht wohl dabei ist wenn LBC sich und andere Files auto-updated.
• Wenn jemand mehrere Ids hatte, kann ich das in der DB konsolidieren.
• Kleiner Speedup wiederum bei AVX2 Generator, mit gcc 6.3.0 statt 5.4.0 compiliert
• Bugfix: Der Test findet wieder korrekterweise 4 Treffer
• Manual (Benutzerhandbuch) erweitert
• Gegenwärtige Pool Performance ~ 50 Mkeys/s

Momentan ist der Pool wirklich noch ein klitzekleines Projektchen. Zwischen 9 und 11 Leuten - mich eingeschlossen - sind dauerhaft aktiv, wobei derzeit einer - nicht ich - 60% der Pool-Performance stellt. Nicht auszudenken, wenn da mal 100-200 Leutchen eindreschen würden...  


Rico

ich sehe gerade oben: i5-2300 @ 2.8GHz, da kommen die 397 000 wohl hin.

1073 Mkeys in 10 oder 15 minuten? Bei 3 CPUs und 10 minuten bist Du bei 596111 keys/s, das wäre sehr gut. Bei 15 Minuten  bist Du pro Kern bei 397407 keys/s - immer noch respektabel. Welche CPU hast Du denn? Die Angabe "Your maximum speed ..." beim Benchmark ist ausschlaggebend.

BTW: ich habe gerade einen optimierten AVX2 generator auf den FTP server geschoben. Da sind ca. 20% mehr Performance drin.
Also wer so eine CPU hat, möchte vielleicht LBC restarten (führt dann ein auto-Update durch).

-> https://lbc.cryptoguru.org/man/admin#generator-speed

sind noch nicht alle up-to-date, weil mir noch zu einigen das Feedback fehlt (Intel i7-4510U @ 3.1GHz sicher mindestens 460 000 mit dem neuen Generator laut Feedback und Screenshot ~535 000)


Rico

meiner läuft jetzt wieder mit 1073 mkeys
bin mal gespannt wann und ob ich etwas finde.

"Ich" nicht, letzter Fund war am 16.1. - zwischen den Funden dauert das schon eine Weile, auf den letzten haben wir 3 Monate gewartet.
Der Pool hat momentan über 40MKeys/s und wir nähern uns den 48bit (von 160) abgeklapperten Suchraums.

Bei der Geschwindigkeit können wir im Schnitt in 33 Tagen #49 der Puzzle Transaction gefunden haben.

arulbero hat im englischen Thread einen Interessanten Vorschlag gemacht, der die public key Generierung fast zum Nulltarif verdoppeln könnte. Ich sehe mir das bei Gelegenheit an.


Rico

Guten Morgen,
habt ihr ein schönes wochenende gehabt?

Hast du nochmal etwas gefunden?

lg
thomas

Sow wie ich das sehe, hast Du 3 CPUs (VMware default auf einem 4 CPU system - also ok) und 8 GB RAM (mehr als genug, würden 3GB auch reichen).

Bist Du sicher, dass Du



eingibst? Wenn ja, was sagt er dann?

Rico

Guten morgen oder guten tag,
nu mal so am rande. ich hasse die nachtschicht.
so ich habe jetzt mal die cpu ausgelesen. er läuft immer
nur noch auf einem pott

Nachtwächter? :-)

Auf jeden Fall folgendes testen:

1) Hardware

Wieviele Kerne hat die Maschine (real, logisch) oder halt einfach welche CPU, dann sehe ich nach
Wieviel Speicher hat die Maschine in GB

2) VM

Wieviele Kerne sind der VM zugewiesen (steht in den Vmplayer Parametern)
Wieviel Speicher ist der VM zugewiesen
In der VM unter linux entsprechend
> cat /proc/cpuinfo
> free

eingeben, Ergebnis mitteilen (beantwortet die Frage was sieht das OS in der VM real).

Naja und dann halt den Screenshot wie du LBC startest (kommandozeilenparameter) und was der so von sich gibt. Das wird schon.


Rico

also ich kann immer nur noch einen cpu benutzen. leider muss ich jetzt zur arbeit.
aber sobald ich morgen mittag wach bin mache ich mal bilder von dem
auslesen meiner daten über dieses programm.
wünsche eine angenehme nacht.
lg

ich finde sowas super,
mir macht es so viel spass sich in die materie einzuarbeiten.
und für deine hilfe bin ich die auch sehr dankbar.
bin mal gespannt wann ich etwas finde und vor allem ob ich das dann auch entziffert bekomme
lg

Thread studieren hilft (hatten wir vor ~4 Tagen, Antwort ist nein)
Genau genommen weiß ich ja nicht einmal wer "Du" bist, so lange Du mir nicht sagst von welcher IP Deine Clients zugreifen, bzw. welche Id Du hast.

Aber  da jeder Finder stolz wie Oskar ist, kann/soll er mir natürlich von seinem Fund mitteilen, damit ich das auf der Trophies page verewigen kann. Gerne auch mit Id des Finders wenn er das will.

So weit ich das verstanden habe, hat "der Pool" auch schon wesentlich mehr "gefunden", als so offiziell angezeigt wird, weil die Leute mit der manuellen Eingabe von Blöcken irgendwelche Suchräume abgrasen, bei denen sie vermutlich selbst wissen was drauf ist und das entsprechend verifizieren.

Ja, theoretisch könnte ich mir die Logs ansehen und diese Blöcke auch durchforsten, aber praktisch habe ich keine Chance da hinterherzukommen. 1:many Relation...
Meistens sind das eh irgendwelche kleinen Testbeträge, die jemand drauf hat um zu testen ob der LBC überhaupt funktioniert.  

edit: So habe ich z.B. den letzten Bug gefunden, indem ich von einem user darauf hingewiesen wurde, dass er
https://blockchain.info/address/17AxE7odq6A8sp1jMZFtagD745M126yueh
nicht finden konnte, obwohl er den korrekten Suchraum eingab.

Nachdem ich den Bug korrigiert hatte, hat ers heute wohl wieder abgezogen. Es war wohl als Weihnachtsgeschenk gedacht, aber halt im falschen Suchraum deponiert.



Rico

Guten morgen,
ja sehr cool. Kannst du meine Treffer (wenn ich mal einen haben sollte) auch sehen?
lg
und einen guten start in die woche

LOL - Der Pool hat wieder etwas gefunden.

0.0001 BTC - vermutlich irgendeine Bounty, oder Test oder sowas.
Transaktion ist vom 2016-04-21

Stay tuned.

https://blockchain.info/address/164kvbiwxEq3wfeUWLSdxBuQeAyMhyFe4N
https://lbc.cryptoguru.org/trophies

Rico

Und die Absicherung gegen Side-Channel Angriffe. Ja, wichtiges Thema, ist mir auch erst im Verlauf so richtig bewusst geworden.

Ändert aber nichts an der Tatsache, dass ich für die Generierung die Performance anderswo brauche und wenn das im Rahmen der Standard-secp256k1 Bibliothek nicht möglich ist, dann muss ich eben selbst ran. Und dass die libsecp256k1 nicht der Weisheit letzter Schluss ist, wird mir auch immer klarer.

Es macht ja auch Spaß, schliesslich kommt man so zu Ergebnissen, die es anderswo nicht gibt. 


Rico

(*) und die Absicherung gegen Side-Channel Angriffe

Du meinst Kollisionen? Erstmal finden wir eine hash160 Kollision und dann sehen wir weiter.
Oder wenn ich irgendwann keinen Bock mehr habe, dann gebe ich den Code frei, aber noch habe ich Bock. 

Es ist übrigends nicht so einfach das mal auf andere Cryptos zu übertragen. So ein Projekt muss den Generierungs-Pfad (Privatschlüssel -> Adresse) durchlaufen und die sind meist nicht optimiert. Gerade habe ich mit gmaxwell ein "freundschaftliches" Gespräch gehabt und festgestellt, dass z.B. für die Core-Entwickler eigentlich nur die Geschwindigkeit der pubkey Validierung von Interesse ist.

Es gibt beim Bitcoin in dieser Hinsicht noch mehrere Kathedralen zu bauen, also werde ich da erst einmal mithelfen, bevor ich überhaupt an andere Cryptos denke.


Rico

huhu, wünsche euch einen schönen sonntag.

könnten wir nicht auch versuchen moneros oder andere zu finden?
lg
thomas

Er braucht pro Prozess ca 550 MB RAM. Wenn er feststellt, dass die Anzahl der gewünschten Prozesse mehr Speicher benötigen würde als vorhanden ist, drosselt er runter. Ggf. der VM mehr Speicher geben. Ggf. schauen was


sagen.

Aber Du hast doch geschrieben, dass bei Dir die CPU Auslastung irgendwo bei 80% liegt - oder? Also muss das doch schon mal funktioniert haben.


Rico

Komisch ist das ich nur mit einem core arbeiten kann.
Selbst wenn ich 3 starten möchte sagt er 1 core use

Ja, ist es.  

Misslungener Bildschirmschoner. SHIFT drücken reicht auch schon und man wurstelt nicht in die Bildschirmausgabe.
Kannst aber lassen. Er arbeitet auch so weiter. Ich drücke ab und zu schift um zu sehen ob noch alles in Ordnung ist.

So einmal die Woche.  

Wenn Du den PC ausschaltest/neu startest/er abstürzt etc. ...
=> Deswegen wird die Datei "FOUND.txt" angelegt. Die ist natürlich auch über Neustarts/Abstürze etc. persistent.
D.h. Ja, er merkt sich schon gefundene Adressen.

Er fängt nicht von vorne an, sondern fragt beim Server einfach die aktuelle Arbeit an und bekommt was zugewiesen.
Der Server kümmert sich darum, dass nichts (unnötig) doppelt gemacht wird.

Rico