Ok, I finally sold those Bitcore AND Bitcoin Gold coins from the 54th key.

I think I sold the BTG for around ~0.038 and the Bitcore was like $8 or so. So I will send over half as promised.

However little did I know that Hitbtc sends BTC from Segwit addresses and my Electrum isn't upgraded yet. So I need to upgrade first before I can send over the BTC to you. So give me a few days to do so.

Excuse me for not reading everything about LBC, but who found the keys corresponding to 0.161 - 0.256 BTC outputs range in the Puzzle transaction? There are somehow derived from 0.001 to 0.054 private keys?

Hello, guys! Just joined my modest 10Mkps to your great project. But I still have a couple of questions...

1. What perl program does when the collision is found? Only writes to file FOUND.txt? If I someone overlook/delete this file, nobody will even know that we found the key and the worst thing - this range should be marked as empty? 

2. Is there any validation of results? Or just checking checksums of the program itself? Why not to compute each block's checksum (even simplest in couple of bytes) and send to server?
Then make 10% of work-units overlap. If checksums do not match, sending to third client and marking ALL work from client with wrong checksum as undone and ban him if there were several badly processed blocks.

For now it seems like we are sifting with too large sieve? 

Joining up!

By the way, don't you think that starting from very beginning is a bad idea?

I guess most of us are hoping to discover abandoned wallets from early 2010-s.
At that times harsh cryptofreaks didn't have fancy bitcoin-core software and generated private keys themselves.
So, they at least have seen the result of RNG.
And the secret key with 40 leading zeros looks very stupid.
Yeah, I understand that any value from RNG has the same probability to occur, but still...

Why not to move to middle of 256-bit range (or 2^160 - I'm not sure what exactly we are bruteforcing)?

No hard feelings, but I think you have still a lot to read and learn about the project and the concept and tech behind it.

Most of your "suggestions" are result of being badly informed - really.

ASICs - as the "Application-Specific" part suggests - are of use only for a very narrow usage case. Bitcoin miners have scrapyard value beyond BTC* mining.

I asked http://www.orsoc.se/ what the cost of ASIC development might be about 2 months after launching the pool.
ORSoC is/was the technology development company behind KnC and I thought it would be a good address to ask.

Unfortunately never got any answer. I might try again.

Bitcoin miners do a SHA256d essentially.
The LBC does  ECC, followed by hash160, followed by bloom filter lookup

Now the hash160 is actually less demanding than SHA256d and if it was only for that, I'm pretty sure that hash160 ASICs could deliver more performance than SHA256d ASICs.
The ECC however, requires 256bit multiplications and that is serious stuff taking up whole FPGA circuits. (at least until a few years ago)

At the moment we do these ECC things on CPU and hash160 on GPU

An ASIC doing hash160 and Bloom-filter lookup (512MB chips containing the BLF connected directly to the ASIC) I can imagine, but I can't imagine how to feed it with ECC data.
ECC on ASIC I can't imagine, but then again, I am a VHDL, Verilog, FPGA, ASIC noob.

It would certainly be good if we managed to establish at least some informal smalltalk with ORSoC (or similar) engineers about this.

Hi! what is the -c in process? why they are diferent? 
http://c2n.me/3Qpu2Gr

Total newb here when it comes to linux but please take a look at the attached image and let me know if I actually started the collider

https://i.imgur.com/BLSDMjc.png

If it's started how can I see the FOUND.txt file in case something is found? Any suggestion is much appreciated.

edit: also, does 1,8 Mkeys/s mean that I'm searching through 1,800,000 keys per second?