becoin - as always... It's not the "project" that needs economic considerations, but anyone who wants to get in the top30 for getting a GPU client and not forking out 0.1 BTC (or 0.5 BTC if he's becoin).

Right now, you can still get in the top30 for around $11 (~28 hours) with a m4.x16 AWS spot instance. To achieve the same with the p2.xlarge would cost you $33.

Apropos churning:

I made a workaround in the LBC client to stop the generator when it is churning bad hashes:

(Searched the thread and site couldn't find a previous example of this)

edit: it ran for a while then said " so you want to play hard, sucker? yes, ok .. bye" and died. man i love this server hahaha.error must be on my end i think ;p maybe an updateedit 2: i fixed it, apparently the client self destructed (due to my "death wish"?) so i just remade the whole thing, im back colliding!

Your client probably updated already to 1.015 - this is the 1st version to choose a GPU-assisted generator if all the prerequisites for it are met:

You put the --gpu flag on command line (if you don't it will still use the regular CPU generator)

You are in the top30 or have the GPU-eligible flag set

You have an AVX2 capable CPU

Your OpenCL environment is installed

There are still some things missing (like the OpenCL source code - that's why you see that error). After working almost 16 hours straight yesterday, I had to stop at some point.I intend to have it all working this weekend.

Good news for the client is, the race condition is gone and it can now handle multiple GPUs in a system.

Bad news for those using AMD GPUs is: The client will only look out for Nvidia hardware. There is no technical reason for this. It's just that nobody with AMD hardware sent me a diagnostics file and I will not enable AMD support if untested. I have an AMD GPU machine here myself, but it's windows only and I have to install Linux on it 1st. After I have done and tested that, I will enable it.

@CjMapope

Quote

edit: it ran for a while then said " so you want to play hard, sucker? yes, ok .. bye" and died. man i love this server hahaha.error must be on my end i think ;p maybe an update

What you observed is the 2nd line of defense the client has in place to cope with code tampering. Normally it computes a checksum of its source code and sends that to the server which has a database entry which version has which checksum. If you tamper with the code, it will simply say so and block communication. Now if you dig deeper and change the code providing that checksum, you have tampered with the code and the client sends the "correct" checksum to the server. There is a 2nd mechanism in place to prevent that and that's what you have seen. Please do not change the code of the client - it's really not worth it.

@unknownhostname

Quote

whats the Key rate for a p2.16xlarge ?

I managed to get 22 Mkeys/s from a p2.8xlarge - for a while, after having worked hard to put the p2.8xlarge on life support. And it crashed eventually again. Really - these machines are utter shit. And it crashed eventually again. $2 per hour? Bah. And for the regions I have looked up, Amazon wants $144 per hour for the ps.16xlarge. Srsly? In a perfect world you should get 44 Mkeys/s from a p2.16xlarge.As I said, the best AWS machine for LBC is currently still the m4.16xlarge which gives you 18 Mkeys/s for $0.4 per hour.

Which were only hashed to compressed addresses. Plus it does not check 9 M addresses for each generated key(!).We're doing both uncompressed and compressed, so to be fair, when LBC will show 75Mkeys on this configuration, it will be technically as fast as oclvanitygen, but doing more work.

Our problem is still the ECC which happens on the CPU. Right now, we have a CPU/GPU hybrid. That is

The CPU computes 4096 uncompressed public keys and moves them to GPU

The GPU computes 4096 hash160 of this and 4096 hash160 of the compressed equivalents

The 8192 hashes are moved back to the CPU which performs a bloom filter search on them.

This process is done 4096 times before you see a 'o' on your screen. The bloom checking is negligible and the CPU could easily follow the GPU here.The ECC is the problem. Of the 7.5 seconds for the 16Mkeys on my computer, 6.2 seconds are ECC.

I'm working on it, and we will see again (tremendous) speedups in the future. Until then the best motivation to make it happen is basically

"Yay! We are faster! Cheers!" - after a 300% speedup (of Go generator, which was some 1000 times faster than wget/100x faster than vanitygen parsing"Yay! We are faster! Cheers!" - after a 1300% speedup (by using brainflayer)"Yay! We are faster! Cheers!" - after a 50% speedup by optimizing/rewriting the brainflayer code for almost 3 months."Yay! We are faster! Cheers!" - after a 250% speedup by using the GPU as hash160 coprocessor"Yay! We are faster! Cheers!" - after a 20% speedup by optimizing the CPU/GPU hybrid more

=> We are today about 150x faster than the 1st LBC generator in July 2016, My notebook alone delivers 25x the keyrate than the whole pool upon inception.=> We are on our way to a GPU generator only or something well balanced using 100% of the GPU (and efficiently)

So if we get ECC from 6.2s to - say - 1s, the configuration above will make around 90 Mkeys/sI'm quite confident, that based on arulberos work and research, we can move quite a bit towards this goal.Until then, what we've got is the best we've got.

Before i go nuts and try to reach top30, is there a guesstimate for how a GTX 750TI will perform with LBC ?

Will it make sense to try and enter top30, or to shell out 0.1 BTC ?

My current setup is a i7-4770, 16GB RAM and a Palit GTX 750TI.

At the moment this configuration will give you ~ 3 times the performance compared what you get now with the CPU-only generator.

My suggestion would be to shell out 0.01 BTC for some AWS code ($20 or more) and to throw some AWS compute instance on the "top30 problem".As of now, this is still possible. If 10 people do it, it may not.

Oh and because the question has come up: Once in top30 - always GPU-authorized=yes, the authorization will not go away should you fall out of the top30 again.

Before i go nuts and try to reach top30, is there a guesstimate for how a GTX 750TI will perform with LBC ?

Will it make sense to try and enter top30, or to shell out 0.1 BTC ?

My current setup is a i7-4770, 16GB RAM and a Palit GTX 750TI.

At the moment this configuration will give you ~ 3 times the performance compared what you get now with the CPU-only generator.

My suggestion would be to shell out 0.01 BTC for some AWS code ($20 or more) and to throw some AWS compute instance on the "top30 problem".As of now, this is still possible. If 10 people do it, it may not.

Oh and because the question has come up: Once in top30 - always GPU-authorized=yes, the authorization will not go away should you fall out of the top30 again.

Rico

Thanks for answering, but i'll stick to CPU-only for now. Not willing to spend any $ or BTC for less than 10x speed gain.

CPU-only performance is quite awesome, one core on i7-4770 does 720000 keys/second.

Thanks for answering, but i'll stick to CPU-only for now. Not willing to spend any $ or BTC for less than 10x speed gain.

CPU-only performance is quite awesome, one core on i7-4770 does 720000 keys/second.

I understand that, but you may want to reconsider (strategically). I will certainly not stop at 3x, but by the time I have a 10x client, the value of getting the perks of a top30 member may not be achievable below 0.1 BTC and 0.1 BTC may have a higher value than it has today...

What you are saying right now is: "I know you offer early adopters great benefits, but I prefer to wait."It's ok. Like not having bought BTC @ $2.

edit: it ran for a while then said " so you want to play hard, sucker? yes, ok .. bye" and died. man i love this server hahaha.error must be on my end i think ;p maybe an update

What you observed is the 2nd line of defense the client has in place to cope with code tampering. Normally it computes a checksum of its source code and sends that to the server which has a database entry which version has which checksum. If you tamper with the code, it will simply say so and block communication. Now if you dig deeper and change the code providing that checksum, you have tampered with the code and the client sends the "correct" checksum to the server. There is a 2nd mechanism in place to prevent that and that's what you have seen. Please do not change the code of the client - it's really not worth it.

Should probably just abort when a new version is found and not start working.

New version seems to work, Ill complain later in case it doesnt

I have checked it in the logs. Something is triggering this behavior in a regular update.Currently it seems to keep the checksum of the older version, but sending the newer versionto the server

Code:

178cbfaa074273b584fd4f8ed220aaf6 <-> d9f2697140fbf1e5c919a01630bce63b

(178cbfaa074273b584fd4f8ed220aaf6 is 1.010 and d9f2697140fbf1e5c919a01630bce63b is 1.015)

Not sure yet what's going on, so for now it's safe to say if you encounter this, have a laugh andignore it - you're most probably not doing anything wrong. Just downloading 1.015 should fix things.I will of course look into it and fix this.