@Real 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  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 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.  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://bitcointalk.org/index.php?topic=1534300.msg15638727#msg15638727Aus heutiger Sicht war ich damals ebenso Dödel  Und wer weiß was wir in 1 Jahr sagen... Jetzt muss ich auch noch eine native Kiste Lunixen  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 |
|
|
|
|
There is a new version, which fixes the rogue "Death Kiss" events.
Please update as follows:
End your LBC client
Do a LBC -u (you should have a 1.031 or newer)
Start your LBC as usual
If you haven't updated yet (I see clients as old as 0.993), you are also missing out quite some keyrate.
There are reports of 1.6 Mkeys -> 2.1 Mkeys for CPU clients on VMs
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!  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 |
|
|
|
I just used Ubuntu 14.04.4 and installed fglrx.
Then the normal LBC install.
As for the GPU client: Can you write more about hardware you use and keyrate you get out of it? I'm adding some overview of speed for complete system configurations https://lbc.cryptoguru.org/man/admin#generator-speedRico |
|
|
|
|
New client 1.029 - upon restart your LBC should auto-update.
Also, most generators (except generic and sse41) have been updated to accept the -L option.
These too, should auto update.
Everyone who is GPU auth, should now be plug and play via --gpu.
The names of the generators are now in a more canonical form.
gen-hrdcore-skylake-linux64 (CPU)
gen-hrdcore-skylake+gpu-linux64 (CPU+GPU)
gen-hrdcore-avx2-linux64 (CPU)
gen-hrdcore-avx2+gpu-linux64 (CPU+GPU)
...etc. - you get the idea
So basically if you had a gen-hrdcore-avx2-linux64 generator up to now, with --gpu LBC would fetch the gen-hrdcore-avx2+gpu-linux64 counterpart and use that.
Even if you are CPU only, an update makes sense, as the -L will lower the generator startup overhead and should give you some more keys/s
Rico
|
|
|
|
-c 10 auf einem Dual Xenon W5580
Der leuchtet dabei bestimmt ziemlich hell. 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.
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 |
|
|
|
No I haven't. I have sworn to myself to pull this project off without any thinking at all.
Well let's see how the LBC evolves, thankyou. Of course my answer was sarcasto-ironic (which I often do to stimulate thinking in my discussion counterpart, but it almost never works). So full verbatim, my answer translates to this: There are currently P2PKH and P2SH addresses. We search only P2PKH, but we may extend our search to P2SH. This "If you find collisions BTC will die/will be worth nothing" is FUD. Bitcoin is an evolving system. And yes, LBC may put evolutionary pressure on the P2PKH part right now. If you look at https://github.com/bitcoin/bips/blob/master/README.mediawiki, you will see that there are other address formats already proposed. E.g. the now deferred BIP142 defining a P2WPKH format. Others may follow (I'd propose a true-512bit address format in a BIP myself, but am lacking the time atm. Also I prefer to interact with core devs as few as possible). In other words: There are so many levels between LBC finding collisions and BTC dying, one can safely assume these two events are not connected. Also I do not believe in the 2nd one. Rico |
|
|
|
but it also threw about 4 error lines about an unknown command "-L" but it went on asking for work so I let it be.
And that is something you shouldn't have done. When I asked for GPU beta testers, there were several prerequisites. Among them there were - If you have GPU authorization
- If you are bold
You had no GPUauth, but you were extremely bold, which means you can handle the consequences. At the moment I handle the consequences too, because I put my client on rectifying your 278+ Gkeys of invalid mess. If you really are interested to help out in the project and not making things worse, PM me. BTW - this (PM me) applies to everyone who feels he can't make it into top30, cannot fork out 0.1BTC and would like to explore the 3rd option How does that gpuauth=1 happen? ... - You get a gpuauth set to 1 by decree (i.e. for special services)
Rico |
|
|
|
I have feedback, that at least one user got his AMD GPU to run with LBC and the sse42+gpu generator. Which makes him the 1st, because I was not lucky so far. May he come forth and bath in glory (and answer questions/give support  ) The new generators have a new parameter -L you may see in the process table. In case you're wondering what that is: -L is loops
earlier versions of the generator started up, searched 16M keys, terminated, next startup, searched 16M keys...
so per 'o' one run.
-L <num> will now tell the generator to run <num> loops, i.e. <num> x 16M
this is especially important for GPU generators as they have a high startup cost, but also the CPU generators profit from this.
So if you e.g. see -L 25, this means, the generator will startup and run from a certain offset a search of 25 x 16M keys, which means only 1 startup cost for 400M keys instead of 25 startups. There is a drawback to this - unfortunately. If you want to end LBC by pressing "e", it will take longer. Namely at the end of the next ask-for-work-block. Ask for work... got blocks [426612921-426615288] (2483 Mkeys)
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooe <--- here we pressed "e"
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo (7.33 Mkeys/s)
Ask for work... got blocks [426626393-426628760] (2483 Mkeys)
<-- here LBC found out
END requested. (Ending this loop) Waiting for children to finish...
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo <--- here it ends
So max. time from "e" to end is twice the time given in -t
Also, you may see a -d 1 parameter in the process table with the GPU generators. -d <num> is simply the GPU device to use. If there are several GPUs on the system, this says which one to use. Default is 1
When does one use that? Again, as a LBC user, most of the time you do not need to take care of this, but in case you have a really big iron (say 32 physical CPUs and 4 GPUs), the LBC parameter is called "gdev" aka "GPU device". Howto - you open 4 windows/terminals: terminal1: ./LBC --gpu -c 8 -gdev 1 terminal2: ./LBC --gpu -c 8 -gdev 2 terminal3: ./LBC --gpu -c 8 -gdev 3 terminal4: ./LBC --gpu -c 8 -gdev 4 => you should have 4 LBCs running, each taming 8 generators (8 CPUs + 1 GPU) used if e.g. 8 CPUs are right to saturate 1 GPU Rico |
|
|
|
Anschließend habe ich meine Kiste mal das Wochenende durchlaufen lassen. Ich dachte die Auslastung würde nahe der 100% Marke sein, aber alle 4 Kerne liegen immer so zwischen 30-50%. Wenn nichts weiter gemacht wird, komme ich auf 2MKeys/s.
Das ist seltsam, denn falls die Maschine nur 4 Kerne hat, sollte die Auslastung tatsächlich bei 100% sein. Falls Du mit 4 Kernen auf 2 Mkeys/s kommst, dann werden die auch genutzt (Ich kenne keine CPU, die mit dem CPU generator in einer VM mit 4 Kernen auf 4Mkeys/s käme) Fazit: Entweder hat die Maschine mehr als 4 Kerne, oder die 30-50% werden von irgendeinem komischen Prozessmonitor angezeigt (denn selbst der Win-Taskmanager ist da korrekt). Rico |
|
|
|
it works root@Meh:~/LBCGPU# ./LBC --id XXXX --secret XXXX --gpu -t 1 -l 1 --no_update
Your maximum speed is 2232588 keys/s per CPU core.
Congrats! And ... what? ... better keyrate than me? I have to o.p.t.i.m.i.z.e. more  I'm getting more and more feedback about GPU clients finally working with some heart-lung machine work. I'll publish a new client soon which wraps up all the fixes, so GPU experience will be smooth. Rico |
|
|
|
Patiently waiting, hehe.
JFYI: The "hrd-core" binary below is a sse42+gpu version with a AMD GPU (R9-280X - I wonder why it's named Hainan, I thought they are Tahiti XTL) No idea why it's throwing that "Out of host memory" on me. The host is sitting there with 8GB unused memory... [root@localhost HRD-GPU]# time ./hrd-core -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 -d 1
OpenCL device chosen: Advanced Micro Devices, Inc. (Hainan)
256/16/1
256/1/1
Couldn't create a command queue: Out of host memory
As soon as I crack this, you will have your toy. edit: needless to say, it works on NVIDIA platforms without problems: ubuntu@ip-172-31-44-82:~/collider$ ./LBC --gpu -x
GPU authorized: yes
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 1308421 keys/s per CPU core.
Generator chosen: gen-hrdcore-sse42+gpu-linux64
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:c:priv:0000000000000000000000000000000000000000000000000000000000001001 + 0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:u:priv:0000000000000000000000000000000000000000000000000000000000001001 + 0x66
9d74ffdb31068ca2a1feb8e34830635c0647d714:c:priv:00000000000000000000000000000000000000000000000000000000000fa001 + 0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:u:priv:00000000000000000000000000000000000000000000000000000000000fa001 + 0xf8d
Ending test run.
1308421 keys/s per core - that's on a g2.xlarge (xeon v2 + K80) Also in the news: ftp://ftp.cryptoguru.org/LBC/generators/And we are sure the CPU is AVX2 capable?
My CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz You could try some hacking by using the 170220-3a3e82c4efe4a75e07c9c43a46206135.gen-hrdcore-avx2+gpu-linux64.bz2 generator, unpacking and renaming it to gen-hrdcore-gpu-linux64 and starting LBC with all options according to the instructions (as you did) and additionally --no_update (so it doesn't overwrite your generator). It might work, because it has been made on Haswell. Rico |
|
|
|
My CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Ok. It seems the GPU generator is working on Broadwell, Skylake and Kaby Lake. I'm working on compiles for the older architectures too and will post here when they're available. Rico |
|
|
|
So what? What does this matter? by the time you use quantum computers or asics and start finding tens and tens of collisions, bitcoin will worth 1 dll because people will move to other one more secure.
Have you ever thought about this?
No I haven't. I have sworn to myself to pull this project off without any thinking at all. Rico |
|
|
|
aaand I got blacklisted while using the beta build only on CPU.
How could you use the GPU client if you have no GPU auth? I had a look at the logs: Shortly after you said here "top30 here I come", your client started to churn invalid blocks to the server, so the server blacklisted you and the contributed 278,8 Gkeys got invalidated. As it should be - IMHO. Rico |
|
|
|
So, the beta is available to top30 and paying users? or for everyone with OpenCL installed?
OpenCL is necessary but not sufficient. The beta (and then the production client) is available to everyone, but it wikl work only for users who have a gpuauth: 1 attached to their id. How does that gpuauth=1 happen? - You are a top30 Gkeys contributor
- You fork out 0.1 BTC - which are distributed among all pool members (except me) who have a BTC address set
- You get a gpuauth set to 1 by decree (i.e. for special services)
Rico |
|
|
|
When the International Quantum Computing Society inaugurates it's Cryptocurrency Hacker of the Year award in 2025, will it be called the Rico in honor of the pioneer in collision computing?
I don't know. Quantum computing is only 4th on my TODO list. 1. Full-GPU client 2. FPGA implementation 3. ASIC 4. Quantum Computing Rico |
|
|
|
after following your instruction 1st run Illegal instruction (core dumped)
And we are sure the CPU is AVX2 capable? Rico |
|
|
|
Ok - Kurzfassung der englischen Version Wenn Ihr "GPU authorized" seid, eine AVX-fähige CPU habt, eine korrekte OpenCL installation habt, LBC nicht in einer VM läuft und ihr den zugehörigen Mut aufbringt: kopiert euch eueren LBC ordner in eine Kopie für eure Experimente. Z.B. $ cp -a collider gcollider
Im GPU-ordner löscht ihr bench.pst, LBC und eure gen-hrdcore-avx2-linux64 und eine eventuell vorhandene diagnostics-OpenCL.txt und holt euch den beta-LBC client $ cd gcollider
$ rm -f bench.pst LBC gen-hrdcore-avx2-linux64 diagnostics-OpenCL.txt
$ wget https://lbc.cryptoguru.org/downloads/beta/LBC
$ chmod a+x LBC
Ok, Stunde der Wahrheit. Beim ersten Aufruf solltet ihr das hier sehen: $ ./LBC --gpu -t 1 -l 0
OpenCL diagnostics written.
GPU authorized: yes
OpenCL program written. LBC beendet sich und in eurem Ordner solltet ihr 2 neue dateien sehen ( diagnostics-OpenCL.txt und hash160_deparsed.cl) beide nicht löschen. beim 2ten Aufruf (und allen folgenden), sollte es losgehen: $ ./LBC --gpu -t 1 -l 0
GPU authorized: yes
Best generator chosen: gen-hrdcore-gpu-linux64
New generator found. (DL-size: 0.72MB)
Benchmark info not found - benchmarking... done.
Your maximum speed is 2098648 keys/s per CPU core.
Ask for work... got blocks [416958585-416959096] (536 Mkeys)
oooooooooooooooooooooooooooooooo (8.06 Mkeys/s)
In der Theorie. Wenn ihr dann das -l 0 entfernt und die Zeit hochsetzt sollte alles so laufen wie gewohnt - nur schneller. $ ./LBC --gpu -t 5
GPU authorized: yes
Best generator chosen: gen-hrdcore-gpu-linux64
Ask for work... got blocks [419776761-419779192] (2550 Mkeys)
Nette Zahlen - hm?
Auch neu: Benutzerhandbuch unter https://lbc.cryptoguru.org/man/user erweitert mit Themen zu Id, security, BTC addresse setzen, GPU und defaults-datei (lbc.json). Rico |
|
|
|
|
Show Posts
