Made more experiments.
Two cards do not interfere each other and work at 16+25 Megakeys in one PC.  

Two CPU cores are used.

Upgraded 1050ti to gtx1060 3GB.

On 1050ti: LBC had 22Mkeys, vg from ndv 16Mkeys.
On gtx1060: LBC dropped to 20Mkeys, vg from ndv 25Megakeys.  

Cpu is core i7 3.7, with vg only one core is used.
GPU consumes 65W. GPU is 100% utilized, gpu mem is 7% utilized.

Still very interested in benchmarks on 1070 and 1080.

p.s. most of $500 went to rewriting launcher, but not OpenCL kernel.
Today he boosted the speed from 11.5megakeys to 17 in a couple of hours. 

Says that ECC part should be rewritten properly, and many other things.

Testing done today. Now it successfully searches all previous bounty PKs.

Also some boost in speed - on 1050ti 17megakeys (LBC was 22mk).

Still very interested in benchmarks on high end cards. C'mon, dudz!

Partially done!

I've payed my $500 to the programmer who modified oclvanitygen for searching 32BTC bounty (or any other address actually)
...delete

Moving here https://bitcointalk.org/index.php?topic=3102823

Partially done!

I've payed my $500 to the programmer who modified oclvanitygen for searching 32BTC bounty (or any other address actually)
All possible optimizations are NOT done, because he asked for $1100. But even now it is doing all the stuff on GPU.
Both compressed and uncompressed addresses.
Actually it is an disconnected version of LBC. Network access is not required at all. All code is opensource.
It is Nvidia optimized, but should run on ATI with about 10% penalty.
He claims that it runs in windows without crappy virtualization.

https://github.com/ndv/vanitygen

On my gf1050ti it is almost twice SLOWER than LBC. But I'm really really interested in seeing benchmarks for large rigs, because CPU  is not bottleneck any more.

p.s. If someone wants further development, contact me or him directly. It can be split to parts, not only $600 or nothing.

deal is done. 

Wut? Sooo strange conclusions you've made.

For EVERY LBC member speeding up the entire LBC is good, because we could collect bounties a bit faster. That's especially true for glatzer and other maniacs with dedicated rigs.

But if the mass is too hesitatory, then it is even better for smaller group, who will get an advantage for themselves.

Thanks for commenting

Cheap - you mean I offer some scam?
Or cheap for a programmer to work for a week and earn $1k ?

For me $1k is a close to month's salary (programmer too).


The best option would be for LBC community to gather and to spend 5-10 bucks each. But surprisingly nobody give's a fsck.

As time goes by, I'm more convinced that current LBC's goal is to PREVENT effective brute forcing of Bitcoin address space.  

.

Hey!

OK, deleting initial post. Fork is already done, and freely available.

https://github.com/ndv/vanitygen

But there's plenty of opportunities to make it faster (for extra bucks).

If you want to make it better, contact this programmer.

......


If you like LBC and its Remote Exec Feature do not read any more.

1.
LBC itself has a BIG problem - it is heavily CPU bound.
A classic mining rig with 4-6 GPUs is almost useless with it.
Most of GPUs will be underutilized.
By contrast oclvanitygen even now uses 100% of GPU. After moving ALL processing to GPU it will be super scalable.

2.
LBC users have a BUNCH of problems - your hardware is not utilized, you do not know what addresses are in bloom filter, you do not know what Rico executes on your PC, you cannot be sure that you are actually not making doublecheck after other LBC users, you cannot be 100% sure the whole LBC is not scam. Isn't that enough?

>Is there anything wrong

Megakeys means millions of keys. 18607006172-18607002461=3711

That's a wrong statement. They are killed (with 30 seconds timeout) when there's demand from google itself.
So they live from several minutes to 24 hours.

DigiOcean highCPU seems to be ordinary dedicated CPUs, price is $160 for 8core.

Probably google's "preemptible instance" for $40/month is the winner (8core). Speed differs from 3.1 to 3.4 megakeys.

Let me guess the speed - about 10k keys per second per thread? (that's what I got on my java-version)

I myself is a huge fan of java (esp EE), but it really SUX on this task. vanitygen is about 60 (yeah, sixty) times faster.

I was hoping to get usual slowness of 10-20-30 percent, but not 60 times.

Do you have an interest to make use of OpenCL ? It should speed things up. But oclvanitygen is also faster (5 million keys per second per core easy)

Are you on topic, man? 134.58 is just an AVERAGE distance in 2^256 between addresses. And nothing more.

Right now bloom filter with ~20mln addresses with funds is more than 500MB and it takes precious RAM from every GPU process.
I suppose switching to 1 address (or say 5000 really abandoned wallets) would RAISE speed in several times.
But unfortunately, the project is looking for all addresses.

The probability to find ANY address would be 15mln times lower.

The probability to find EXACT address would be the same.

So, LBC is going through first 160 bits of 256? But Rico says it is not.

Thanks for the answer! And what's the magic of extracting 2^160 from 2^256? That's totally unclear

adr1 = ripemd160(sha256(pubkey(rand(2^256-2^160)+2^160)))

this line makes no sense to me 

2^256 is from 1 to 115792089237316195423570985008687907853269984665640564039457584007913129639936.

2^160 is from 1 to 1461501637330902918203684832716283019655932542976

But the sha256-hash of LONG==1 is almost in the end of 2^256
48635463943209834798109814161294753926839975257569795305637098542720658922315

LONG==1461501637330902918203684832716283019659932542976 (around 2^161 ) is also near hash of 1.

So, if LBC is not going sequentally from PK == 1 to 2^256, does it really solve this puzzle?! 

Hey, guys!

Please, anyone can explain how do you predict when LBC will find the key?

I've read (lbc.cryptoguru.org/man/theory) several times, but do not understand that pseudo code (I'm programmer, but noob in crypto)
The point I do not get completely: rico claims that they do not brute 2^256 range, because it is too large and do some hack to make range 2^159.

I of course understand that after sha256 we get a compression of range. But shouldn't sets 2^256 and 2^159 overlap chaotically? So how LBC chooses the right keys from 2^256 that map to unique addresses in 2^159 ?

For solving this puzzle shouldn't LBC brute 2^256 range ?!