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 ?!

LBC is going to start finding the 55th key in a few hours.

With 3GH/s should take around ~37 days

0.55 BTC plus BCH plus BTG yields around

~0.66 BTC = $8,500

Basically about 2x as profitable as regular ETH mining with a RX470/570 if you can find it in 37 days and not closer to the end around 74 days.