Läuft  real-duke@C1-Ubuntu:~/gcollider$ ./LBC --gpu
...
oooooooooooooooooooo - snip - ooooooooooooooooooo (6.61 Mkeys/s) Danke rico, die fehlenden Pakete waren Schuld Super.  Eine Anmerkung zum "--gpu": Auch das kann man in die lbc.json schreiben: $ cat lbc.json
{
"cpus": 4,
"gpu": 1,
...
Dann kann man sich auch das auf der Kommandozeile sparen. Und es wäre gut, wenn Du etwas zur Hardware (welche CPU, welche GPU) schreiben könntest, damit ich die 6.6 Mkeys/s entsprechend einordnen kann. Rico |
|
|
|
Habe mir ein Dualboot gebaut mit Windows 10 und Ubuntu 16.04. LTS Leider klappt der Aufruf ./LBC --gpu bei mir nicht nvidia Treiber ist installiert, nach der Info mit OpenCL 1.2 aber irgendwo klemmts! Kann jemand helfen? 1.2 functions, they might be nonfunctional and crash.
Do you want to prefer the OpenCL 1.1 API over the 1.2 API where possible?
Prefer OpenCL 1.1 over 1.2 functions (y/n)? [y] y
Nope. Hier "n" antworten. Du willst openCL 1.2 x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"1.01\" -DXS_VERSION=\"1.01\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.22/CORE" -DPREFER_1_1=1 OpenCL.c
OpenCL.xs:40:25: fatal error: CL/opencl.h: Datei oder Verzeichnis nicht gefunden
ok, ich gehe davon aus, gcc und make sind installiert. Fehlen offensichtlich noch die OpenCL header Dateien: UNter Ubuntu vermutlich das Paket opencl-headers http://packages.ubuntu.com/search?keywords=opencl-headersUnter Ubuntu auf den AWS maschinen habe ich immer folgende Pakete installiert: sudo apt-get install gcc make tmux libssl-dev xdelta3 nvidia-367 nvidia-cuda-toolkit Rico |
|
|
|
It only happens on the cpan install of JSON.
I always manually run cpan install JSON prior to running LBC for the first time.
I'll try to improve that situation. This "return pressing" should work though. Then after JSON installs I run the LBC client and everything except xdelta3 will install.
I then install xdelta3 using apt-get.
LBC cannot install distribution packages, because the way how this is done varies between distributions and also their package names (and some distributions do not even have xdelta3). So this is something that has to be done always manually, but prior to calling LBC. When LBC is called, "make, gcc, openssl-devel, libgmp-devel" must be installed, else some Perl package installations will fail. openssl-devel may be called libssl-dev on some distributions. Rico |
|
|
|
|
Only the server providing the FTP services will be unavailable for 20 minutes, LBC server will operate without interruption.
Rico
|
|
|
|
|
LBC Server wird ohne Unterbrechung weiterarbeiten. Lediglich der Server der die FTP Services (Update) bereitstellt, wird für ca. 20 Minuten nicht erreichbar sein.
Rico
|
|
|
|
Kurz nachgefragt, muß es Ubuntu 14.x sein oder gehts auch mit 16.x ? natürlich geht es mit Ver. 16.x Mein Tipp: installiere doch KUBUNTU - da hast wenig bunte schnick-schnak die Du sowieso nicht brauchst. Ich bin mit AMD bei 16.04 und 16.10 auf die Schnauze geflogen, mit 14.04 geht es angeblich. Das muss ich noch probieren. Mit Nvidia Grakas scheint es ziemlich egal zu sein welche Version man nimmt. Rico |
|
|
|
It would say that "module not found, installing it", and nothing would happen, I waited 15 min,
Yeah, it's necessary to hold the "Return"-key for a while (like 5 seconds), which auto-answers some "Shall I install xyz?" CPAN questions that unfortunately are not seen on the screen. It may be a little bit counter-intuitive. I'll see if I can fix this nicely. Rico |
|
|
|
Mein Post bezog sich auf den MinerVonNaka  Ist Irgendetwas in meinem Post, das andeutet, ich hätte dies nicht bemerkt? Ich darf doch trotzdem an der Diskussion teilnehmen - oder? Die odt/doc-Geschichte geht noch einigermaßen, aber speziell ods/xls ist eine Katastrophe, wenn es über Zahlen in Feldern rausgeht.
Das ganze rumgemakro ist nicht kompatibel, und dann wird es schon eng.
Da stimme ich zu. Klar gibt es hier die Windows-Ökosystemtümpel, dort wieder die Linux-Ökosystemtümpel. Oftmals mit einer sehr geringen Schnittmenge. Für mich geht die Sache ja bei den Entwicklungsumgebungen los. Will ich einen C-compiler, dann installiere ich diesen unter Linux einfach. Unter Windows habe ich erstmal irgendeine Microsoft Visual C trial Version für 30 Tage (die lange vorbei sind) und sonst weiß ich erstmal nicht, wie ich überhaupt an einen Compiler kostenlos und legal und für immer komme. Die native Windows Version von LBC hatten wir ja auch nur, weil Papa Google so nett war und dem Go-Compiler eine cross-compile Funktion spendiert hat (man konnte einfach unter Linux-Go Windows als target-Plattform angeben und fertig war das .exe) Ein Full-Time-Linux da drauf zu packen ist also beinah unmöglich, und eine USB-Installaton ist weit abseits meines Horizonts.
Linux ist nunmal nicht nur ein bissel anders als Windows, sondern eine ganz andere Welt, und demzufolge ist die Lernkurve schon steinig und nicht waagerecht.
Da ich Linux seit 1994 mache, sieht es für mich in der anderen Richtung genauso aus. Mach doch einfach Linux drauf, und lass das bischen Windows was da laufen muss in einer VM knödeln. Ich habe unter Windows schon Probleme den File Explorer zu bedienen.  Geschweige denn mich in der Filesystem-Struktur auszukennen. Wer sich das ausgedacht hat, dem muss man wohl ins Hirn gesch* haben. Und ich habe die große Befürchtung wenn ich mich längere Zeit damit befasse, sch* jemand in mein Hirn. Die meisten der Leute, die eine propere GraKa haben, wollen damit zocken, und das ist pur Windows. Linux kann das nicht.
Die meisten Leute die ich kenne, machen mit GPUs numerische Simulationen, Neuronale Netze, Deep Learning (ScorpioKing würde sagen DeppLearning) und so ganz pur ist das nicht: https://www.heise.de/newsticker/meldung/Agenten-Game-Hitman-fuer-Linux-verfuegbar-3630929.htmlhttps://www.heise.de/ct/artikel/Hier-gibt-es-Linux-Spiele-3619555.htmlhttps://bitcointalk.org/index.php?topic=1573035.msg17950209#msg1795020923. Februar Rico |
|
|
|
@DrTouchUrSon Nice Id. If I may suggest - crank up the -t parameter. You seem to run quite some capacity with -t 1 As stated in the docs, this does cost you some keyrate. Try -t 10 and see what happens. @ylpkm It would give me "JSON not found". looking at the source, the complete printout is print "$module not found - installing it.\n"; then followed by a qx{cpan force install $module};LBC finds out what's missing and does install by itself. Rico |
|
|
|
Had some issues getting it running on 14.xx ubuntu, and this allowed it to run, if anyone had some trouble try this.
So of course ensure you have these installed:
use: sudo apt install "the name of the items below without quotations"
perl (5.14 or newer) - probably preinstalled
bzip2 - most probably preinstalled
xdelta3 - look for a "xdelta3"-named package.
libgmp-dev -The GNU Multiple Precision Arithmetic Library
gcc
----------------------------
Then in terminal use:
cpan install File::Spec
cpan install JSON (dont remember if this one actually installed)
cpan install LWP::UserAgent
cpan install Net::SSLeay
cpan install LWP::Protocol::https
cpan install Parallel::ForkManager
cpan install Term::ReadKey
cpan install Win32::SystemInfo (dont know if this one and the ones below it are necessary but i did it anyway)
cpan install Data::Dumper
cpan install Digest::MD5
cpan install File::Temp
cpan install Math::BigFloat
cpan install Getopt::Long
-------------------------------------
Then for opencl files:
sudo apt get install ocl-icd-opencl-dev
cpan install OpenCL
----------------------------
then you should be able to run lbc by using:
perl lbc -h
or any other parameter you want after the lbc like -x -gpu -id -s -a
(Dev I had a question, How much merit needs to be brought to the pool to have gpu enabled? If this guide merits enough if you could pm me, id like to see what the hashrate of my gpu is. Thanks for your time.)
May I ask why you just didn't $ sudo apt install perl bzip2 xdelta3 libgmp-dev libssl-dev gcc make
$ wget ftp://ftp.cryptoguru.org/LBC/client/LBC
$ chmod a+x LBC
$ ./LBC -h
because ./LBC -h should do all the CPAN stuff already and for this to work, you definitely need the apt install before that. You do not need Win32::Systeminfo on Linux - obviously. Quite some of the mentioned Perl modules are belonging to Perl core i.e. are installed as soon as Perl is installed. I think SlarkBoy has a very similar configuration to yours. You can see what performance to expect a couple threads up https://bitcointalk.org/index.php?topic=1573035.msg17969538#msg17969538Rico |
|
|
|
|
Tschechien 10ct/KWh ohne großes Trara. 7.4ct/KWh mit großem Trara.
Sind zwar nur wenige deutsche Notare dort, aber Zivilisation gibt's da
sonst auch.
Rico
|
|
|
|
Es gibt nunmal gewisse Programme, die nur da gehen
So wie momentan GPU-LBC eben nur unter Linux geht. Hast du schon mal im großen Umfang OpenOffice/LibreOffice-Dateien verschickt? Da kann ja keiner mit üm.
.odt oder .doc (.ods, .xls) geht doch. Das kann Windows besser, bei der Usability sind die nunmal vorne.
LBC ist momentan nichts für Klickibunti-User. Ich bin mir auch nicht sicher, ob ich die Software je in die Ecke drücken möchte. Natürlich würde ich gerne die Einrichtung so einfach wie möglich haben, aber andererseits will ich auch keine User, die meinen mit der Bereitstellung/Betrieb von Hardware und 2-3 Klicks sei der Gipfel der eigenen Kompetenz erreicht. Sprich, ich werfe den Usern keine Stöcke zwischen die Beine, dokumentiere und programmiere so gut ich kann um den Einstieg nicht zu hart zu machen (will ja, dass Leute mitmachen). Wer aber glaubt, er bekäme Alles auf dem Silberteller, für den ist der LBC sicher nicht das Richtige. Ich habe mit dem Bitcoin-Mining in großem Stil aufgehört, als mir einfach zuwider wurde, meine Hardware von irgendeinem Chinesen einzukaufen und dann eben nur noch Betrieb sicherzustellen. Da fühlt man sich doch wie ein 3.-Land Mohr der nur um irgendeine magische Technik herumtanzt, aber keine Chance hat selbst sowas herzustellen. Nun ist es heutzutage wohl illusorisch sich seine eigenen Miner zu bauen, also mache ich was anderes, was der Chinese noch nicht kann. Im englischen Thread kam einer an mit in etwa den Worten: "Wenn Du ein Windows-Binary mit Nvidia Unterstützung baust, wäre ich bereit mit meiner 1080 zu testen." Da antworte ich gar nicht darauf, weil der Mensch ist so weit weg von einem "sich-damit-auseinandersetzen", dass da wohl überhaupt keine gemeinsame Diskussionsbasis vorhanden ist. Wir hatten ja schon einmal einen nativen Windows-Client und theoretisch sollte das ja wieder machbar sein, aber da bräuchte es die Hilfe von Leuten, die unter Windows in C programmieren können und nicht nur auf .msi Pakete klicken können. Rico |
|
|
|
Die Probleme gehen bei mir aber jetzt erst los: Jetzt muß ich mit nativem Linux ran...hast Du dafür evtl ein "vorbereitetes" Image, das man von USB installieren kann? Mit der Appliance für die VM hast Du uns Windows usern bereits gut geholfen Da ich immer noch mit meiner AMD R9 280X kämpfe, werde ich demnächst versuchen ein Ubuntu 14.04 mit fglrx auf einem USB stick zu installieren. Wenn das klappt, könnte ich die Binärdatei des USB sticks selbst irgendwo hinterlegen. Dann müsste man nämlich nicht von USB installieren, sondern kann direkt vom USB stick booten ohne die Installation auf der Festplatte anfassen zu müssen. Die Zeit jedoch ... die Zeit... Rico |
|
|
|
-snip-
ECC weiß ich noch nicht.
-snip-
ECC ist durch die "Modulo Operation" (endl. Körper) nicht umkehrbar, das heißt aber nicht das man nicht zu einem gegebenen öffentlichen Schlüssel einen privaten Schlüssel algorithmisch ermitteln kann (Shor's). Die Modulo-Operation kommt aber - nach allem was ich in der libsecp256k1 gesehen habe pro field operation höchstens einmal zum Einsatz (Magnitude). Daher: weiß ich nicht. Könnte evtl. was zu machen sein. Wenn der öffentliche Schlüssel bekannt ist, ist der Private eben nur noch durch 128bit geschützt - ist aber eine andere Aufgabenstellung als ich mir vorgenommen habe. Rico |
|
|
|
Wenn diese unumkehrbar ist, gibt es auch keinen Weg (nichtmal den einzigen über eine Kollision) auf die Ausgangsinformation zu kommen.
also willst du keinen privaten schlüssel zu einer adresse finden? was willst du dann? Doch, will ich, aber eben nicht über eine Invertierung der Hash Algorithmen, sondern durch mehr oder minder brute force (= Ausprobieren). Weil ich ja eine Kollision für den gesamten Prozess finden will also privkey -> ECC -> SHA256 -> RIPEMD160 und nicht nur für eine hash Funktion. Nach reiflicher Überlegung ist das der günstigere Weg. Die Alternative wäre RMD160 analytisch knacken UND SHA256 analytisch knacken UND ECC analytisch knacken. Das traue ich mir erstmal nicht zu. Eine weitere gewollte Eigenschaft ist ja, dass Hash-Algorithmen nicht invertierbar sein sollen. Und nach ausgiebigem Studium von SHA256 und RIPEMD160, bin ich auch zu dem Schluss gekommen, dass das für diese zutrifft. ECC weiß ich noch nicht. Nochmal: die Gleichverteilung der bekannten Hash-Algorithmen wurde exzessiv untersucht und für gut befunden.
der beweis ist schon erbracht? es wurden ausreichend kollisionen gefunden und sie verteilen sich genügend gestreut im suchraum? Ja, der Beweis wurde schon erbracht. Nennt sich chi-square Test und ist wesentlich "ausreichender" als ausreichend Kollisionen zu haben. Rico |
|
|
|
Es gibt kein "schieben in bestimmte Bereiche des Suchraums". Diese Kryptoanalyse haben SHA256 und RIPEMD160 lange hinter sich. Sie verteilen uniform - das macht sie ja zu guten Hash Algorithmen. Genau weil sie jedoch uniform verteilen, kann man auch von einem Abbild aller Privkey -> Adresse Paare in den ersten 160bit "des Suchraums" ausgehen. RIPEMD160 sei Dank.
wie führst du den beweis ohne je eine kollision gefunden zu haben? Wenn Du da drin etwas findest, was nicht stimmt, nehme ich gerne Korrekturvorschläge entgegen. Ob der Pool eine Kollision gefunden hat oder nicht, ist offen (= strittig): https://lbc.cryptoguru.org/trophiesDenn genauso gut kann ich anzweifeln, dass f6cc30532dba44efe592733887f4f74c589c9602 und 378e8af588e6433032d0f5fb548431408c4bcb3c originär tatsächlich mit den Privkeys erzeugt wurden, die der Pool gefunden hat. also auch EDIT: der algorithmus hat aber einen "charakter" den er in die ergebnisse "einfliessen" lässt.
es ist eine verdichtung von informationen welche nicht umkehrbar ist. der einzige weg auf die ausgangsinformationen zu kommen ist nach kollisionen in einem riessigen suchraum zu suchen. kennt man den "charakter" des algorithmus kann man den suchraum eingrenzen da man weiss dass die ergebnisse in bestimmten bereichen des suchraums bevorzugt auftreten.
Also zu "charakter" eines Algorithmus kann ich Nichts sagen, das ist ein wenig zu esoterisch und somit nicht mein Fachgebiet. Was ich sagen kann ist, dass es keine Verdichtung von Information gibt. Es gibt eine Reduktion oder eine Transformation von Information. Erstere ist unumkehrbar, also meinst Du vermutlich das. Wenn diese unumkehrbar ist, gibt es auch keinen Weg (nichtmal den einzigen über eine Kollision) auf die Ausgangsinformation zu kommen. Nochmal: die Gleichverteilung der bekannten Hash-Algorithmen wurde exzessiv untersucht und für gut befunden. Auch den sog. Avalanche-Effekt weisen diese auf. (1bit Änderung am Input resultiert im Schnitt in der Änderung von 50% der bits beim Output). Arulbero hat im englischen Thread sogar noch seine eigenhändig vorgenommenen statistischen Untersuchungen zu diesem Thema gepostet. EDIT2: (Du machst mir Spaß) Quantencomputer sind das Vorzeigeprodukt für die Behauptung eine Geschwindigkeitsverdoppelung reduziere den Suchraum um 1bit. Ein N-bit Algorithmus auf einem N-bit Quantencomputer ausgeführt hat potentiell eine O(1) Laufzeit. Jedes Qbit verdoppelt die effektive Geschwindigkeit eines Quantencomputers. Ein 256qbit Quantencomputer könnte folglich - mit dem richtigen Algorithmus - einen validen (merke: nicht den originalen) SHA256 Input zu einem gegebenen Output instantan finden. Das ist auch kein "überproportionales Parallelisieren". Die Rechengeschwindigkeit wächst einfach nur genauso exponentiell wie der Suchraum (N Qubits:bits), das ist geradezu harmonisch proportional. Rico |
|
|
|
nimm es mir nicht übel, aber du vergisst den hash algorithmus. um die kollision zu finden darf man nicht davon ausgehen, dass der suchraum linear mit abziehen von bits verringert wird. der algorithmus "schiebt" die ergebnisse in bestimmte bereiche des suchraums. deshalb sprach mezzo von kryptoanalyse. man versucht diese gewichteten bereiche zu finden.
Nimm Du es mir bitte nicht übel, aber nach knapp 8 Monaten Entwicklung, wobei ich meine eigene SHA256 Implementierung sowohl auf CPU wie auch auf GPU vorgenommen habe (genauer gesagt zwei Implementierungen, jeweils eine für uncompressed und compressed public keys) und eine eigene RIPEMD160 Implementierung, speziell auf den SHA256 output (hier als Input) zugeschnitten - wiederum für CPU und GPU... nach ausführlichen Benchmarks schnellster Code weltweit (von dem was öffentlich zugänglich ist)... bin ich mir wirklich nicht sicher, was ich von der Aussage "Du vergisst den Hash Algorithmus" halten soll. Nicht nur vergesse ich diesen nicht, ich kenne ihn in- und auswendig. (Und kann deswegen auch sagen, dass die RIPEMD160 Autoren ziemlich einfallslos von SHA256 abgekupfert haben)
Es gibt kein "schieben in bestimmte Bereiche des Suchraums". Diese Kryptoanalyse haben SHA256 und RIPEMD160 lange hinter sich. Sie verteilen uniform - das macht sie ja zu guten Hash Algorithmen. Genau weil sie jedoch uniform verteilen, kann man auch von einem Abbild aller Privkey -> Adresse Paare in den ersten 160bit "des Suchraums" ausgehen. RIPEMD160 sei Dank.
Ich gebe zu, ich bin gemein. Ich stelle Fragen, zu denen ich lange die Antwort kenne. In diesem Fall eben Äquivalenz von Suchgeschwindigkeit und effektiver Suchraum (bezogen auf eine Zeitkonstante). Sprich: Brauche ich mit Prozess A für 8bit 256 Jahre und finde einen Prozess B, der doppelt so schnell ist wie A, dann braucht Prozess B eben 128 Jahre. Was effektiv die Zeit ist, die A für 7bit bräuchte. Klar? Natürlich kann man den Suchraum auch effektiv verkleinern indem man analytisch vorgeht und z.B. Symmetrien aufdeckt (pro Symmetrie hat man auch oft eine Reduktion von 1bit) - das bleibt ja weiterhin unbenommen. Und wer den englischen Thread verfolgt hat, weiß, dass gerade diese Analysen für ECC nochmals eine erhebliche Steigerung der Suchgeschwindigkeit nach sich ziehen werden. Rico |
|
|
|
Eine Verdoppelung der Suchgeschwindigkeit entspricht einer Verkleinerung des Suchraums um 1bit. woher hast du diese aussage? Durch die Fähigkeit auch ohne wolframalpha nachdenken zu können. Rico |
|
|
|
Der notwendige Suchraum umfasst doch sowieso nur 96 Bit und nicht 256 Bit.
Kannst Du das näher erläutern? Die Suchgeschwindigkeit ist aus Sicht der Cryptoanalyse nicht relevant. Interessant sind Methoden/Verfahren, die den Suchraum von 96 Bit z.B. auf 48 Bit verkleinern. Dort steckt tatsächlich Potential drin, was bei anderen Algorithmen bereits ausreichend oft nachgewiesen wurde.
Eine Verdoppelung der Suchgeschwindigkeit entspricht einer Verkleinerung des Suchraums um 1bit. So gesehen haben wir den Suchraum seit Projektbeginn nochmals um ca 8.5bit verkleinert. Gern geschehen. Rico |
|
|
|
|
Show Posts
