Topic: Large Bitcoin Collider (Collision Finders Pool) - page 54. (Read 193484 times)

What a pain in the....

If anyone knows WTF they are doing with Go and OpenCL please feel free to help, haha.

Trying to make an OCL version of LBC for teh fast.

Work of a whole day gone


500 Can't connect to 62.146.128.45:5000

address is on http://directory.io/120349701228   

Eyyyyy!!! xD

Congratz xD

Tadaa.



Rico

New LBC client will have slightly different time semantics.


So no seconds anymore, as that granularity doesn't make sense. No days either.
While testing the new code, I got bitten by habit  - of course:


So silly me, instead of 30 minutes, I gave it 1800 minutes and the client got a block interval for 1 day. Because I cancelled the job, it never delivered and today the server decided to reissue. While the forefront at the time of reissue was somewhere beyond block 14000000, this "1 day of work of my 4 Skylake cores" got thrown before the pack.

Less than 2 hours later, it has been munched and we are at 14000000+ again. 

Rico

Currently its 200% of the ETA as declared by the client. So if the client asks for work for 10 minutes and does not deliver within 20 minutes, blocks will be reissued. However, if the original client still delivers them after that, they'll be accepted too. It's just that at that time another client might have done them already (double work).


September 24th. The new version will fortunately have a way to incrementally update the balances data as often as it will make sense.


Rico

Daaaaamn...

And im here with my small 4 core PC at 1 million keys pr sec having fun xD.

it' server with 2 x CPU - 10 core each crystal, each core have hypertreading = 40 virtual cpu

I had no experience with LBC on AMD, but one of the beta testers used it on AMD (250 000 keys/s per core - don't know which CPU model though). So It works evidently. Any AMD CPU that has at least a "Westmere"-similar instruction set should run fine.


I observe the best performance on Skylake CPUs. Ideal seems to be:

• as many physical cores as possible (use those, leave hyperthreaded cores for the OS  )
• as high frequency as possible
• AVX2

One 2.8GHz Skylake core does over 500 000 keys/s with the avx2 version of hrd-core


Rico

Holy Shizz...

A CPU with 20 cores xD

I gotta do some research and see if I can get some hardware that can compete with that xD.

1 Client running strong atm with just about 1 million keys pr sec.
Another one will come up today or tomorrow at the latest

EDIT: Any difference between Intel and AMD CPUs?

What specs would be the most ideal?

Seriously, if you have such a machine, start LBC on a Linux instance
on your CPU you will get under windows ~ 25 000 keys/s, under Linux at least 300 000 keys/s - per core

get this version: http://62.146.128.45/download/LBChrd-0.837_l64.tbz2

If you install it in some Linux VM and give that VM X cores, give it 550MB * X + 300MB RAM. (4 cores -> 2.5GB, 8 cores -> 4.7GB etc.)
If you use 8 cores on your machine, you should be able to check 2.5 mio keys per second.

Which Linux version?



Rico

Thanks - that works!

If I have 20 CPU core on intel E7 4870 - I will must run 20 process?

What version  the Linux you recommended?

go into the LBC directory, there issue the "perl LBC -c 1 -t 60 -l 0"

for your 1-shot try. LBC looks for the generator executable only in the current directory.

It should work, but you should seriously consider letting this run on Linux 64bit. The Generator there is 13 times faster, uses less memory (and -c X for X > 1 is also no problem).
You can ignore the "-c 1" message if you set the "-c 1" yourself. See also "Yesterdays bug"



Rico

Hi
I have a Windows 2008R2 x64 virtualized on the vmware esxi 5.5

I try run LBC and have error:
If I run with any parametres in c  - LBC -l 0 -c x -t 1:0
aslo print those message

Basically yes - not a single block, but a block interval. See the green text in "Yesterdays bug"


If you simply run the client in "auto" mode (as 99% of clients do), you got the blocks 50-100 from the server, because the client asked the server "give me work for X cpus for Y time". This is a get_work message client -> server and at the same time a promise to finish that work.

Now if you close that client as in your example, your client will not deliver at the end of the cycle a proof of work that the given interval was searched. Therefore ALL of the blocks in the promised interval are considered not having been done and will be reissued again.

---

If you manually define which blocks your client should compute (-p - see "Going no-auto") the server does not even know about your clients work until it finishes its self-imposed work. Only upon finishing, it delivers PoW to the server and the server will add this manual interval to the list of blocks done and also credit the client these blocks done.

This is a part of the server log. The IPs and the client-Ids (except 1ff65d1e0f08af7529e9c9f0a591f263) I have changed. The timestamps and the block ranges are original. For readability I also added client name aliases.


Most of the time, we see a client delivering (<<<) pow of an interval done and immediately getting (>>>) a new interval.
You can see that A gets [11692283, 11692898] after having delivered [11673395, 11674010].
Roughly 100 seconds later, B delivers [11668291, 11671482] and gets [11692899, 11696090]. As you can see it starts off where end of work for A was. Same with C and D. Last entry is my workstation, where I started up LBC at the time, so it fetches a work interval (starts where end-of work for D was) and there is no previous delivery.

As mentioned in the referenced text, sometimes clients do not deliver promised work within a certain time frame, so the work will be reissued.
Then there is also a global overview of blocks done, which looked today morning like that:

You can see the pool "forefront" somewhere behind 11754328, this is where new work intervals will be reissued. The [3515625000000,3515625030841] is an interval that is the result of a manual -p where someone ran their client for a day.

You can also see, there are missing intervals in there. First one 10255011-10255651. These are 640 blocks that have been not or not yet delivered back after they have been promised. If the clients who promised them will not deliver back, this range will be reissued by the server.
So yes, the blocks 0 - 10255010 (the first ~ 10753157365760 keys) have been searched completely already. As the holes are getting filled, this first interval grows.

Rico

One question/concern I have if it was not already brought up, but does the server check for a response of some sort to confirm that a block was completely searched?

For example if I have block 50-100 and at block 60 I close my client, does the server know that my block was not completed and someone else will need to finish looking through it?

Two days ago, the pool found the private key to

https://blockchain.info/address/1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1

Which is one of the "monitoring" (at least I call them so) addresses from the transaction
Ryan mentioned in his 1,3,7 cracking article.

I suppose, at the current speed we will hit the private key to

https://blockchain.info/address/1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF

within 24-48 hours. Any bets?


Rico

http://lbc.cryptoguru.org:5000/stats

Read the text above the client list...


Rico